About collection handling

[Ferenc Nánási]

Hey @open-dynaMIX !
I'm the developer of mpv-remote-app
We've talked about switching to your backend. I've an idea how filebrowser extension can be implemented, for handling collections on my frontend app.

API route for example:
/api/browse_files/"<directory_path1>";"<directory_path2>";

We should only get response of supported formats by MPV, file formats can be found here
The response should return sub-directories first and files afterwards, but it's not big deal to implement this on my frontend, if you don't implement it.

Response (something like this):

[
    {
        "fullPath": "/home/user/media/subdir1",
        "name": "subdir1",
        "type": "directory"
    },
    {
        "fullPath": "/home/user/media/subdir2",
        "name": "subdir2",
        "type": "directory"
    },
    {
        "fullPath": "/home/user/media/movie.mkv",
        "name": "movie.mkv",
        "type": "video",
    },
    {
        "fullPath": "/home/user/media/movie.ass",
        "name": "movie.ass",
        "type": "subtitle",
    },
    {
        "fullPath": "/home/user/media1/music.mp3",
        "name": "music.mp3",
        "type": "audio",
    },
]

My implementation of this on node backend

If you need any more info please let me know. I would implement this by myself, but I don't have Lua coding experience.

[Fabio Ambauen]

Hey @husudosu

Awesome, let's do this 🚀 !

Couple of things I plan to do different:

• Only directories added to a collections setting on the server (and sub-directories) will be exposed. A GET request to /api/collections/ will yield only them, as a starting point for traversing. By default, the collections setting is empty and no files are queryable.
• I will not only present files supported by MPV, but any file. The reason for this is: File extensions can be missing or wrong. MPV will play an mp4 file with a .txt extension without any issue. Also, I don't want to make any assumptions about the capabilities of MPV and I don't want to update a list of extensions, every time there is a new esoteric media format MPV can handle.

[Ferenc Nánási]

It's fine with me, to store available paths as server setting. But /api/collections by using all of the user provided directories is not the best idea. The collection route should have an optional parameter which can get only the specified directory. My app supports handling multiple collections which can be defined by users (for example: Movies, TVShow, Anime, Music etc...) .
Based on your suggestion I imagine something like this:
/api/collections/<path_url_encoded> - Gets a single directory contents if the path exists on server config. JSON as described above
/api/collections - Returns server configured paths as JSON. When the user wants to add a collection on my frontend these paths will be shown. This can be a simple array with the paths.

Probably most of the files on the net have proper file extensions, and TXT can be also subtitle file.
If you don't filter media file formats it's okay (file formats not being added so often) , but excluding scripts like shell, batch scripts and executables would be a good idea for security reasons.

[Fabio Ambauen]

I think we have a small misunderstanding. I plan on implementing the following:

collections setting on the server: "/home/user/Music;/home/user/Videos"

GET /api/collections/:

[
    {
        "path": "/home/user/Music",
        "is-directory": true
    },
    {
        "path": "/home/user/Videos",
        "is-directory": true
    }
]

These are basically the configured entry-points for traversing the trees.

GET /api/collections/home/user/Music/:

[
    {
        "path": "/home/user/Music/Artist1/",
        "is-directory": true
    },
    {
        "path": "/home/user/Music/Artist2/",
        "is-directory": true
    },
    {
        "path": "/home/user/Music/song.mp3",
        "is-directory": false
    }
]

[Ferenc Nánási]

@open-dynaMIX
Oh, sorry my bad. :)