Kodi Community Forum

Full Version: Odd error when XBMC switches video modes
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Edit: as of 11820 this issue appears to be fixed on my machine.

Just now rebuilt my system from scratch so this might not be an XBMC error.

Error reads:

X Error of failed request: BadValue (integer parameter out of range for operation)

Major opcode of failed request: 135 (Xfree86-VidModeExtension)
Minor opcode of failed request: 10 (Xf86VidModeSwitchToMode)
Value in failed request: 0x13a
Serial number of faild request: 131
Current serial number in output stream: 133
Aborted (core dumped)

This on up to date on Ubuntu 7.10 with NVIDIA binary drivers updated today. When the error occurs I'm left at a really low rez desktop. If I run XBMC again at this resolution it runs okay but obviously the screen looks like crap. XBMC resolution is set to use desktop resolution. I'm on build 11708 right now. Is this me or are others seeing this?

Edit: I updated a known good working load, with broken sound, to 11716 and this error now occurs.
xrandr must not be playing nicely with your video card and/or driver. Try some other resolutions/framerates..
Uh boy, that sux. This is pretty much the exact setup I was running prior to the rebuild. I didn't pull xrandr from package manager this time, was either from the Wiki apt-get or from the Desktop load. I will look into this from an Xrandr standpoint, see if I can figure it out. 1920x1080 is what was running before, in fact this is the same Xorg file I was using prior to the rebuild. Appreciate the lead!

One question, how do I go about reverting to a previous build? svn revert -R doesn't seem to do it, wants more arguments.
I'm not at my machine atm but I think it was something like svn up <version number> -r

As I say I'm going from memory (rather corrupt Smile )
snappz Wrote:I'm not at my machine atm but I think it was something like svn up <version number> -r

As I say I'm going from memory (rather corrupt Smile )

Thank you! That might come in handy. I had thought to revert my machine back a few builds and see if the issue persisted. However I'm not sure this is XBMC and as stated above might be xrandr, just not sure what to do about it. I suspect that my previous build used an older NVIDIA driver, I may yet pull that from backup to see. It's possible my heavily tweaked Xorg.conf is no longer right with this new driver. However something happened to that working build today and I no longer get PCM sound. So, sound on one build, video on the other Sad Given a choice I'd prefer to get the older load working but having reloaded ALSA and other sound stuff it still doesn'twork - argh.

Here's what I see in my XBMC log when it blows up with the load that has video issue, looks like xrandr to me!

Code:
05:57:19 T:3056379744 M:1675751424    INFO: Checking skinpath existance, and existence of keymap.xml:Q:\skin...
05:57:19 T:3056379744 M:1675751424 WARNING: CXRandR::SetMode: found alternative mode (different hz): default mode: 0x15c.
05:57:19 T:3056379744 M:1675751424 WARNING: CXRandR::SetMode: found alternative mode (different hz): default mode: 0x15d.
05:57:19 T:3056379744 M:1675751424    INFO: XRANDR: /home/blkmgk/XBMC/BUILD/xbmc-xrandr --output default --mode 0x15d
05:57:20 T:3056379744 M:1664045056   ERROR: (pthread_mutex_destroy(&m_mutex)): 16

Not 100% clear on how xrandr works. However it looks to me like it's selecting 0x15d but the error at console says 0x13aHuh Running xbmc-xrandr I get a list out video resolutions. 0x15d is a 720x576 screen, 0x13a appears invalid. I think the 0x15d is the rez I end up with when it crashes down.

Is after 1am here and I've been screwing with this all day first with the sound and then the video. I had guests over this evening and had wanted to show off some of the HD I've been transcoding but it wasn't to be, I'm beat. I'll back this up and play more come morning. Open to suggestionsConfused
snappz Wrote:I'm not at my machine atm but I think it was something like svn up <version number> -r

Nope. I was close. Try

Code:
svn up -r <version number>
Okay, this is a BUG introduced within the last day!!!

Frustrated at not being able to figure out the video problem I loaded up from backup the install that had broken sound to try and troubleshoot. Having little luck getting sound working I did an SVN up for XBMC. Boom! XBMC on THIS install is now having the SAME issue I have above with THAT install! This WAS a perfectly good working install until the sound went away, now the video is broken just like it is when I create a new Ubuntu Desktop install. Gah!

