[SOLVED] Zipped roms crash N64 core (and maybe others)

Libretro Lakka
#1

The RetroArch rom scanner happily locates Nintendo 64 roms within zip files (ie, your N64 roms are all *.zip archives with one rom inside) and allows you to select them. However, the N64 fails to launch and the UI crashes (segfaults)

The forums have a handful of posts describing similar behavior (and some upset users). Since I, too, was seeing the N64 core (mupen64plus_libretro.so) crash upon launching any N64 rom, and other seemingly skilled forum members were not, I decided to dig into it a bit.

To confirm crashing behavior (from command line accessed via ssh)… [ul] [li]Reboot your device[/li][li]ssh into your device[/li][li]stop the UI service[/li][li]start the UI again in interactive mode[/li][/ul]

$> systemctl stop retroarch
$> retroarch --menu

Then, use the UI to navigate to any N64 rom that has caused your UI to crash The relevant output is something like the following (emphasis mine)


RetroArch [INFO] :: Using content: /storage/roms/N64/Donkey Kong 64 # N64.zip#Donkey Kong 64 # N64.N64.
RetroArch [INFO] :: arg #0: retroarch
RetroArch [INFO] :: arg #1: /storage/roms/N64/Donkey Kong 64 # N64.zip#Donkey Kong 64 # N64.N64
RetroArch [INFO] :: arg #2: -s
RetroArch [INFO] :: arg #3: /storage/savefiles
RetroArch [INFO] :: arg #4: -S
RetroArch [INFO] :: arg #5: /storage/savestates
RetroArch [INFO] :: arg #6: -c
RetroArch [INFO] :: arg #7: /storage/.config/retroarch/retroarch.cfg
RetroArch [INFO] :: arg #8: -L
RetroArch [INFO] :: arg #9: /tmp/cores/mupen64plus_libretro.so
RetroArch [INFO] :: arg #10: -v
RetroArch [INFO] :: Threaded video stats: Frames pushed: 689, Frames dropped: 0.
RetroArch [INFO] :: Monitor FPS estimation is disabled for threaded video.
RetroArch [INFO] :: Redirecting save file to "/storage/savefiles/Donkey Kong 64 # N64.srm".
RetroArch [INFO] :: Redirecting savestate to "/storage/savestates/Donkey Kong 64 # N64.state".
RetroArch [INFO] :: === Build =======================================RetroArch [INFO] :: [CPUID]: Vendor: GenuineIntel
RetroArch [INFO] :: [CPUID]: Features: MMX MMXEXT SSE SSE2 SSE3 SSSE3
MMX MMXEXT SSE1 SSE2 SSE3 SSSE3 Built: Nov 24 2015
RetroArch [INFO] :: Version: 1.3.0
RetroArch [INFO] :: Git: 3c89451
RetroArch [INFO] :: =================================================
RetroArch [INFO] :: [CPUID]: Vendor: GenuineIntel
RetroArch [INFO] :: [CPUID]: Features: MMX MMXEXT SSE SSE2 SSE3 SSSE3
RetroArch [INFO] :: Threaded rarch_task started
RetroArch [INFO] :: Loading dynamic libretro core from: "/tmp/cores/mupen64plus_libretro.so"
RetroArch [INFO] :: Environ SET_VARIABLES.
RetroArch [INFO] :: Version of libretro API: 1
RetroArch [INFO] :: Compiled against API: 1
RetroArch [INFO] :: Environ GET_LOG_INTERFACE.
RetroArch [INFO] :: Environ GET_PERF_INTERFACE.
RetroArch [INFO] :: Environ SET_PIXEL_FORMAT: XRGB8888.
RetroArch [INFO] :: Environ GET_RUMBLE_INTERFACE.
[B]RetroArch [INFO] :: Loading content file: /storage/roms/N64/Donkey Kong 64 # N64.zip#Donkey Kong 64 # N64.N64.[/B]
[B]RetroArch [ERROR] :: Could not read content file "/storage/roms/N64/Donkey Kong 64 # N64.zip#Donkey Kong 64 # N64.N64".[/B]

