ScummVM (on RetroPie) trouble with games on a samba share

Ask for help with ScummVM problems

Moderator: ScummVM Team

Post Reply
wintersdark
Posts: 4
Joined: Sun Jun 17, 2018 4:13 pm

ScummVM (on RetroPie) trouble with games on a samba share

Post by wintersdark »

Ok, I'm trying to add my ScummVM games to RetroPie. All my roms - including my ScummVM games - are on a Samba share. I've successfully added Arcade (via FBA), nes, snes, megadrive, etc with no problems - the share is mounted with user pi on the retropie having read and write permissions. My process to date has been removing the directories in ~/RetroPie/roms/ and replacing them with links to the appropriate folders in /mnt/ROMs/ (the samba share). This has worked thus far for every system.

However, upon linking ~/RetroPie/roms/scummvm to /mnt/ROMs/scummvm-extracted, installing ScummVM and launching +ScummVM GUI, I cannot navigate into /RetroPie/roms/scummvm - the folder is greyed out. I suspect this is due to ScummVM itself having issues with links.

So, instead, I navigated to /mnt/ROMs/scummvm-extracted directly, and could indeed see all the folders for the games, and inside those folders all the files.

Attempts to add those games either one at a time in the specific folders, or via Mass Add, results in "ScummVM couldn't open the specified directory" (despite being able to see it's contents in the ScummVM file browser!)

I tried mounting the scummvm-extracted folder (where my games are) directly in ~/RetroPie/roms/scummvm, but got the same result.

I have confirmed I have r/w access to the share: I can drop to a command line, read, create, edit, and delete files in that share without issue.

If I just have ~/RetroPie/roms/scummvm as a local directory, and copy a game folder there, I can add the game and play normally.

However, my SD card is 16gb, and I have 78gb of scummvm games, so this isn't a sustainable method.

Any ideas as to how I can get ScummVM in RetroPie to use games on my network share?
User avatar
sev
ScummVM Lead
Posts: 2272
Joined: Wed Sep 21, 2005 1:06 pm
Contact:

Post by sev »

ScummVM and ROMs? Maybe it could be a good idea to refer to the Forum Rule #0?
User avatar
criezy
ScummVM Developer
Posts: 947
Joined: Sat Sep 23, 2006 10:41 am
Location: West Sussex, UK

Post by criezy »

I have seen users use 'ROMs' to mean copies on a hard drive from CDs, so I would not necessarily assume those are pirated copy. In this particular case it is possible that this is also the name of the directory that retropie expect for where to find the game data (I am not familiar with retropie, so I would not know).

As for the samba share and symbolic links, there is not much I can say. I have never noticed an issue myself, but I never tried using a samba share, and I am not sure I ever tried using symbolic links (and if I have it would be on macOS and not on Linux).
wintersdark
Posts: 4
Joined: Sun Jun 17, 2018 4:13 pm

Post by wintersdark »

Indeed, when retropie installs ScummVM, the default location ScummVM looks for data files is ~/RetroPie/roms/scummvm. I'm going with that, as it's just one less variable. I'm not asking for or offering pirated content, nor am I asking for assistance processing it.

The issue at hand is very simply getting ScummVM (on a raspbian install) to read game files from a network share, and more specifically the strange behavior of being able to see the files listed in the "Add Games" dialog, but then getting "Cannot access the specified directory" when I attempt to add those games.

Surely I'm not unique in running ScummVM on a device not capable of storing their games? I'm asking the RetroPie folks as well, of course, but as this is only applying to ScummVM's GUI specifically I figured this would be a good place to come ask.
digitall
ScummVM Developer
Posts: 1172
Joined: Thu Aug 02, 2012 1:40 pm

Post by digitall »

wintersdark: ScummVM does not have any specific code for SMB or other network shares in the standard builds we provide (with the exception of the Wii/Gamecube builds which have this as platform specific code for the reasons you indicate).

I suspect you should address any questions on this to the Retropie distribution maintainers as that sounds like an OS level issue with Samba share settings.

I haven't tried this myself, but it sounds like the issue you may be getting is this one:
https://unix.stackexchange.com/question ... hared-path
wintersdark
Posts: 4
Joined: Sun Jun 17, 2018 4:13 pm

Post by wintersdark »

digitall wrote:wintersdark: ScummVM does not have any specific code for SMB or other network shares in the standard builds we provide (with the exception of the Wii/Gamecube builds which have this as platform specific code for the reasons you indicate).

I suspect you should address any questions on this to the Retropie distribution maintainers as that sounds like an OS level issue with Samba share settings.
I do think it's an issue with the specific build (as it definitely feels like an issue with how it's interacting with the filesystem), but didn't know the Raspbian build wasn't a standard build you provide.
I haven't tried this myself, but it sounds like the issue you may be getting is this one:
https://unix.stackexchange.com/question ... hared-path
Nah, I'm familiar with that issue (and how to deal with it) - in this instance the symlink is just one of two ways things weren't working and is scummvm failing to follow a local symlink directed to the share itself (it treats the symlink as a file, when it should treat it as a directory). The other failure case doesn't involve symlink at all - navigating directly to the share and attempting to add games fails with a "cannot access the directory" error.

