I've just upgraded to the latest version after being on an 0.7 build for awhile, I'm seeing constant problems where mednafen will launch but xbmc will still retain focus. It also seems like the time between selecting a rom and the application launching has substantially increased from what I remember
I'm also using a 360 pad as my xbmc input device with the eventlistener application, seems that XBMC is still receiving and responding to input from the 360 pad when the emulation app launches as well
What OS are you on? Windows, I guess, because I'm having no troubles with mednafen, the 360 controller and the launcher...
Jurai Wrote:I've just upgraded to the latest version after being on an 0.7 build for awhile, I'm seeing constant problems where mednafen will launch but xbmc will still retain focus.
I will need more information on your system to help you. Mednafen is runnning correctly, on my system under Linux and Windows. If you just switch from version 0.7, you may know that way to use command lines have changed :
http://www.gwenael.org/xbmc/index.php?title=Mednafen
Jurai Wrote:It also seems like the time between selecting a rom and the application launching has substantially increased from what I remember.
Advanced Launcher is just starting applications as before using one single code line. If it is slower, it could be related to your system or XBMC (version or skin used).
Jurai Wrote:I'm also using a 360 pad as my xbmc input device with the eventlistener application, seems that XBMC is still receiving and responding to input from the 360 pad when the emulation app launches as well
I do not know how eventlistener is working. But in a normal way only the focused application have the control. If eventlistener, bypass this rule... yes... it could create control problems, and may explain why Mednafen still controlled. Have you try to start XBMC, ALA and Mednafen without any controller, and without eventlistener in background?
went back to 0.7.5 of the addon and none of the mentioned problems seem to occur, im on win7 with dharma 10.0 release version. yes I'm aware the commandline changed. guess ill reinstall xbmc from scratch and see if that helps.
Jurai Wrote:went back to 0.7.5 of the addon and none of the mentioned problems seem to occur, im on win7 with dharma 10.0 release version. yes I'm aware the commandline changed. guess ill reinstall xbmc from scratch and see if that helps.
Have you try this ?
For Windows users, to avoid any Direct3D conflict between XBMC and emulators, you need to activate the Use a fullscreen window rather than true fullscreen option into the Settings / System menu of XBMC.
Angelscry Wrote:Have you try this ? For Windows users, to avoid any Direct3D conflict between XBMC and emulators, you need to activate the Use a fullscreen window rather than true fullscreen option into the Settings / System menu of XBMC.
like i just said, the problem doesnt happen on the older version of the plugin, so not sure why I'd suddenly have a horrible experience with the new version.
K, fresh installed with latest version of plugin (0.9.3), it appears to still be allowing xbmc to process input in the background, causingg me to launch mednafen multiple times as im playing the game. XBMC did NOT process the events in the old version while app was running.
In 0.7.5 (and not sure how far past) I know there was specifically an option in the config to choose whether to Freeze XBMC when the app launched or just launch the application, does the plugin no longer offer the option to freeze xbmc while your application is running?
Jurai Wrote:K, fresh installed with latest version of plugin (0.9.3), it appears to still be allowing xbmc to process input in the background, causingg me to launch mednafen multiple times as im playing the game. XBMC did NOT process the events in the old version while app was running.
In 0.7.5 (and not sure how far past) I know there was specifically an option in the config to choose whether to Freeze XBMC when the app launched or just launch the application, does the plugin no longer offer the option to freeze xbmc while your application is running?
Ok. I have finally fixed the windows command line problem, and your problem will be fixed in the next version. I will also bring back the wait state option, because finally someone need it.
Hey Angelscry,
I've changed the default info scraper to GameFaqs, because I like my "Description" field to be the text from the back of the game boxes. I also turned on automatic Boxart import for US boxes (also from GameFaqs). However, ALA is automatically pulling in FanArt too, even though I do not have this option turned on. I believe this is a bug.
Also, ALA doesn't store the info for the Roms anywhere. It would be really nice if ALA read the info from a ROM.nfo file that was stored with the emulator in the same way that fanart and thumbs are stored. Even better, if you mimicked the current file layout that XBMC uses for Movies! Store the Fanart.jpg, Boxart.jpg, Rom.* and Info.nfo files in a folder with the same name as the rom:
"Rom Folder"
|====="Rom Name"
|======|------Rom Name.zip
|======|------Fanart.jpg
|======|------Thumb.jpg
|======|------Info.nfo
|====="Another Rom Name"
|======|------Another Rom Name.zip
|======|------Fanart.jpg
|======|------Thumb.jpg
|======|------Info.nfo
What do you think?
Angelscry Wrote:Ok. I have finally fixed the windows command line problem, and your problem will be fixed in the next version. I will also bring back the wait state option, because finally someone need it.
thanks I appreciate it, I don't think the 360 event listener app discerns if xbmc is the current highlighted app so it just chugs along relaying input .
out of curiosity, what is the reason behind NOT entering a wait state all the time? tbh I can't think of a good reason to not always dump xbmc into a freeze state when launching a separate app thats taking display control
srsobieraj Wrote:I've changed the default info scraper to GameFaqs, because I like my "Description" field to be the text from the back of the game boxes. I also turned on automatic Boxart import for US boxes (also from GameFaqs). However, ALA is automatically pulling in FanArt too, even though I do not have this option turned on. I believe this is a bug.
Very strange... I'm going to check this. Fanarts are added (even if the option is disabled) during automatic scan or manually rom add? Are you sure you do not already have local fanarts images and Advanced Launcher found them automatically?
srsobieraj Wrote:Also, ALA doesn't store the info for the Roms anywhere. It would be really nice if ALA read the info from a ROM.nfo file that was stored with the emulator in the same way that fanart and thumbs are stored.
Infos are stored into the
launchers.xml file with all the Advanced Launcher infos.
srsobieraj Wrote:Even better, if you mimicked the current file layout that XBMC uses for Movies! Store the Fanart.jpg, Boxart.jpg, Rom.* and Info.nfo files in a folder with the same name as the rom:
"Rom Folder"
|====="Rom Name"
|======|------Rom Name.zip
|======|------Fanart.jpg
|======|------Thumb.jpg
|======|------Info.nfo
|====="Another Rom Name"
|======|------Another Rom Name.zip
|======|------Fanart.jpg
|======|------Thumb.jpg
|======|------Info.nfo
What do you think?
No. That's really not a manner to organize roms. Most of the time, roms need to be into the same folders (like for MAME emulator, project64, Dolphin, etc...). Also there is a lot of covers and screenshots images packs that already exist and are organized like this.
Jurai Wrote:thanks I appreciate it, I don't think the 360 event listener app discerns if xbmc is the current highlighted app so it just chugs along relaying input.
out of curiosity, what is the reason behind NOT entering a wait state all the time? tbh I can't think of a good reason to not always dump xbmc into a freeze state when launching a separate app thats taking display control
Yes, but for applications that did not take display control and works into the background the wait state must be desactivated. For example
ijourneaux use Advanced Launcher to start the PVR application BTV into background :
http://forum.xbmc.org/showpost.php?p=678...tcount=764. Also, if I decide to add pre- and post- command line support to the Advanced Launcher, they will not use the wait state.
Thought I would share a bit on why my emulators weren't launching. The issue is that was causing them not to launch is a space in the path.
I was running my testing of emulators from my desktop. My username in windows 7 has a space in it, and it was causing a failed addon.py error.
I changed all of my emulators to a more standard c:\games\ , and they boot right up!
Not sure if the new version of advanced launcher needs to put "" around the path in the launchers.xml, just in case to cover peoples scenarios?
just a question, why do you import xbmc here ?
seems to be not used.
ppic Wrote:just a question, why do you import xbmc here ?
seems to be not used.
What you you mean by "here"?