Relative paths not working in a playlist on linux

[cyberconan]

Description

Relative paths not working in a playlist on linux, only absolute paths.

Expected behavior

Launch a game from a playlist with relative path.

Actual behavior

The game is not launched.

Steps to reproduce the bug

1. Edit a playlist created previously with RetroArch interface than works well.
2. Replace absolute path like "/home/karl/.config/retroarch/roms/fbneo/1941.zip" with relative path like ":/roms/fbneo/1941.zip".
3. When try to launch the game from playlist, it not load

Bisect Results

I detected this when I was trying to prepare some playlist for my SteamDeck from my desktop installation.
I tried other relative path options like ":/cores/../roms/fbneo/1941.zip", "roms/fbneo/1941.zip" or "~/.config/retroarch/roms/fbneo/1941.zip", but no one work.

Relative paths works perfect for core line: "core_path": ":/cores/fbneo_libretro.so".

Version/Commit

1.19.1

Environment information

• OS: ArchLinux
• Compiler: Using official version in Arch Extra repository

[i30817]

Use the portable playlist feature to relocate playlists between systems or OSes boots, playlist only work with absolute paths on purpose because the current directory is a very relative thing for RetroArch, on OSes boots, package format or even user changes.

Not to be disrespectful but usually here the reporter of this issue will insist that relative paths are absolutely necessary for their workflow, usually some kind of script launcher hack to relocate the rom folder depending on the OS, and then they get ignored, because it's really not that simple if you want to relocate across sufficiently different OSes with different ways to mount drives.

Portable playlists are not simple to explain how they do it, but are relatively simple to do. Turn on portable playlist on both target devices\oses\users RetroArch, then with a valid playlist, set a ... I forgot the name, the browser start directory setting, to a path that is a ancestor of the game dir or is the game dir.

Then on the other device\os\user set that setting to the path that happens to have your games when you mount the drive, RetroArch will check the paths in the playlist do not match the setting and rewrite them. You might have to restart so the playlist entries work, don't recall.

You can also use this to change your rom folder inside the same system I think.

[i30817]

