-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Remote-Playlists #17241
Comments
While it would indeed be very useful, we have purposely avoided adding anything like this because it would make RetroArch into a one-stop piracy machine. Kodi ran into a lot of legal harassment when they indirectly added similar capabilities through their plugin system. |
Oh, that's a fact which I hadn't in mind🙈. I don't want that you get some problems and you make a great job, but I thought I could make an issue to find a way to create ab global roms-management. |
You can already do this, if you have a OS that is not a unconfigurable walled garden. A path is a path is a path. A webdav or nfs server can be mounted by the OS then used for instance. Hell I used to mount a copy on write filesystem for dos games before I started RetroArch and my dos (and x68k too) playlist only had paths there (so the games didn't self modify). If you ARE in a walled garden like android, you're shit out luck because RetroArch doesn't implement the blessed way to access and record authorizations for network file paths (in android, the SAF: storage access framework). Ironically in android this only requires using the android file chooser to access network paths plus a 3rd party plugin for the filesystem you want (RSAF implements "filesystem" mounts for webdav, nfs and samba with rclone for instance, if you configure them after installing the apk). So emulators that use the native file chooser do work without extra code afaict, if not always quite well if they're too smart for their own good (Dolphin playlist might delete itself on a timeout if you open it without the drive available, for example if your server is down or waking up from wake\boot on lan). The problem is that RetroArch wants to use its file chooser, everywhere and it's a deeply held assumption of all the code, and in android, for unobvious sandbox escaping reasons you can't simply pass a path to RetroArch instead to use the Files app (and thus SAF). Instead all apps that want to use these special mounts must call the api to open a android filechooser from the app itself, so it can record the user authorization and the app that requested it. Ironically, you only would really NEED to call the file chooser in the scanners (manual and otherwise) file selection options. AFAICT, after getting the path you can operate on subdirs and file paths without any problem in other apps. Although RetroArch might want to do a option that allows authorizing paths (with the native android file chooser) instead that saves them in a "home page" for its file chooser (scummvm android does this). It would allow future existing playlist backups for android to keep working without recreating them and maybe even portable playlists too (if the file chooser home dir can be changed by first "authorizing" a remote dir then changing it in the usual RetroArch file chooser with a bookmark). |
Thank you for the explanation, unfortunately I am in a walled garden🙈, which is called tvOS from apple. I don't want that you have to make a large change which not fit's in the RetroArch architecture, but I thought that it would possible to import Files from a webdav server, because it would be easier to implement (just a PROPFIND HTTP-Request to scan a directory and a GET HTTP-Request to get the ROM-Files), I didn't know or care about the android privileges, but I thought that should be no problems because RetroArch already can access a webdav server with the Cloud-Sync-Feature. By side the Apple-TV I can help me by my self, but I think this can be make a more comfortably way to. And I would understand if you are thinking that would not be a good idea or to complex to implement it, it was just an idea. Thank you for your great work! |
I don't know how or even if this can be done in apple devices, since I don't have one, I'm just pointing out a alternative for Android remote games that already exists for other emulators using the native filechooser and could easily be implemented in retroarch. A android only "authorize external paths" button that just opens the native filechooser with the right settings and a shortcut in the RetroArch filechooser to get to those paths would be enough. Apple was always much more controlling than even google, terrible company, wouldn't be surprised if you had to root the device to mount a network filesystem at the OS level and use it outside the files app. Anyway, I think hizzlekizzle response clarifies why this functionality will not happen for anything but saves, easy way to get banned from app stores, or even be prosecuted by psychotic companies like nintendo... |
Hello Libretro Team,
it would be great to define "Remote-Playlists", which could Download the Content-Files from a Webserver.
The Idea is the following, in the "Import Content" Menu would be a new Entry "Remote Content".
There would be then the following entries:
Here is an Example of the JSON-File which i think it could handle every relevant action.
Where I think the Thumbnail-Fields should be optional (just to download them if the are defined).
Or it could also be an option to have the url and file_name fields as array in plural to support multi-disc or multi-file roms:
It would be nice when I create the playlist in the Retro-Arch, it would download the JSON and the Optional Thumbnails with the right naming conventions.
When I first want to launch a game from an "Remote Playlist" it should download the Content-File(s) from the URL(s) (probably in the "download" folder or a subfolder which already is used for the Cloud-Sync-Process). It should check always if the file already exists and probably redownload it.
This would be a feature which could solve 2 goals for me (and I think for others to ;)).
I hope you think this is useful and best regards
Alec4
The text was updated successfully, but these errors were encountered: