Certain systems dont work from NFS share

mitu

Is the path correct - i.e. /mnt/WDMYCLOUD/RetroPie/roms/arcade/mk.zip does really exist ? Can you run zipinfo /mnt/WDMYCLOUD/RetroPie/roms/arcade/mk.zip and get the file's contents ?

henryjfry

Yep it does exist:

zipinfo /mnt/WDMYCLOUD/RetroPie/roms/arcade/mk.zip
Archive: /mnt/WDMYCLOUD/RetroPie/roms/arcade/mk.zip
Zip file size: 5493469 bytes, number of entries: 17
-rw---- 0.0 fat 262144 b- defX 96-Dec-24 23:32 mks-u12.rom
-rw---- 0.0 fat 262144 b- defX 96-Dec-24 23:32 mks-u13.rom
-rw---- 0.0 fat 262144 b- defX 96-Dec-24 23:32 mks-u3.rom
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug12.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug14.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug16.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug17.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug19.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug20.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-ug22.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj12.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj14.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj16.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj17.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj19.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj20.bin
-rw---- 0.0 fat 524288 b- defX 96-Dec-24 23:32 mkt-uj22.bin
17 files, 8126464 bytes uncompressed, 5491733 bytes compressed: 32.4%

Although what has been happening is that the NFS share is locked when it tries to open one of the offending roms on my NAS. So i had to power off and power back on the Vero4k before that command worked as gets stuck on the "Press a to configure" loading screen/black screen (depening on whether or not A is pressed).

But the exact same roms moved from the NAS to a folder in the Vero4k's /home/ drive work fine.

mitu

Can you run the emulator with verbose logging (toggled from the Runcommand launch menu) and post the detailed log (from /dev/shm/runcommand.log) to pastebin.com ?

henryjfry

@mitu
Ok so here is a log for the current ROM from the NFS share:
https://pastebin.com/rxGizHUq

And the same ROM from the folder: /home/osmc/RetroPie/roms/arcade

https://pastebin.com/HniTe73T

So it looks like on the NFS share it cant get the CRC check?

mitu

@henryjfry said in Certain systems dont work from NFS share:

So it looks like on the NFS share it cant get the CRC check?

No, it doesn't get to that. I think it's because the MAME core loads the .zip itself, as opposed to other cores relying on RetroArch for unpacking. Can you try and remove the nolock mount option, remount the share and see if it makes a difference ?

henryjfry

@mitu
I tried removing the nolock option and reverting back to the network share for arcade and it didnt make any difference. The log still doesnt report any crc check.

So i take it that means any game in a zip file would need to be on a local folder?

Edit:
I got a psx game downloaded and the cue file opens fine so it appears to be just a zip issue.
Would sim linking folders to my NFS share work any better?
Or setting it up as samba rather than NFS?

mitu

@henryjfry said in Certain systems dont work from NFS share:

So i take it that means any game in a zip file would need to be on a local folder?

No, just the arcade ROMs.

henryjfry

