(2015-08-30, 13:18)garbear Wrote: [ -> ]Each peripheral bus gets its own thread, and all scanning happens within that thread, regardless of where the scan was triggered
Are you sure about that? Anyone can call CPeripherals::TriggerDeviceScan() which in turn calls CPeripheralBus::TriggerDeviceScan() which then either triggers an asynchronous device scan through CPeripheralBus:
rocess() or directly calls CPeripheralBus::ScanForDevices() in which case the scan isn't performed in the CPeripheralBus thread.
(2015-08-30, 13:18)garbear Wrote: [ -> ]The mistake here is that the add-on bus shouldn't hold a lock when passing control to the add-on. I'll get this fixed
The locks being held in below stack trace make sense with the current lock structure (apart from the fact that often the locks are protecting a container but then return a raw pointer to an item from the container which might disappear anytime). Moving to RWLocks wouldn't help in the situation either.
I took a quick look at the code and looks like the CPeripherals::GetAddon() is new to RetroPlayer and its call to CPeripherals::GetBusType() which already exists in master is causing the deadlock. The add-on peripheral bus implementation doesn't hold any specific locks that are causing this issue. They are all in CPeripherals and CPeripheralBus.
I've also done some more runtime testing on the emulators and every now and then when I stop an emulator (doesn't matter which one) it crashes when calling Destroy() on game.libretro. Couldn't figure out yet how to reliably reproduce this. I just start and stop the emulator a lot until it happens. Need to setup game.libretro for debugging.
Furthermore I'm getting the feeling that input delay gets worse the longer I'm playing in an emulator. When starting Super Mario Bros. in level 1 input is perfectly fine but when reaching level 4 there's a huge lag and some button presses aren't detected at all anymore (especially when I'm pressing multiple buttons at once like running and jumping etc. I'm not really sure if it has anything to do with how long the emulator is running but I've never noticed any problems after starting fresh.
(2015-08-30, 13:42)Montellese Wrote: [ -> ] (2015-08-30, 13:18)garbear Wrote: [ -> ]Each peripheral bus gets its own thread, and all scanning happens within that thread, regardless of where the scan was triggered
Are you sure about that? Anyone can call CPeripherals::TriggerDeviceScan() which in turn calls CPeripheralBus::TriggerDeviceScan() which then either triggers an asynchronous device scan through CPeripheralBus:rocess() or directly calls CPeripheralBus::ScanForDevices() in which case the scan isn't performed in the CPeripheralBus thread.
Good point, asynchronous scanning only happens for buses that don't set m_bNeedsPolling to false. Seems kind of odd to couple the scan thread to the update model. The add-on bus left m_bNeedsPolling as true, so it was scanned asynchronously. Which was probably an oversight, as it was in the
application bus.
(2015-08-30, 13:42)Montellese Wrote: [ -> ] (2015-08-30, 13:18)garbear Wrote: [ -> ]The mistake here is that the add-on bus shouldn't hold a lock when passing control to the add-on. I'll get this fixed
The locks being held in below stack trace make sense with the current lock structure (apart from the fact that often the locks are protecting a container but then return a raw pointer to an item from the container which might disappear anytime). Moving to RWLocks wouldn't help in the situation either.
I took a quick look at the code and looks like the CPeripherals::GetAddon() is new to RetroPlayer and its call to CPeripherals::GetBusType() which already exists in master is causing the deadlock. The add-on peripheral bus implementation doesn't hold any specific locks that are causing this issue. They are all in CPeripherals and CPeripheralBus.
The biggest offender is CPeripherals::GetPeripheralsWithFeature(). Any peripheral handling that occurs outside CPeripherals right now (configuration GUI) is unsafe. What if I changed these all to shared pointers?
(2015-08-30, 13:42)Montellese Wrote: [ -> ]I've also done some more runtime testing on the emulators and every now and then when I stop an emulator (doesn't matter which one) it crashes when calling Destroy() on game.libretro. Couldn't figure out yet how to reliably reproduce this. I just start and stop the emulator a lot until it happens. Need to setup game.libretro for debugging.
Furthermore I'm getting the feeling that input delay gets worse the longer I'm playing in an emulator. When starting Super Mario Bros. in level 1 input is perfectly fine but when reaching level 4 there's a huge lag and some button presses aren't detected at all anymore (especially when I'm pressing multiple buttons at once like running and jumping etc. I'm not really sure if it has anything to do with how long the emulator is running but I've never noticed any problems after starting fresh.
How do you set up add-ons for debugging on windows? I tried
setting cmake params to debug, but the resulting DLLs don't compile successfully.
9f99b1b should fix your deadlock... or come close... too tired to verify
(2015-08-28, 13:38)CrispyXUK Wrote: [ -> ]I have about 20 odd controllers so I'll certainly do some testing
Is there an easy way to get the "Games" menu into the amber skin btw?
Easy... no. Amber needs new windows to support games. This isn't hard to do; I'm not a skinner, i just copy/paste/tweaked some existing xml files.
If you or the amber author wants to add game support, you can see the modifications to confluence in the RetroPlayer patch:
https://github.com/garbear/xbmc/commits/7e24843 . Commits
0004, 0005, 0007 and 0011 modify confluence.
EDIT: RetroPlayer's GUI code is horribly incomplete atm. When it's more finalized, I'll post in the skin subforum all the steps needed for game support
(2015-08-30, 14:10)garbear Wrote: [ -> ]Good point, asynchronous scanning only happens for buses that don't set m_bNeedsPolling to false. Seems kind of odd to couple the scan thread to the update model. The add-on bus left m_bNeedsPolling as true, so it was scanned asynchronously. Which was probably an oversight, as it was in the application bus.
Well thinking about it I realised that it's not that odd. What happens is
- when the bus doesn't require polling (because it can rely on events) it considers the call to TriggerDeviceScan() as a kind of forced-scan (which certainly makes sense during startup because you can't expect to receive events for previously connected peripherals
- when the bus requires polling it asynchronously triggers an early scan (earlier than the polling interval)
The problem is that in case of no polling the device scan is performed synchronously and that the device scan is also triggered for these busses even though they should be able to rely on receiving events.
Does that make sense?
(2015-08-30, 14:10)garbear Wrote: [ -> ]The biggest offender is CPeripherals::GetPeripheralsWithFeature(). Any peripheral handling that occurs outside CPeripherals right now (configuration GUI) is unsafe. What if I changed these all to shared pointers?
Well the whole thing depends on how startup and shutdown are handled as that's the only place where m_busses is really modified (i.e. busses added or removed). The startup order probably shouldn't be an issue but the shutdown order needs to make sure that anything using these CPeripheralBus and CPeripheral instances need to be destroyed before destroying CPeripherals.
(2015-08-30, 14:10)garbear Wrote: [ -> ]How do you set up add-ons for debugging on windows? I tried setting cmake params to debug, but the resulting DLLs don't compile successfully.
I've had it setup once but it wasn't that easy. You don't really need to build for Debug because we also include debug symbols in release builds (to be able to get minidumps from releases). I'll try to set it up again and will write a step by step guide once I've got it running again.
I noticed Kodi still crashes when I try to exit (Kodi is not responding). I thought this was fixed a few builds ago?
It's back since the rebase but I haven't had time to look into it yet.
(2015-08-30, 14:10)garbear Wrote: [ -> ]How do you set up add-ons for debugging on windows? I tried setting cmake params to debug, but the resulting DLLs don't compile successfully.
So here goes:
- change addon definitions to file:///....
- open tools\windows\prepare-binary-addons-dev.bat and change -DCMAKE_BUILD_TYPE=Debug ^ to -DCMAKE_BUILD_TYPE=Release ^
- run tools\windows\prepare-binary-addons-dev.bat (you can pass a list of addons to build)
- open project\cmake\addons\build\kodi-addons.sln and build the solution (often need to build twice)
- add project\cmake\addons\build\<addon-id>-prefix\src\<addon-id>-build\<addon-id>.vcxproj to the solution
- build the solution (unfortunately this won't package and copy the addons to the addons directory)
- set any breakpoints in the addon code and run Kodi
- for installing the addons after building either create your own post build event or open project\cmake\addons\build\<addon-id>-prefix\src\<addon-id>-build\<addon-id>.sln and build the INSTALL project
Hope this works for you as well. I've used it to debug the XInput performance issues.
Hi everyone .
I'm a little lost, I'm new to this forum.
I want to install "Retroplayer" in my Kodi. The problem is that I find the zip in the post add-on, just an "EXE" to "Windows". I do not want to reinstall full Kodi, because I do not want to lose my settings, video library, etc.
There is a "step by step" to install "Retroplayer" ?.
Thanks and sorry for my bad English.
Retroplayer is still in heavy development, I would not install it over your current install.
Best to put it on a new machine for testing.
RetroPlayer should be safely interchangeable with the version it's based on (which I include in the installer filename), currently 15.1
This means that you can install retroplayer over 15.1, then revert back to 15.1, without losing any settings. Any game-related settings created by RetroPlayer should be safely ignored by vanilla 15.1
(2015-09-10, 10:56)garbear Wrote: [ -> ]RetroPlayer should be safely interchangeable with the version it's based on (which I include in the installer filename), currently 15.1
This means that you can install retroplayer over 15.1, then revert back to 15.1, without losing any settings. Any game-related settings created by RetroPlayer should be safely ignored by vanilla 15.1
I do this roughly every other day. Seems to work pretty well.
(2015-09-10, 10:56)garbear Wrote: [ -> ]RetroPlayer should be safely interchangeable with the version it's based on (which I include in the installer filename), currently 15.1
This means that you can install retroplayer over 15.1, then revert back to 15.1, without losing any settings. Any game-related settings created by RetroPlayer should be safely ignored by vanilla 15.1
Thanks for your reply.
My version 15.1 Kodi is stable. I understand that you just have to run the EXE, and this does not erase nor any of my current unconfigures Kodi. True?
With Retroplayer need emulador.exe of each video-game? or just I need the ROMs?
It will be easier to "Rom Collection Browser"?
The point of retroplayer is that you should not need any additional applications. Everything runs inside Kodi. So you only need the ROMs.
With that said, at the moment only NES, GBA, and... maybe that's it(?) are working with retroplayer, so if you want to play more using retroplayer, you'll need to wait until the various cores for other systems are ported.
I don't have a ton of experience with RCB, but I think it can work with both retroplayer and external exe emulators. You'll have to ask in that thread though.
Guys, are you not going to do a build for Android (ARM)
I sure would appreciate it...
Thanks!