Certain systems dont work from NFS share

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.