More > JRiver Media Center 25 for Linux
Cross Platform Paths
mwillems:
--- Quote from: max096 on August 05, 2019, 06:10:15 pm ---Could you make a note that pressing upload when connected remotely to another jriver instance should not look for the path where the file is on the remote jriver instance? That's never going to work.
I never had this working on any machine yet either. On Windows I got well that. I would have mounted the directory to that path. But how do I mount to /data/music on Windows? ^^
--- End quote ---
Cross platform file paths are a lingering issue that's not resolved. The current system works in homogenous environments (i.e. all windows machines using UNC file paths to a NAS, or all linux machines with a NAS share mounted to the same directory), but there's no way to get *nix style paths and UNC or windows style paths to play nicely in a mixed windows/*nix client-server environment with JRiver right now. This has implications outside of cloudplay too (for example, the "play local file if available" check box won't work correctly on Linux clients of a windows server and vice versa).
Something like a customizable "root-filepath" variable could at least partially solve the problem; A fix for this issue has been on my wishlist since MC for Linux launched, but I recognized it was previously a niche issue. The path issue looks a little more front-and-center here, so it might be worth sorting out the filepaths issue for good as part of the fix here.
JimH:
I agree. It's time we found a solution.
shortie:
--- Quote from: shortie on August 05, 2019, 09:55:48 am --- I’ll try this when I get home tonight and report back
--- End quote ---
I tried this and got logged in to cloudplay in Panel but couldn’t find a way to upload a playlist there. Maybe that was implied in the post that said it wasn’t working yet on Linux but i thought I’d post anyway.
max096:
--- Quote from: mwillems on August 05, 2019, 06:30:11 pm ---Cross platform file paths are a lingering issue that's not resolved. The current system works in homogenous environments (i.e. all windows machines using UNC file paths to a NAS, or all linux machines with a NAS share mounted to the same directory), but there's no way to get *nix style paths and UNC or windows style paths to play nicely in a mixed windows/*nix client-server environment with JRiver right now. This has implications outside of cloudplay too (for example, the "play local file if available" check box won't work correctly on Linux clients of a windows server and vice versa).
Something like a customizable "root-filepath" variable could at least partially solve the problem; A fix for this issue has been on my wishlist since MC for Linux launched, but I recognized it was previously a niche issue. The path issue looks a little more front-and-center here, so it might be worth sorting out the filepaths issue for good as part of the fix here.
--- End quote ---
I dont think filenpath compatibility is a big problem. Other than for backups (if it does not work there, I dont know, didnt try to backup on Linux and restore on Windows)
You should never retrieve file paths that are true on a remote system and try to use them locally. Either get the file (instead of the path from the remote jriver) or make the jriver on the other end upload it for you.
mwillems:
--- Quote from: max096 on August 06, 2019, 02:43:35 am ---I dont think filenpath compatibility is a big problem. Other than for backups (if it does not work there, I dont know, didnt try to backup on Linux and restore on Windows)
--- End quote ---
It does break backups, it also prevents some media server options from working correctly (as noted above). It's also a limiting factor (IMO) in allowing clients to make certain changes that are currently "server-only."
--- Quote from: max096 on August 06, 2019, 02:43:35 am ---You should never retrieve file paths that are true on a remote system and try to use them locally. Either get the file (instead of the path from the remote jriver) or make the jriver on the other end upload it for you.
--- End quote ---
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.).
You're right that they don't need to fix file paths globally to fix the cloudplay issue, but fixing the filepath issue would fix this issue and a handful of other issues too if you see my point.
Navigation
[0] Message Index
[#] Next page
Go to full version