Don't reuse retroarch.cfg (usually the other way scripters want to reuse RetroArch settings in another system) across systems\oses\users either. That's a fine way to end with a lot of funky bugs because that file has many os specific settings or even user specific paths. You might get lucky with 2 Linux systems with the exact same username, the most forgiving case, but even then you get missing high res icons (RA downloads these to a temp dir on the first boot, and uses the existence of that path to check it doesn't need to, or if it recognized it does need to, it tries and fails because that random temp path download no longer exists in another system).

[cyberconan]

Hi! Relative paths like ":\roms" works perfect in playlists with Windows file system. The problem with linux is than "/" is concatenated always before the path.

Another thing than I have detected is than a relative path in "core_path" works well, a "/" is not added, the issue only happens with "path" field. For example this item works well:

"items": [
    {
      "path": "/home/karl/games/retroarch/roms/fbneo/1941.zip",
      "label": "1941 - Counter Attack (900227 World)",
      "core_path": ":/cores/fbneo_libretro.so",
      "core_name": "Arcade (FinalBurn Neo)",
      "crc32": "00000000|crc",
      "db_name": "FBNeo - Arcade Games.lpl"
    },

And this generate the path not found error:

"items": [
    {
      "path": ":/roms/fbneo/1941.zip",
      "label": "1941 - Counter Attack (900227 World)",
      "core_path": ":/cores/fbneo_libretro.so",
      "core_name": "Arcade (FinalBurn Neo)",
      "crc32": "00000000|crc",
      "db_name": "FBNeo - Arcade Games.lpl"
    },

Regards!

[i30817]

Like I wrote before, relative paths aren't part of the paths of roms on purpose. The reason is that it would sabotage portable playlists because a relative path is relative to the current system, and portable playlists work by memorizing a ancestor path of the game directories in the playlists to compare to another system browser path and when they different, change them.

This is the only way to be portable across OSes and users because mountpoints do not keep the same relative location or RA (sometimes RA dir isn't even writable), even in windows (sometimes a system has 2 drives and the usual D: pendrive is E: for instance). A relative path would never match, and so a part with them would never be transformed, so the portable playlists setting would do nothing.

If it 'works' in windows, it probably breaks portable playlists when you do that manually\with a script, which is the only way you would be able because RA doesn't allow you to choose . or .. as paths in the UI.

Cores have fallbacks, if one can't be found, such as in another system that places cores elsewhere, RetroArch will fallback to the main core associated with the playlist in the default location I think.

[i30817]

I'm almost certain that what you're trying to do with relative paths can be done with portable playlists instead.

If you're trying to make your games portable across a external drive in different systems, it can do that. If you're trying to do that but also keep RetroArch around for multiple OSes, that's possible as long as you keep static RA executables for both systems in the same dir but don't share retroarch.cfg (with a bat or shell file to redirect one of the executables to use another cfg file as the main one). Alternatively you can keep them in different dirs but point the playlist dir (and thumbnails, because why not) to the same directory for both executables.

If you're trying to relocate a games directory, you can turn on portable playlists after setting the browser start directory path setting, load all playlists to be sure they save that setting (I don't know the time the code changes the playlists files, when you change the setting or when you load the playlists) quit RA, move the dir, then restart RA and change the browser start path setting again and wait for the playlists to be rewritten when you load them.

[cyberconan]

@i30817, what you propose is to avoid the problem by using another great functionality of RetroArch, but not solve the issue I reported.

For those of us who move games on an SD from a laptop with Linux to Steam Deck, I think it is infinitely easier to copy the roms to a folder in the RetroArch root directory because the playlist would always work and without doing anything else.

[i30817]

If you're just talking of the games and playlists, cool, portable playlists do that for you without having to do a script to edit the playlists, just change two settings and iterate over the playlists to make sure (I still don't know when the code writes so I can't be sure that last step isn't needed, bugs happen), then copy them over to the right other RetroArch install dirs.

Otherwise, if you're talking of using the same RetroArch folder on both systems... that's a great way to get a corrupted retroarch.cfg. As I mentioned, do not, ever share them across OSes. That feature is what is intended to share playlists and games, so copy or use a external drive to keep the games (and thumbnails and playlists, and if you want to share them with both instead of duplicating, set their paths in RetroArch settings of how the drive appears in the system), it's there to do what you want, but don't say you weren't warned when you get low res icons or failing GPU driver settings sabotaging boot when you try to copy the whole RetroArch folder across systems.

You can fix it but it's a pain depending of which system specific settings are affected (for instance, all the path settings may be different because by default they're absolute, not to mention in Linux packages may be out of the user filesystem). Having to edit retroarch.cfg in a text editor to boot it is not out of the question if you just don't give up and delete it.

In fact, if you think it's easier, you can just try it out before asking. Even on a Linux system following Linux standard base with a statically compiled RetroArch or one where the dynamically linked things are the same versions or compatible versions, just having a different user name is enough to sabotage most of the user writable paths of RetroArch. Including modern user mounted external drives or pendrives.

Even if you DO have the same user name or relative paths to everything (I tried this when changing distros), other path or hardware details in retroarch.cfg make keeping the RetroArch folder\cfg dubious at best (I also tried to reuse it when doing a android RetroArch install. Wasted more time editing the file than if I had bitten the bullet and just recreated the settings, mostly because I used a keyboard on PC and the virtual controller on android and because some android settings simply don't exist in a PC retroarch.cfg or are all wrong like the input drivers).

[cyberconan]

You are wrong in your approach to what I do. I don't copy the entire retroarch folder from my laptop to the SD card, I only copy some folders such as playlists and roms, the rest is already provided by Steam with the official RetroArch installation.

[i30817]

Then just use portable playlists feature. Instead of trying to ask devs into allowing relative paths - a alternative to that - that was rejected because it breaks that feature and because it requires things that the RA interface does not accept. Such as adding yet another option to both scanners, on different places to collect ROM paths relative to the Ra folder paths...

I know Linux users are sometimes proud of being able to automate with some self scripting, but you'd just save trouble to yourself if you used this feature and wanted to, say, share games in a external disk or OSes boot between Linux and windows, or even Linux to Linux. Just making and fixing the bugs of your script or text replace make work is more time that going into the options of both RAs and setting two settings (+ several paths if you want to share saves, playlists and thumbnails, instead of just copying over playlists and saves). Speaking as a dude that did several script projects to make using RA more bearable, including a entire alternative way to get thumbnails using fuzzy game name searching and a way to create the scummvm playlist that eventually was adopted by the core.

Would I like if it just worked to copy over playlists from a system to another if the games were in a RetroArch folder subdir? Of course. But that's not the case and it's likely not to be the case ever, because OSes can't even agree what a path seperator is, much less "current directory".

Moreover I think the original reason why RA doesn't accept relative paths for roms is they found this the hard way, when they tried to feed ROM paths to core dlls (which are often quite distant from the executables or not in a user dir but a root dir).

[cyberconan]

As I said before, I have only reported an issue that is only present on Linux because on Windows relative paths work fine. If it is never solved, nothing happens, Linux users will survive by looking for, collaborating and using alternatives as always. ;)

Thank you @i30817 for your comments.

[i30817]

It's your time man, I don't think it will work out like you think though even if you get the 'limitation' removed. In fact, that the Linux code intentionally adds / always indicates to me a bug fix happened because something was going wrong with the very clumsy way Ra uses its own hadhoc relative path protocol. (:). Probably with the way the executable and core paths are unrelated in RA (core dir is a OS settings default, so in some OSes or installs :./cores makes sense but in others :../../../home/$USER/.config/RetroArch/cores would instead.

And Ra never intended the ROM paths to be relative at all, this is easily seen by the lack of any option on the UI to capture relative paths in the scanner so bugs will a abound in many cores. In fact, i recall a lot of cores "need fullpath" as core metadata. So it's not even just RA or just rom paths.