More > JRiver Media Center 25 for Linux
Cross Platform Paths
max096:
--- Quote from: mwillems on August 06, 2019, 04:23:02 pm ---In the server-client playback context, allowing clients to play "local" files if available dramatically improves the client experience when it works (seeking in videos, for example, works much better with direct file access than when relying on the server to serve the file, etc.).
--- End quote ---
Which is how it is currently. A network drive is not local either. It working well is proove that local files arent necessary and you could match or surpass say smb (for your specific purpose) without requiering users to puzzle together paths by mounting things in a way that matches the remote.
Say your remote jriver is windows and has its music on C://Music. You cant mount that in that way on another machine, even if its Windows too.
Its just not always possible to do that. And that all assumes people have a network share setup they have access to.
BryanC:
--- Quote from: max096 on August 07, 2019, 04:48:07 am ---Which is how it is currently. A network drive is not local either. It working well is proove that local files arent necessary and you could match or surpass say smb (for your specific purpose) without requiering users to puzzle together paths by mounting things in a way that matches the remote.
Say your remote jriver is windows and has its music on C://Music. You cant mount that in that way on another machine, even if its Windows too.
Its just not always possible to do that. And that all assumes people have a network share setup they have access to.
--- End quote ---
I don't think I'm following your logic here. mwillems is describing a setup in which there are duplicate copies of the media files, one on the server instance and one on the client. This is useful for, say, laptops where you may not have unmetered access to your library server on the go. You can save considerable bandwidth by playing the local file. I believe what you are referencing (and I may be wrong) is a single NAS share mounted on both the client and the server. These are different use cases.
The easiest solution from a theoretical standpoint is to just strip the OS-dependent prefix and perform some translation on the path separators (which I believe is already done in MC, albeit in an ugly way with escaping which is exposed in the handheld sync path settings).
max096:
--- Quote from: BryanC on August 07, 2019, 08:56:15 am ---I don't think I'm following your logic here. mwillems is describing a setup in which there are duplicate copies of the media files, one on the server instance and one on the client. This is useful for, say, laptops where you may not have unmetered access to your library server on the go. You can save considerable bandwidth by playing the local file. I believe what you are referencing (and I may be wrong) is a single NAS share mounted on both the client and the server. These are different use cases.
The easiest solution from a theoretical standpoint is to just strip the OS-dependent prefix and perform some translation on the path separators (which I believe is already done in MC, albeit in an ugly way with escaping which is exposed in the handheld sync path settings).
--- End quote ---
Basically, yes youve got a NAS and you connect to it from everywhere else. Local cashing or syncing features are all also useful. But thats not really what this was about.
On my nas my music is in /mnt/raid/music lets say that I bind that into my docker container to /data/music. So inside the docker container /data/music/song.flac would be a valid path that exists. Now Im on my windows PC and connect to jriver inside the docker container, trying to upload a playlist witch contains song.flac. Now it will tell me /data/music/song.flac does not exist on the Windows. Even if you cache or sync it it would never be under /data/music/song.flac on the Windows PC unless I also mount it there.
Does that make sence now?
It may also just be a weird error message that was not really planned. For cloud sync that might very well be a case of "Not quite implemented yet". An error message like "Could not find /data/music/song.flac on 192.168.1.xx" would make more sence. Or just "Could not find song.flac" then. But if you where actually trying to find it at "/data/music/song.flac" on my Windows PC i´m 100% going to get the same error message once this works on Linux as /data does not exist on any of my Linux desktop installs.
bob:
We just did a bit of noodling on this concept.
What if the database filepaths have separators and "drive" placeholder values that are filesystem agnostic (how they are stored is yet to be determined)
Then there are path mappings stored independently in a path settings file to tell each OS where that "drive" starts.
For examples of the drive placeholder values, in windows C: is mapped to the first drive whereas in Linux and Mac that might become /
For a network path a UNC path \\ becomes /media/foo/bar in linux or /Volumes/foo/bar on Mac.
We modify our existing file functions to test for equivalency not including the drive placeholder values.
One could then simple move a Library from Windows/Mac/Linux and then just update the path mappings on the destination machine.
This could apply to stream playlists as well I think.
Thoughts??
Hendrik:
An automatic solution that tries to automatically split drives out is probably not going to be flexible enough, between mapped network drives on Windows, or arbitary filesystem mount points on Linux (or on Windows even, albeit more rarely used). How do you know that /a and /b are different drives? I suppose you could read the mount table, but that sounds like a nightmare to figure out.
Personally, I would go a simple but tad bit more manual way. Let the library continue to simply store a path, say the path on your primary media system, ie. your server, and on clients you can define "mappings" where you tell MC how to translate the path to the current system (ie. a simple string replacement at the beginning of the string, first rule to match wins with a defined order)
That way you also have zero risk of screwing up the library itself, and only have to make proper mappings. Safety of the library is key there.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version