Is no one else seeing this?? It's the EXACT same error on this install as on the other. NVIDIA binary video drivers, 8500GT card.

I will try to roll it back with the SVN command above and identify where it went off the rails...

Edit: Nope, svn up -r 1699 results in an error that the target path doesn't exist with a long path from the xbmx repository it looks like. Cannot easily copy\paste it here Sad I *think* 1699 worked fine, it was one or two after the multi-core decoders were in that last worked, 1708 failed for sure.
1699? We're up to almost 12000 now in buildnumbers. Grab a changelog using tools/Changelog/Changelog.py and pick a likely build number to revert to.
rodalpho Wrote:1699? We're up to almost 12000 now in buildnumbers. Grab a changelog using tools/Changelog/Changelog.py and pick a likely build number to revert to.

That would be 11699 sorry. I've been keeping pretty good pace with the builds. You're right though the number was off, I'm reverting back to 11699 now. I think I can perhaps step forward from this and figure out the one that cooked my video!Nod

Thanks!
Okay, not had much luck reverting. I get errors with the LCD code. I'm not deleting existing code but am making clean so it's possible it's something on my end. A quickie on what should be done would be helpful. Honestly I'm most upset that I seem to be the only one with this issue - that sux! It's 100% XBMC though, confirmed that. I'd love to narrow this down!

Anyway, I can let it crash at some crap rez and then run again and it will run at that resolution. Video is goofy at 720x576 though, like watching it through a periscope. Sad Man the builds right before this were rocking though!Big Grin
The LCD stuff was just added. Try backing up your userdata then completely deleting everything and starting clean.
rodalpho Wrote:The LCD stuff was just added. Try backing up your userdata then completely deleting everything and starting clean.

Doing it now, will start with 11699 and work upwards. I know that it worked fine on a version I had backed up that had the dual core decoding but sound broke on itRolleyes I reloaded from scratch and was on 11700+ and it was toast. I should hopefully have a revision nailed down tonight. I compile with debug on 100% of the time (drives the woman nutz but..) so I will be able to provide a log. Is there anything else at all I can provide to troubleshoot this?

Thanks!

Edit: Does the X+Y apply to Linux XBMC too?
I don't believe that the devs are officially accepting bugreports yet, but they do monitor the forums off and on. Bugs that affect their configurations get fixed quickly, features that they would personally like to see (like mythtv support, etc) get added quickly, others (like the SDL build being broken and WMV files playing slowly) are addressed at very low priority. That's just how opensource development works, nobody's being paid for it.

Why would debugmode upset anyone? Just run XBMC with the -q switch.
rodalpho Wrote:I don't believe that the devs are officially accepting bugreports yet, but they do monitor the forums off and on. Bugs that affect their configurations get fixed quickly, features that they would personally like to see (like mythtv support, etc) get added quickly, others (like the SDL build being broken and WMV files playing slowly) are addressed at very low priority. That's just how opensource development works, nobody's being paid for it.

Why would debugmode upset anyone? Just run XBMC with the -q switch.

Oh, I know they aren't accepting bug reports yet although I see a few listed in the Dev forum. The Debug mode bothers her because I do not use -q Big Grin I leave it up full time to monitor what's going on with the CPU and whatnot. This is code under development so I like to watch for anything odd so I can report it <shrug>

Right now it looks like I'm good up to 11702. 11703 breaks my box, I've gone back and forth about 3 times now to make absolutely sure! This last time it crashed VNC too lol:p

Looking closely at the code and not being much of a coder <ahem> the changes in GraphicContext.cpp look most likely to have been at fault to me. Surface.cpp looks suspect too but it appears to check if the host is an Apple first.:confused2:

I'd love it if a Dev could look at this! For now I'll hold at 11702 and try it out occasionally. Hate to be left behind Oo
You know that you can monitor the CPU display with the title button, right? The little black bar with 4 (used to be 3) lines of info about the currently playing video?
Pages: 1 2