You may be able to CTRL-C and then relaunch your UI and try again, but I needed to reboot

$> reboot

Now, unzip a problematic rom and relaunch the UI in interactive mode as above. Then, launch the unzipped rom. (I rescanned the dir containing the zipped roms and the now unzipped rom, then confirmed which identical menu choice - in my case “Donkey Kong 64” - was the unzipped rom by looking at the contents of “/storage/playlists/Nindendo - Nintendo 64.lpl”. In hindsight, it would have been easier to move the zipped rom out of the roms folder prior to rescanning, leaving only the unzipped one to select from the menu.)

The unzipped rom launches without a problem.

This might be the problem other users had experienced in the past. Unzipping the roms solved the crashing problem for me.

#2

To quickly unzip a directory full of zipped roms. Handles file names with spaces just fine.

$> cd /storage/roms/[I]<the-directory-containing-zipped-roms>[/I]
$> ls *.zip | while read FILE; do unzip "$FILE"; done

This lists (ls) all files ending with “.zip” and pipes that list to a while-loop. During each iteration of the while-loop, one file name from the list is stored in a variable named FILE, and unzip “$FILE” unzips that file. The only thing you need to change in the snippit above is <the-directory-containing-zipped-roms>.

You can then PERMANENTLY delete the zip archives with $> rm *.zip MAKE SURE YOU BACK UP ANYTHING YOU WANT TO KEEP.

#3

Looks like there is something wrong in the playlist files.

See, when I launch a PC Engine rom, I see this in my log :

RetroArch [INFO] :: Using content: /home/kivutar/Jeux/roms/pce/1943 Kai (Japan).zip#1943 Kai (Japan).pce.RetroArch [INFO] :: arg #0: retroarch RetroArch [INFO] :: arg #1: /home/kivutar/Jeux/roms/pce/1943 Kai (Japan).zip#1943 Kai (Japan).pce RetroArch [INFO] :: arg #2: -c RetroArch [INFO] :: arg #3: /home/kivutar/.config/retroarch/retroarch.cfg RetroArch [INFO] :: arg #4: -L RetroArch [INFO] :: arg #5: /usr/lib/libretro/mednafen_pce_fast_libretro.so RetroArch [INFO] :: arg #6: -v

And in my playlist:

/home/kivutar/Jeux/roms/pce/1943 Kai (Japan).zip#1943 Kai (Japan).pce 1943 Kai (Japan) /usr/lib/libretro/mednafen_pce_fast_libretro.so Mednafen/Beetle PCE FAST FDE08D6D|crc NEC - PC Engine - TurboGrafx 16.lpl /home/kivutar/Jeux/roms/pce/Adventure Island (Japan).zip#Adventure Island (Japan).pce

The # is used to separate the name of the zip and the name of the file in the zip.

But in your case, it looks like the name of the zip contains a # that should be escaped somehow. Is it the case?

#4

There was, indeed, a #-sign in the filename for both the zip archive and the file it contained. That might have been too many #-signs for the playlist file to handle. Especially given the #-sign has syntactic significance in the playlist.

In my case, the naming scheme that broke normal behavior was literally this: Donkey Kong 64 # N64.zip (the zip archive) Donkey Kong 64 # N64.N64 (the file it contained)

So, zip archives weren’t the problem after all. It was zip archives that have a #-sign in the archive’s file name, and/or in the name of the file contained within the archive.

Maybe someone with this exact problem will find this post someday.

#5

I can’t launch N64 roms either, i tried to unzip them but later was it was not the problem. Whenever I launch a n64 rom I get a segmentation fault (core dumped). I first tought it was just the CPU that couldn’t handle it, but it is an Intel Pentium T3400 (dual core at 2.16 ghz), it should handle it, right ? I have 4 gigs of ram and a GMA 4500M, i’m running Lakka on a live USB. I’m sorry this is a bit off-topic but i can’t create a topic yet and i’m really wondering what goes wrong. Thank you !