RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    Some games load, some don't (NES/FCEUmm Core)

    Scheduled Pinned Locked Moved Help and Support
    nesretroarchcrashabort
    49 Posts 11 Posters 22.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • synackS
      synack @bmn001
      last edited by synack

      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.

      1 Reply Last reply Reply Quote 0
      • C
        chromium
        last edited by chromium

        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 :(

        BuZzB 1 Reply Last reply Reply Quote 0
        • BuZzB
          BuZz administrators @chromium
          last edited by BuZz

          @chromium there is a retroarch ticket link above - doesn't look resolved yet.

          Unpack your ROMs or use another emulator?

          To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

          1 Reply Last reply Reply Quote 0
          • C
            chromium
            last edited by

            @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.cfg

            So 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.

            BuZzB 1 Reply Last reply Reply Quote 0
            • BuZzB
              BuZz administrators @chromium
              last edited by BuZz

              @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.

              To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

              C 1 Reply Last reply Reply Quote 0
              • BuZzB
                BuZz administrators
                last edited by

                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.

                To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                1 Reply Last reply Reply Quote 0
                • C
                  chromium @BuZz
                  last edited by chromium

                  @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

                  1 Reply Last reply Reply Quote 0
                  • C
                    chromium
                    last edited by

                    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?

                    synackS 1 Reply Last reply Reply Quote 0
                    • synackS
                      synack @chromium
                      last edited by

                      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.

                      C 1 Reply Last reply Reply Quote 0
                      • C
                        chromium @synack
                        last edited by

                        @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 :)

                        synackS 1 Reply Last reply Reply Quote 0
                        • synackS
                          synack @chromium
                          last edited by

                          just fyi, the issue has been identified and fixed

                          https://github.com/libretro/libretro-fceumm/commit/821ca02

                          BuZzB 1 Reply Last reply Reply Quote 0
                          • BuZzB
                            BuZz administrators @synack
                            last edited by BuZz

                            @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).

                            To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                            synackS 1 Reply Last reply Reply Quote 3
                            • synackS
                              synack @BuZz
                              last edited by

                              @BuZz Thank you. Appreciate the time and effort you put in to solve these type of issues.

                              1 Reply Last reply Reply Quote 2
                              • C
                                chromium
                                last edited by chromium

                                Great work @BuZz!

                                Out of interest why do some zips work and others don't and why did zipping with 0 compression make the issue go away? Also, why could I not reproduce the issue on my other retropie setup that had the same retroarch and fceumm_libretro.so binaries?

                                BuZzB 1 Reply Last reply Reply Quote 0
                                • BuZzB
                                  BuZz administrators @chromium
                                  last edited by

                                  @chromium Luck. Well, it was due to some code that after allocating some memory, tried to align a pointer. If the pointer got changed it would fail (since the wrong pointer would be used to free the memory). The code was wrong as the free should have been done on the original pointer value.

                                  That's why when bisecting it, a completely unrelated piece of code in retroarch seemed to be the problem, as it just affected where the memory was allocated, but the real problem was the code that tried to align the memory block.

                                  To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    bmn001
                                    last edited by

                                    Pretty dang thrilled that this got fixed. Awesome sauce. Thanks @buzz for the troubleshooting.

                                    1 Reply Last reply Reply Quote 0
                                    • hansolo77H
                                      hansolo77
                                      last edited by

                                      I'll mark this thread as solved then unless somebody has reason not to...

                                      Who's Scruffy Looking?

                                      1 Reply Last reply Reply Quote 0
                                      • J
                                        jyo
                                        last edited by jyo

                                        I had been having this problem on PI3 and have been solving it by updating from Binary.
                                        I am having these issues on Pi ZERO still.
                                        i dont have a WIFI adapter, so what i have been doing is putting my SD card in a Pi 2 (since it uses the same retropie) and interestingly enough updating from binary fixed the LR-FCEUMM issue while in the PI2......but when i put the card back in my Zero, i get the same issues.
                                        pretty stumped

                                        markyh444M 1 Reply Last reply Reply Quote 0
                                        • markyh444M
                                          markyh444 @jyo
                                          last edited by

                                          @jyo Pi2 and Pi Zero don't use the same image or RetroPie build mate.

                                          Pi Zero is a Pi 1 in a smaller form factor.

                                          I'd suggest opening a new topic with your details in as it is likely going to be a different fix for this.

                                          Retropie in a NES - Pi 3 with Mausberry circuit shutdown switch wired to buttons and 8bitdo NesPro30 controller
                                          Retropie in a Saturn Controller - Pi Zero, GPIO controls using DB9 driver
                                          Retropie in a PSX - Pi3
                                          https://markyh444.wordpress.com

                                          J 1 Reply Last reply Reply Quote 0
                                          • J
                                            jyo @markyh444
                                            last edited by

                                            @markyh444 oh wow you're totally right.
                                            so i made the image for the pi 0/1.
                                            but then im doing the update from binary in a pi2 since i couldnt get the wifi adapter i had to work.
                                            shouldnt it be downloading the right file as its off the right image, or because the SD is in a pi2, it is downloading the files for a pi2/3?

                                            markyh444M 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post

                                            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.