Storing ROMs and other data on a remote drive

Clyde

@mitu Thanks for your reply. One could also use the option bootwait in the fstab to ensure that the boot process will wait for the remote mount, right?

mitu

@Clyde bootwait is not an /etc/fstab option, is something set by raspi-config for boot process to wait until the Pi gets an IP address. That might provide enough delay to allow the network to start and mount the drive before EmulationStation starts, so it's an useful addition.

Clyde

@mitu I mean the option that was talked about here: https://unix.stackexchange.com/questions/53456/what-is-the-difference-between-nobootwait-and-nofail-in-fstab

But I don't know if it is depricated by now like nobootwait, as someone in that old question remarked. Maybe you'd have to use x-systemd.device-timeout for that too now.

seriema

@mitu said in Storing ROMs and other data on a remote drive:

The only advantage I see if that - with this method - the remote disc is mounted before EmulationStation starts, so there's a smaller chance for EmulationStation to start with an empty roms folder.

Yes that's what I use it for too, but there's a caveat to it that I missed the first time. The autostart.sh looks like this:

emulationstation #auto

Meaning the mounting has to be added to the top of the file. Otherwise it's too late to be of any use.

Commonly I just append to files with >> or tee -a. But due to the above I end up doing sed magic:

sudo sed -i "1s+^+$mntCmd\n+" /opt/retropie/configs/all/autostart.sh

Clyde

@seriema Thanks for sharing your solution. Like nearly always with console magic, there are multiple ways to add a line at the beginning of a file. 😎

seriema

@seriema said in Storing ROMs and other data on a remote drive:

@Clyde [...] I'll be trying this tomorrow or later on.

I hate threads that end like that and the timestamp is 5 years ago 😁

In the end I didn't change my solution. I spent a whole day mulling over it, and it basically comes down to all the scenarios I'd need to handle.

My previous (and current) approach

Setup:

mount /mnt/retro-cloud
move /home/pi/RetroPie/roms -> /home/pi/RetroPie/roms.local
rsync /home/pi/RetroPie/roms.local -> /mnt/retro-cloud/roms
symlink /mnt/retro-cloud/roms -> /home/pi/RetroPie/roms

Boot: Step 1.

Drawback: If the mount doesn't work, you can't play the local ROMs.
Counter: The idea is that you keep all your ROMs in retro-cloud, and connect it to everything you run emulators on. RetroPie being just one of them. So you wouldn't have anything locally to fall back on anyway. It also makes the copying (step 3) optional during setup, and can be run at any time after boot.

Suggested approach in this thread

Setup:

mount /mnt/retro-cloud
rsync /home/pi/RetroPie/roms -> /mnt/retro-cloud/roms
mount /mnt/retro-cloud/roms -bind -> /home/pi/RetroPie/roms

Boot: 1 and 3.

Drawbacks:

If the ROMs aren't copied in step 2, they can never be copied to retro-cloud after boot.
Boot script is messier. Step 3 should not run if step 1 failed.

Clyde

@seriema said in Storing ROMs and other data on a remote drive:

Boot script is messier. Step 3 should not run if step 1 failed.

That should be avoidable by && between 1. and 3. (bash for "only execute the latter if the former finished successfully").

mount retro-cloud && mount --bind roms

That said, if there's nothing in the local roms directory, it shouldn't matter if 3. runs if 1. fails. The roms directory will be empty no matter if 1. is executed or not in this case. :)

seriema

@Clyde said in Storing ROMs and other data on a remote drive:

That should be avoidable by && between 1. and 3.

Good tip with &&, thanks! I still need them written separately somewhere, so I can run step 2 in-between during setup. Unless I want to have steps 1 and 3 copied in two places (RetroPie's autostart.sh and my setup.sh) I'd need to make them available in a separate script and call them as methods? It's not insurmountable, it's just meh 😁

Hopefully there's nothing in the local folder. The main reason for me to go down the bind mount path was for the fallback functionality (play local roms if VM mount failed). If I'm not going for the fallback then I don't see the drawbacks of my current symlinked approach?

Clyde

@seriema said in Storing ROMs and other data on a remote drive:

If I'm not going for the fallback then I don't see the drawbacks of my current symlinked approach?

On a quick glance, I don't see any either. The fallback is a nice idea, though. Apart from that, I mostly prefer bind-mounts out of "sympathy". They just feel somewhat more elegant to me.

I think that some people prefer symlinks if there's no actual reason for mounts and vice versa. I just happen to be among the latter. :)

seriema

@Clyde said in Storing ROMs and other data on a remote drive:

You can set it in the file /home/pi/.emulationstation/es_settings.cfg via the line <bool name="ParseGamelistOnly" value="true" />.

Finally got around to try that out. I didn't notice any real difference in starting time. It spends 80%-ish of the EmulationStation load screen with "Loading system config". The total time from console to be in the UI is ~1 minute regardless if ParseGamelistOnly is set to true or false.

It might be my setup, because there's no es_settings.cfg file available so I had to create it myself:

<?xml version="1.0"?>
<bool name="ParseGamelistOnly" value="true" />