@mitu
Well N64 ROMs (z64 and N64) also only load from local folders with mupen64 (ie not lr- emulators which don't work on my system for N64)

Although as that's non retroarch its presumably the same sort of issue

henryjfry

@henryjfry
I did just try downloading r-type as a mame ROM and it was able to run a CRC check, but they failed as the ROM appears to be missing files.
So it seems to be only larger zip files with the problem.

Would a later version of mame work better?

mitu

So it seems to be only larger zip files with the problem.
Would a later version of mame work better?

That's not how arcade ROMs work - take a look at https://retropie.org.uk/docs/Arcade/ and apply the advice given there.

henryjfry

@mitu
Yeah I've read that, I checked the list to find some working/compatible games.
But I was commenting that the zipped ROMs can't seem to do a CRC check on the NFS share. However an r-type zipped rom on the NFS share did a CRC check as reported by the log but then failed for a different reason.

And I thought that maybe the zip file being that much smaller was the reason. Don't know much about CRC but there shouldnt be any reason why a correctly mounted share wouldn't work.

But I have been able to get the other ROMs to play so it's not like it's improperly setup.
The only difference is where the ROMs are stored.

Except for r-type, which must be bad, but did get past the CRC part. As I stated.

mitu

@henryjfry said in Certain systems dont work from NFS share:

But I have been able to get the other ROMs to play so it's not like it's improperly setup.
The only difference is where the ROMs are stored.

The size may be a factor. Can you run a strace on the RetroArch's process to see where it gets stuck ?

henryjfry

@mitu
I've not used strace before, would it be:

strace emulationstation

mitu

@henryjfry said in Certain systems dont work from NFS share:
You'd be better off exiting EmulationStation and tracing the emulator directory:


strace -f /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame2010/mame2010_libretro.so --config /opt/retropie/configs/arcade/retroarch.cfg "/mnt/WDMYCLOUD/RetroPie/roms/arcade/mk.zip"

henryjfry

@mitu
Ok the output of that command is here:

https://pastebin.com/ZY6KrpKS

mitu

@henryjfry The logs shows the read call hangs in the middle of reading the file, after about 3 mb read:

[pid  1822] _llseek(3, 0, [0], SEEK_SET) = 0
[pid  1822] fstat64(3, {st_mode=S_IFREG|0777, st_size=5493469, ...}) = 0
[pid  1822] _llseek(3, 5488640, [5488640], SEEK_SET) = 0
[pid  1822] read(3, "\10\227\266\\\322\315\201\3415\247\2576ft\243_w\235W\\\353\217\233G}\302&\311\0348\265\353"..., 4829) = 4829
[pid  1822] _llseek(3, 0, [0], SEEK_SET) = 0
[pid  1822] mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xece99000
[pid  1822] read(3, "PK\3\4\24\0\2\0\10\0\0\274\230!\371\327\213%9\230\3\0\0\0\4\0\v\0\0\0mk"..., 1048576) = 1048576
[pid  1822] read(3, "+#\326\26\305\25\377\221\346\17\250\363\255d\216\335\304\362\310!\3\31\26\345\35![\354\227\r\213\30"..., 1048576) = 1048576
[pid  1822] read(3, "#\355\3061\214`\222\r\216\34\203\4u)\210\343\0\366\27\302\364\315\220\323\342\0051$\345\240\3165"..., 1048576) = 1048576
[pid  1822] read(3,

We could look at more logs, but without being able to reproduce this error I'm grasping at straws here.

EDIT: Check if the .zip file is not at fault, the situation described here. While the error is more explicit on mame2003, I might be that mame2010 has a different behavior and doesn't log the error. That still doesn't explain why the other ROM types (N64) won't work, but it's worth a shot.

henryjfry

@mitu
So i changed the default mame emulator to Mame-2003 and re-ran that rom from the NFS share:
strace /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mame2003/mame2003_libretro.so --config /opt/retropie/configs/arcade/retroarch.cfg "/mnt/WDMYCLOUD/RetroPie/roms/arcade/mk.zip" --appendconfig /dev/shm/retroarch.cfg

And the output of the strace is here:

https://pastebin.com/BvxB2jqk

It seems to be fairly similar to the previous output.

henryjfry

@mitu
I did some googling about mmap2, NFS and zip and found some stuff which seemed to suggest that it is the mount point and sync/async which might be the culprit.
Would adding async to my fstab improve things do you think?

(trying to find exactly what async would do it does appear to be the default setting, so this may be irrelevant).

edit: And/or "local_lock=flock" ??
as per https://github.com/ValveSoftware/steam-for-linux/issues/5788

mitu

@henryjfry said in Certain systems dont work from NFS share:

Would adding async to my fstab improve things do you think?

The async option would be ok, but I don't know if it would solve anything. You can just try different mount options - the less mount options you have, the easier it would be to test different combinations.