Windows XBMC crashes when XBOX-controller disconnects

ok I rushed the previous version a little bit. I made some tests on my HTPC and it would not register the button presses anymore.
here is fixed version:
http://ryushare.com/ik4s6zoac43z/XBMC.zip
tell me how it behaves in your environments.

Are you referring to the nightly builds? If not how can I tell if am on the most recent build?

you should be good with an environment created from the nightly builds. versions don't need to be a perfect match.

As WiSo wrote I don't have a controller. But I have ideas :-)

@WiSo is it an option to bump the SDL dll? It's pretty ancient.

@evil-B I understand how your change avoids the problem, but it doesn't really fix it. Is there a way to make the SDL recover after the exception and get valid data again? Using functions like SDL_QuitSubSystem, SDL_InitSubSystem, SDL_Init, SDL_Quit...

Maybe sleeping a little in the event handler before calling CJoystick::Reinitialize() would help? Or sleeping between the QuitSubSystem and InitSubSystem?

For video playback, you guys will need to add evil-B's binary on top of the latest xbmc nightly.

sure as I said, this is a workaround not a fix.

I made some more tests on my dev machine and I am now able to reproduce the bug more frequently. Turning off the controller while playing a video triggers the bug more often. That way I found out that once SDL_InitSubSystem has crashed, it will always throw an exception for every subsequent calls even if I try to call SDL_Quit / SDL_Init.

If I call SDL_QuitSubSystem, then SDL_Quit and then SDL_Init in Reinitialize() the bug comes up less often but it still does from time to time.
Of course calling SDL_Quit could be a problem on systems where the SDL layer is used for more then just Joystick handling. This SDL layer is a mess.

Anyway here is my latest attempt for those XBMC adventurers:
http://ryushare.com/uhqh6qhvbqqk/XBMC.zip

I am starting to think that I will use xpadder to handle the controller completely...

(2012-04-27 12:31)evil-B Wrote:  If I call SDL_QuitSubSystem, then SDL_Quit and then SDL_Init in Reinitialize() the bug comes up less often but it still does from time to time.
Of course calling SDL_Quit could be a problem on systems where the SDL layer is used for more then just Joystick handling. This SDL layer is a mess.

Hasn't it always been?
Question would be for example games - most of them use SDL nowadays, so that could indeed produce silly problems...
However - strangely I cannot reproduce the error on my Win-System (Windows Enterprise x64, SP1). Neither with a wired nor with a wireless controller...

Quote:I am starting to think that I will use xpadder to handle the controller completely...

Another solution would be to try to use the EventClient for the controller for XBMC. That should resolve the issue, shouldn't it?
Of course, you have to keep in mind that if XBMC isn't in the focus, the commands of the controller will get passed to it anyhow... this could of course arise other issues, if you use your controller in other situation when XBMC is still open.

Me thinks that this could also be a problem within SDL...?
Maybe this fits somewhere here...?
http://bugzilla.libsdl.org/show_bug.cgi?id=1139

yes this fits quite well with our current problem... I guess we'll have to wait for the SDL next version and hope...
I tried the build the latest SDL version but XBMC would not take it and I am not in the mood to investigate this matter.

If we get good reports from my latest patched version I will indicate exactly what I did otherwise... lets dump this.

I gave it a shot and couldn't play a movie and the controller crashed. Can anyone else confirm this behavior?

if you can't play video probably that your installation is not up to date. Do you have a dll load error in the log ?

(2012-04-27 04:11)CrystalP Wrote:  @WiSo is it an option to bump the SDL dll? It's pretty ancient.

We already wanted to get rid of SDL for all platforms but we still rely on the input layer. topfs2 wanted to abstract it and uses addons for it but afaik never started with it.
We got rid of the SDL window handling on win32 but the last bits are often the difficult ones.