Retroarch: Disk swapping causes RetroArch to restart when "rgui_browser_directory" is set in CFG files.

Created on 3 Nov 2017  路  14Comments  路  Source: libretro/RetroArch

Description

Disk swapping causes RetroArch to restart when "rgui_browser_directory" is set in CFG files.

Expected behavior

When a new disk image is appended RetroArch should not restart.

Actual behavior

When a new disk image is appended RetroArch restarts if the option "rgui_browser_directory" has been set in a retroarch.cfg file. Commenting out this line so it is default causes the issue to stop.

Steps to reproduce the bug

  1. Add or update the "rgui_browser_directory" setting to something other than default
  2. Load a core that supports disk swapping (blueMSX, PCSX-Rearmed)
  3. Go to RGUI -> Disk Controls -> Append Disk Image and select a file. RA restarts immediately.

Version/Commit

RetroArch: v1.6.7 / c96a9db
BlueMSX: 41f7f15
PCSX-Rearmed: c7dde5e
Also verified it occurred on the release build of v1.6.7

Environment information

  • OS: Windows 10 x64, RPI3 Jessie
major

All 14 comments

I haven't verified the reason myself, but I can verify that RetroArch does indeed reset the emulator on disk insertion through the disk menu.

@msheehan79 and @meepingsnesroms Is this still an issue? I don't have any convenient saves to test...

It's actually the other way around, it happens when it's not set

@orbea Sorry for not getting back to this sooner, have not had much time to spend on my PC lately.

I just downloaded the latest RA nightly (Win x64, build e7befaba37) and the current blueMSX core and retested. Appending a disk via the GUI still resets RetroArch so it does appear to still be an issue. However I tried both with & without rgui_browser_directory set in my cfg file and it reset both ways now, not sure if that behavior changed between 1.6.7 and 1.7.5. Either way, it is still an issue as of 1.7.5 nightlies. For my setup I switched to using m3u playlist files as this is a workaround for multi-disk games if the core supports that format.

If you want me to test anything specific just let me know and I can do my best to help.

Thanks for testing, it really needs someone with the experience and time to look at the code. I am not sure I will get anywhere, but if someone can provide a save that makes it easy to reproduce I will try.

I don't think you need a save state to verify this issue - the issue appears as soon as you try to append a disk image to the list, before you are even asked to eject/swap disks in the UI.

For my test this evening and when I had tested some other disk swap updates back when i originally created this issue I had used a 2 disk MSX game called Gandhara, because disk 1 is just an intro sequence and you are prompted for Disk 2 pretty much immediately after that so you don't have to burn a lot of time getting into the game before reaching a prompt to swap disks.

It is related but it doesn't happen this way (it happens when the dir is not set

@msheehan79 Maybe this might fix your issue too? https://github.com/libretro/RetroArch/issues/8071#issuecomment-456973431

@orbea I will give it a shot when I have a chance and will update this report either way. Thanks!

Thanks, I confirmed that it doesn't try to detect a core with the referenced PR, but I didn't play any content long enough to see a disk change yet.

So I just did a retest of the issue, first with the same build I had tested at the beginning of the month (e7befab) and again with the current nightly build 7ba6ffdfbe.

As it turns out, the restart issue only seems to happen when you try to append a disk that is inside a zip archive. When I extracted the files and appended the raw file it worked.

I could not at this point say if that was the case back when I originally opened the issue on v1.6.7. I did usually have my content zipped to save space as it was on a RPI3 with limited storage.

I am not sure if that would be considered a bug still or if it would be assumed that you cannot use zipped files for multi disk games. I can update the original report with this additional info if you think worthwhile?

Using zip files with bin/cue content is not recommended, but I'm not sure this extends to disk control in general as well.

However I can reproduce your issue if the appended disk is in a zip archive and it again it occurs with subystem content too so it should be fixed. I would suggest a new issue to make it clear what the remaining issue is.

Was this page helpful?
0 / 5 - 0 ratings