Some games load, some don't (NES/FCEUmm Core)
-
Well I gave up on trying to make this work. In the end, the only thing I could do was install the latest image (4.1) upgrade to 4.1.3 using the setup script, and reinstall roms, re-scrape data, re-config raspi system settings, re-add controllers...basically completely start over.
I've got things working now, but it was a ton of work and I'll have to think long and hard about ever upgrading RetroPie again.
-
Ok, after getting everything set up all over again, the problem has returned. I'm pulling my hair out in frustration and I'm more determined than ever to find the cause.
This affects several roms on my system, and the problem only shows up when the roms are zipped.
The verbose logs continue to show the runcommand "line 925/aborted" error.
If I launch into the emulator with a working zipped rom, I'm then able to load a non-working zipped rom inside of the libretro GUI, and it works there! It's only when attempting to launch from emulationstation that I have problems.
Could this libretro bug be to blame? https://github.com/libretro/RetroArch/issues/3783
How can I check if "cache_directory" is set to a valid dir? -
check your
configs/all/retroarch.cfg
- note that runcommand creates the/tmp/retroarch
directory when it launches and removes it afterwards. -
Thanks for that. The cache directory is definitely set in the cfg. I even tried changing it temporarily to a persistent dir, and no change.
So next I tried manually entering the same command that runcommand is running on the command line, based on the error log:
/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-fceumm/fceumm_libretro.so --config /opt/retropie/configs/nes/retroarch.cfg "/home/pi/RetroPie/roms/nes/Ice Climber (USA, Europe).zip" --verbose --appendconfig /dev/shm/retroarch.cfg
This is the output:
http://pastebin.com/C36xN96WCompare that with the output of a zipped rom that does work properly:
/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-fceumm/fceumm_libretro.so --config /opt/retropie/configs/nes/retroarch.cfg "/home/pi/RetroPie/roms/nes/Tetris (USA).zip" --verbose --appendconfig /dev/shm/retroarch.cfg
The error I'm seeing is "*** Error in `/opt/retropie/emulators/retroarch/bin/retroarch': free(): invalid pointer: 0x01ff8979 ***"
Is this definitive proof that it's a Retroarch bug? If so, I can file a report with them.
-
When you compare the two.. the one that works continues right after checking for
Environ GET_VARIABLE fceumm_overclocking:
. The next step that is failing on the one that doesn't work isEnviron GET_VARIABLE fceumm_overscan:
. So maybe it's an overscan setting? -
Good eyes, thank you.
Ok, I just enabled overscan in /boot/config.txt and rebooted.
Didn't do much. Same error, slightly different pointer address:
*** Error in `/opt/retropie/emulators/retroarch/bin/retroarch': free(): invalid pointer: 0x01cb89e9 ***I'm not sure if this is a retroarch bug or a fceumm core bug.
-
At least the
invalid pointer
error is now pointing to a different address..0x01cb89e9
vs
0x01ff8979
The 2nd to last digit changed :)
-
I submitted this as a Retroarch bug. Hopefully I don't get laughed out of their bug tracker for not knowing what I'm doing.
-
I experienced the same bug with lr-fceumm using a no-intro set. I can confirm it's specific to lr-fceumm (lr-nestopia works fine).
One foolproof workaround is use an unzipped rom, or to store (zero compression) the rom in the zip. The commands below will re-zip the files at zero compression (so no extra scraping needs to be done, gamelist tweaking, etc).
As always, make a backup first.
sudo apt-get install zip cd ~/RetroPie/roms/nes mkdir old for f in *.zip; do unzip "$f"; mv "$f" old; zip -0 "${f%.*}".zip "${f%.*}".nes; mv "${f%.*}".nes old; done
The old zip files will be placed in the "old" folder. They can be removed when you're satisfied with the new set.
-
Is there a fix for this yet? I just spent ages setting up retropie only to find that most of my nes roms are failing to load with a "failed to extract content" error followed by an "invalid pointer" error. Nothing wrong with the zips as they unzip fine and they worked in my other retropie setups
I'm sure starting again from scratch will fix, but I really don't want to do that. I've spent days on this setup :(
-
@chromium there is a retroarch ticket link above - doesn't look resolved yet.
Unpack your ROMs or use another emulator?
-
@BuZz said in Some games load, some don't (NES/FCEUmm Core):
@chromium there is a retroarch ticket link above - doesn't look resolved yet.
Unpack your ROMs or use another emulator?
I'm stubborn and am trying to fix it properly :)
I had this issue with a new Retropie install a couple of days ago and then I updated everything and the problem went away. Updating isn't helping in this one though. I tried updating from binaries and sources for both retroarch and lr-fceumm with no joy.
I actually only get the invalid pointer error from command line. If I run from emulationstation I don't get that, I just get "Aborted."
Eg.
RetroArch [libretro INFO] :: Loading /tmp/retroarch/1942 (Japan, USA).nes...
RetroArch [libretro INFO] :: PRG ROM: 2 x 16KiB
RetroArch [libretro INFO] :: CHR ROM: 1 x 8KiB
RetroArch [libretro INFO] :: ROM CRC32: 0x171251e3
RetroArch [libretro INFO] :: ROM MD5: 0x0b66fdf88964235c434daff62837af60
RetroArch [libretro INFO] :: Mapper #: 0
RetroArch [libretro INFO] :: Mapper name: NROM
RetroArch [libretro INFO] :: Mirroring: Horizontal
RetroArch [libretro INFO] :: Battery-backed: No
RetroArch [libretro INFO] :: Trained: No
RetroArch [libretro INFO] ::
RetroArch [INFO] :: Environ GET_VARIABLE fceumm_palette:
RetroArch [INFO] :: asqrealc
RetroArch [INFO] :: Environ GET_VARIABLE fceumm_nospritelimit:
RetroArch [INFO] :: disabled
RetroArch [INFO] :: Environ GET_VARIABLE fceumm_overclocking:
RetroArch [INFO] :: disabled
/opt/retropie/supplementary/runcommand/runcommand.sh: line 947: 8304 Aborted /opt/retropie/emulators/retroarch/bin/retroarch --verbose -L /opt/retropie/libretrocores/lr-fceumm/fceumm_libretro.so --config /opt/retropie/configs/nes/retroarch.cfg "/home/pi/RetroPie/roms/nes/1942 (Japan, USA).zip" --appendconfig /dev/shm/retroarch.cfgSo it looks like it's unzipping the rom ok because it's reading information from the rom. Pretty weird. Not sure why zipping with no compression works. Everything works ok in nestopia.
-
@chromium also make sure /tmp/retroarch exists (runcommand makes it usually), if starting from command line without using runcommand. That's the default path for unpacking.
PS. Put logs in a code block when posting to forum.
-
I may look into this issue at some point, but it might help to add more info to ticket as they still have it marked down as unconfirmed.
-
@BuZz said in Some games load, some don't (NES/FCEUmm Core):
@chromium also make sure /tmp/retroarch exists (runcommand makes it usually), if starting from command line without using runcommand. That's the default path for unpacking.
PS. Put logs in a code block when posting to forum.
I checked and it does get created because I can see the unzipped rom there for working games while they are running and then it disappears once I quit. I'm assuming for games that don't work it gets cleaned up as soon as it fails because if you look at the log I posted before you'll see it actually reads information from the unzipped from in /tmp/retroarch
-
This is insane. I tried my other SD card where nes games work in lr-fceumm and I compared the retroarch binaries, the fceumm_libretro.so binaries, the runcommand.sh and all the config files. EVERYTHING was identical. So I have no idea what the problem is. It doesn't seem to be retroarch, lr-fceumm or runcommand, what on earth else can it be?
-
One other interesting tidbit is that regardless of the zip file used (normally compressed file which fails to load or one using store [0% compression]), they both write the .nes file correctly to /tmp/retroarch -- same md5. It appears that something is continuing to read the original zip file.
-
@synack said in Some games load, some don't (NES/FCEUmm Core):
One other interesting tidbit is that regardless of the zip file used (normally compressed file which fails to load or one using store [0% compression]), they both write the .nes file correctly to /tmp/retroarch -- same md5. It appears that something is continuing to read the original zip file.
Yep, this is the bit that I can't understand. The zip file is being unzipped correctly in both cases. I added a comment saying that yesterday in the ticket that was raised. It makes no sense. Also my other fully update retropie setup is running all these roms fine. Same binaries, same kernel. It's madness :) I'll probably use that one, but I have put a lot more work into the one with the lr-fceumm issue. I might just rezip all my roms with 0 compression, but I'd really love to know what this issue is :)
-
just fyi, the issue has been identified and fixed
-
@synack That didn't fix the free crash on RetroPie (there was a separate issue though also) but I have debugged it and worked out the problem. Updating from source should sort it now. (binaries will be updated in a moment).
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.