Thanks for your time, however, it is much appreciated. I'll keep searching, and once I figure it out, I'll post the results here in case anyone else has a similar issue.
wintersdark
Posts: 4
Joined: Sun Jun 17, 2018 4:13 pm

Solved!

Post by wintersdark »

So, the solution is fairly simple. Due to how ScummVM handles files, you need to mount the network share with the "noserverino" option in fstab to force the Pi to assign it's own inodes rather than use the server inodes for the share. I'm not sure why this is only a problem with ScummVM on the Raspberry Pi (but I suspect it's related to the Pi being 32 bit) but there you have it.

Once I did this, ScummVM was able to load game files of the network share without issue.
digitall
ScummVM Developer
Posts: 1172
Joined: Thu Aug 02, 2012 1:40 pm

Post by digitall »

wintersdark: Thanks for letting us know what the solution was. Reading the Samba mount.cifs manual page about this option, I think the issue is covered by the section headed "Inode Numbers":
https://www.samba.org/samba/docs/3.5/ma ... ifs.8.html

<snip>
INODE NUMBERS

When Unix Extensions are enabled, we use the actual inode number provided by the server in response to the POSIX calls as an inode number.

When Unix Extensions are disabled and "serverino" mount option is enabled there is no way to get the server inode number. The client typically maps the server-assigned "UniqueID" onto an inode number.

Note that the UniqueID is a different value from the server inode number. The UniqueID value is unique over the scope of the entire server and is often greater than 2 power 32. This value often makes programs that are not compiled with LFS (Large File Support), to trigger a glibc EOVERFLOW error as this won't fit in the target structure field. It is strongly recommended to compile your programs with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this problem. You can also use "noserverino" mount option to generate inode numbers smaller than 2 power 32 on the client. But you may not be able to detect hardlinks properly.
</snip>

So basically Samba is compiled as "vanilla" with no Unix extensions and thus with the default option of "serverino", it generates it's own local UniqueID inode numbers to avoid the issue, but these are sometimes greater than 2**32 and thus cause issues with 32-bit programs compiled without LFS support ie. without "-D_FILE_OFFSET_BITS=64" ... I am not sure if Retropie use our stock RPi builds, but I would suspect they either use Raspbian standard builds or build from source, but that is mainly an issue with the options provided while compiling in the distribution and slightly outside our scope.

https://digital-domain.net/largefiles.html covers this in more detail. I am not sure if we would want to enable that define by default in our configure script for some targets, but if you have an suggestion or patch then we would be happy to accept this as a Pull Request or similar.
digitall
ScummVM Developer
Posts: 1172
Joined: Thu Aug 02, 2012 1:40 pm

Post by digitall »

If we did add this, it would be to here:
https://github.com/scummvm/scummvm/blob ... gure#L2937

Basically add the following line around L2949:
append_var CXXFLAGS "-D_FILE_OFFSET_BITS=64"

But again, I am not the RPi porter / maintainer and I am not at all clear what drawbacks / side effects enabling that option would cause.
Post Reply