Retroarch Support? about retronas HOT 12 CLOSED

Symlinks from Retroarch rom folders to other folders? I just suggested a Docker image too.

If RetroNAS is to cover lots of options like MiSTER and Retroarch and other Rom folder structures that might be the only way to avoid duplication of folders

from retronas.

I'm going to close this issue off.

There's an open discussion for Docker, which is a good place for that:
https://github.com/danmons/retronas/discussions/2

And "RetroArch" I don't think is a thing I can support generically, as to my knowledge it has no specific layout for ROM folders.

I've got the RetroPie and Recalbox source downloaded, and have their folder structures laid out. I'll build those shortly with symlinks into the generic ROM dir tree and devote specific shares to those, then test (from what I can tell Recalbox has extra folders for saves, savestates, etc, which I'll try to deal with too).

But that's more platform specific to those "distributions" (for lack of a better description of what they are), and not about "RetroArch" itself. I'll try and get some commits in over the next week, and then if there are problems with those from testers, we can open some new issues on each one specifically to track their individual issues.

from retronas.

Docker is challenging for several reasons. "systemd services" mentioned above, as well as conflicting ports (if running on a NAS with its own SMB, RetroNAS's SMB will conflict), as well as non-IP traffic and broadcast (EtherDFS, AppleTalk, NetBIOS, etc - some of these don't even have "ports" to "port forward", because they don't use IP, TCP or UDP). Most Docker images you find run services on custom ports, or just choose random ones. That won't work for RetroNAS, as the ports being used need to follow official standards, otherwise remote systems won't connect.

Just throwing what's there now into a Docker image together is easy enough, but it very likely won't work on almost every NAS devices you can think of for all the reasons above. On a bare computer or RPi it'll probably work, but this isn't the audience asking for Docker currently.

Docker is absolutely a goal - I've had over 100 requests across social media for it this morning alone. But making it work is trickier than it first appears, and any assistance from the community is very welcome (especially people who own these NAS devices and know how to build complex Docker images with non-default networking).

from retronas.

Port conflicts aren't much of a concern for docker if a prerequisite of a load balancer is stated in the install instructions and checked for.

Load balancers and port forwarders only work with certain features. RetroNAS already supports multiple non-IP protocols (EtherDFS and AppleTalk/DDP), and more are on the way (IPX and DECnet coming soon).

I know that modern MiSTer/emulation users have their specific wants, but my goals are to ensure as wide a range of systems can use the tool as possible.

That's not a "I don't want containers", more a "I'd prefer as many features to work in a container as possible". Some things may need to be sacrificed, which is fair enough. Perhaps there's a way to identify which tools are container ready and which aren't too help any automatic container build tools.

from retronas.

well - I think my specific use case is this:
My family all have different devices, but the most problematic are tablets - getting the roms to retroarch on the tablet without actually loading them on the tablet has proved more difficult than you'd think.

from retronas.

The main issue dockerizing retronas is that it uses systemd and it is not in the essence of docker to run an "operating system" with services. Not that it is not possible, but it would be a little hacky.

from retronas.

Answering the top post - RetroArch support:

RetroNAS currently has a concept of a "generic ROM folder":

• https://github.com/danmons/retronas/wiki/Generic-ROMs-folder

i.e.: all ROMs live there, and symlink to a structure compatible with any given project.

RetroNAS itself supports MANY protocols:

• HTTP 1.0+
• FTP
• TFTP
• LANman/NTLMv1,v2/SMB1+/CIFS
• AppleTalk/AFP
• NFSv2+

For example, the "MiSTer" installer of RetroNAS simply creates symlinks from a specific MiSTer SMB1+ share and uses symlinks to point these to the generic ROM folder.

Similarly OpenPS2Loader does the same - points to the generic ROMs folder in a specific way to satisfy OpenPS2Loader.

On the RetroArch side, if you're running on a PC or RPi, you can mount the generic ROMs folder currently via any of the protocols listed above. If specific folder structures are needed to satisfy RetroArch, I can build those. If these are documented somewhere, please link that documentation (whether it's a wiki somewhere, a text list, a code source file, whatever), and I can build a structure and share dedicated to RetroArch that points back to the generic ROMs folder.

Same goes for any project - Recalbox, Batocetera, RetroPie, whatever. If they need custom layouts too (or can just use the RetroArch layout), I can build these if documentation exists.

On the client side, the protocols RetroNAS supports are listed above. If extra protocols are required, I can add them. Just let me know (a) the protocol and (b) any specific requirements (e.g.: OpenPS2Loader requires SMB1, can't work with SMB2+, etc).

If people are developing new tools (handheld emulators, flash carts, etc) and are thinking about clever ways to network load ROMs, my advice is: don't limit yourself to SMB if you don't have to. HTTP, for example, is low overhead, supports poor quality links like WiFi, doesn't require authentication, read-only, and very easy to find lightweight libraries for. RetroNAS can export any given ROMs share via multiple protocols - HTTP for your device, and SMB/AFP/FTP/NFS/whatever for pushing ROMs to the share ready for HTTP export.

Larger ROMs may be tricky however (ISO / optical media streaming, for example, my require more than HTTP to keep latency lower, I'm not sure).

from retronas.

Docker is challenging for several reasons. "systemd services" mentioned above, as well as conflicting ports (if running on a NAS with its own SMB, RetroNAS's SMB will conflict), as well as non-IP traffic and broadcast (EtherDFS, AppleTalk, NetBIOS, etc - some of these don't even have "ports" to "port forward", because they don't use IP, TCP or UDP). Most Docker images you find run services on custom ports, or just choose random ones. That won't work for RetroNAS, as the ports being used need to follow official standards, otherwise remote systems won't connect.

Just throwing what's there now into a Docker image together is easy enough, but it very likely won't work on almost every NAS devices you can think of for all the reasons above. On a bare computer or RPi it'll probably work, but this isn't the audience asking for Docker currently.

Docker is absolutely a goal - I've had over 100 requests across social media for it this morning alone. But making it work is trickier than it first appears, and any assistance from the community is very welcome (especially people who own these NAS devices and know how to build complex Docker images with non-default networking).

I'm not sure if this is an option elsewhere but running docker containers in Unraid has an option for "custom" networking which allows the container to have its own IP address which removes the conflict with ports.

I tried a Debian based container (basically a small VM) in docker with RetroNAS and ran into some issues but I will do more testing later today.

Preferably we'd set up symlinks from the RetroSMB share to an existing share as I'm sure I'm not alone in having an existing share with roms which would be better off not duplicated so as not to use additional storage.

Apologies for pushing this further off topic so please let me know if you would like me to post a new issue.

Happy to test if you need as this is something I'd love to get sorted out and would push me to finally grab a PS2 again.

from retronas.

I'm not sure if this is an option elsewhere but running docker containers in Unraid has an option for "custom" networking which allows the container to have its own IP address which removes the conflict with ports.

That's very useful, and will help solve the network conflict problem.

I tried a Debian based container (basically a small VM) in docker with RetroNAS and ran into some issues but I will do more testing later today.

I appreciate this. RetroNAS is less of a static product and more of a tool that installs and configures packages. What could be doable is building a dockerfile that uses RetroNAS's Ansible palybooks, and references an environment file with the user's preferences in it (their existing NAS path, user permissions, etc).

That would at least then allow the container to be built on the fly as needed, rather than pre-packaged and potentially conflicting with a person's existing layout.

from retronas.

Port conflicts aren't much of a concern for docker if a prerequisite of a load balancer is stated in the install instructions and checked for.

from retronas.

I'm afraid RetroArch doesn't currently have a folder structure that maps onto console_xyz.
When you import a folder, you tell RetroArch either:

• 'please scan this directory tree against your checksum database' which works well for - archived and unarchived - content that is unmodified (i.e. not a CHD with compressed Redbook Audio as MP3 or similar) or modified content where the checksum is known (e.g. patched ROM). No need to specify the platform there.
• 'this is my Ninsofty XGameStation folder, please add these files to my Ninsofty XGameStation playlist.'

Here it would be really handy if RA let you configure folders to scan on startup (multiples per system preferably), but it AFAIK that doesn't exist. Something like it does exist specifically for BIOS and firmwares (:\system).

from retronas.

Whilst RetroArch doesn't have support for folders as described above, you can set the default directory to the root folder of your NAS ROMs and you can then browse everything in a straightforward manner.

No artwork or game info this way, but a similar experience to MiSTer menu.

I do this anyway because I don't use the RetroArch "scan folder" or library function.

from retronas.