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

Certain systems dont work from NFS share


  • Global Moderator

    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 ?



  • @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?


  • Global Moderator

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



  • @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?


  • Global Moderator

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



  • @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
    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?


  • Global Moderator

    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.



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


  • Global Moderator

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



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

    strace emulationstation


  • Global Moderator

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


  • @mitu
    Ok the output of that command is here:

    https://pastebin.com/ZY6KrpKS


  • Global Moderator

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



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



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


  • Global Moderator

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



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.