Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[tjobbins]

Hi

I am now using multiple different architectures in my MC network: my MC Library Server is Windows 10, serving Windows and Mac OS clients.  I may in future move the server to Linux, serving Windows and Mac OS clients.

I am using Library Server -> Client syncing, and this works great, except for one annoyance:  when the Client and Server are using a different OS, all files have to be re-transmitted via the Library Server, because the filenames can never be found directly given the different network paths required.

My Windows PCs find my files at the path Z:\media\, but on Mac OS this is /Volumes/Media/ and on Linux I mount it as /data/media/

So although all systems can access the same files directly, the Library Client option "Play local file if one that matches Library Server file is found" can't work across multiple OS'.  This could also be the case between systems of the same OS, if they happened to require different network mappings.

So my request is to add a new option: "Search/replace local path for Library Server files", either globally under Media Network -> Client Options or (better) as a per-Library option in Library Manager.

This would allow specifying Find: and Replace: fields, such that those substitutions are made automatically and transparently on every path retrieved via the Library Server.  It would do this before the local file check was performed, such that if the replaced path could be found locally, the file would not need to be transmitted via the Library Server.

It'd also be nice if this modified path was shown in the Filename field on the client, and was therefore also also used for operations such as Find On Disk.  (Perhaps with some indication in the UI that the path had been substituted, with a reference to the path seen by the server, so that it's clear that a change is being applied automatically.)

In my example, on my MacOS client I would specify Find: "Z:\media\" and Replace: "/Volumes/Media/".  This should work as long as MC automatically converts the \ in Windows file paths to the / for MacOS and Linux (if not, then that's another request )

Ideally it would be possible to add any number of multiple Find/Replace rules (using a dialogue with a + and - for adding/removing rules), for libraries where not all files are under a single base path.  That wouldn't currently be necesary for me as 100% of my Library files are in a single Media tree (with subfolders for Video, Movies and Audio), but others might benefit from it.

Thanks in advance.

[RoderickGI]

A solution already exists without the need to modify MC.

https://wiki.jriver.com/index.php/Home_Networking_Examples

Example 3.

[tjobbins]

A solution already exists without the need to modify MC.

https://wiki.jriver.com/index.php/Home_Networking_Examples

Example 3.

Thanks for the reply, but unfortunately this doesn't work across different OS.  (Actually this is mentioned in the guide:  "Non Windows OS: This guide is only for Windows UNC Shares and it will not work if you have a mix of non Windows Clients as the Network Paths are named differently.")

Mac OS and Linux don't recognise \\SERVER\SHARE UNC paths natively.  Any network path on a *nix OS has to first be mapped to a normal directory path before it can be accessed, then it's referred to in the normal /directory/tree, like any other file.

UNC paths are a Windows thing, and are baked into the OS' standard file handling.  In other words, I believe that on Windows you can pass a \\UNC path to any standard file open call and it works automatically, identically to accessing any local file.  Mapping to a drive letter is an optional convenience. 

The same is not true on Mac and Linux, where the mapping is essential.  On these OS any network paths (SMB, NFS, etc) must first be mapped to a local path (eg /Volumes/Media).   You can't pass a network path to a file open call, even if it's already mounted.  You always pass the mounted location.

Perhaps MC could do some trickery on the Mac and Linux clients; special handling for UNC paths.  For example given a path like \\192.168.0.54\media, it could check the mount tables to find if that network path is currently mounted, and to which path it's mounted (eg /Volumes/Media) and then substitute.  But that sounds a bit messy and potentially error-prone to me.

Personally I think my user-configurable substitutions idea would be the easiest and cleanest solution for a multi-OS environment. 

Perhaps then this request is more appropriate for the Mac or Linux forum.  But if I switched to using my Mac OS MC as the Library server I'd need my proposed Library Client remapping on the Windows client instead, so the Windows forum seemed the best, central place.

[mattkhan]

unfortunately this has been requested multiple times over the years but it has not been implemented nor commented upon e.g. https://yabb.jriver.com/interact/index.php?topic=112840.0 .

It would be good if one of the devs could comment on whether this something they don't want to do for some reason or whether it's just not a priority for them.

[BryanC]

+1. I abandoned library server and use automatic tagging + syncthing to keep my media files synced across my different OSes, but playlists obviously do not map correctly, and there is no easy way to automatically import/export playlists with relative paths). If we could have this functionality implemented, it would be a huge bandwidth saver.

It should be as simple as letting the user define the base path somewhere and correcting the slashes.

[mwillems]

+1. I abandoned library server and use automatic tagging + syncthing to keep my media files synced across my different OSes, but playlists obviously do not map correctly, and there is no easy way to automatically import/export playlists with relative paths). If we could have this functionality implemented, it would be a huge bandwidth saver.

It should be as simple as letting the user define the base path somewhere and correcting the slashes.

+1; I think I recall that the slash reversal logic may already even be implemented, it's just the base path.

[RoderickGI]

Thanks for the reply, but unfortunately this doesn't work across different OS.

My bad. I didn't elaborate, because I haven't used Linux in many years, or OSX in a couple. I'm certainly not up to date nor can I remember everything that is possible. 

However, a quick Google came up with these solutions to the accessing Windows UNC challenge.

Windows Subsystem for Linux: https://blogs.msdn.microsoft.com/wsl/2017/04/18/file-system-improvements-to-the-windows-subsystem-for-linux/
Using CIFS on Linux: http://hoppenheit.info/blog/2014/mounting-windows-network-shares-in-linux/

I think the Windows Subsystem for Linux would be a better solution, because Microsoft has dropped SMB 1.0 support recently, and are talking about dropping other older access methods in the future. CIFS may not be around in the future. But I haven't worked out exactly how to use WSL, because I don't have the hardware to try it out.

Of course, with either solution, you would need to mount the volume and point them to the UNC as part of the boot process, but I'm sure that could be done. I don't know if those solutions will work, but as you have a better understanding of Linux, I'm sure you will be able to confirm or otherwise.


My GoogleFu wasn't good enough to find a direct equivalent in Mac OS. There was mostly talk of using Samba or CIFS. But there was also talk of using UNC paths when using Active Directory services. However as Mac OS is a *nix OS, it could be possible that the same mount commands that allow Linux to connect to a Windows UNC also work in OSX. You will have to try that out.



I don't like your suggested solution because it is implemented at the application level, while I would prefer a solution at the operating system level, such as Windows Subsystem for Linux. Having said that, I found that at least one other media center application used to support a path substitution feature, so that could be a valid solution. But that support was dropped a couple of years ago and replaced with direct support for using SMB paths. I guess that they had issues with the substitution. It just wouldn't be my preference to use a path substitution feature. Of course, JRiver may have other ideas.


If the above ideas don't work and something needs to be done in MC, it would make more sense to me to use a Global Variable which was different for each installation and stored the base address, such as suggested in this post, because then at least the operating system is doing the substitution, so the solution should work in all(?) places within the OS.

The library currently contains platform specific paths, make this format OS agnostic which means

- auto replace \ with / as necessary
- use a named path rather than an actual path, e.g $MOVIES$\MyFilms would resolve to X:\MyFilms on Windows and /mnt/media/MyFilms on Linux

[mattkhan]

There is no OS level solution, if there were then these threads wouldn't exist wsl and cifs are not relevant here as they just refer to mechanisms for mounting something in Linux. The point is that irrespective of what hosts those files and how you mount them, the path will vary by OS and MC stores the literal path in the library thus an application level translation will be required.

[tjobbins]

There is no OS level solution, if there were then these threads wouldn't exist wsl and cifs are not relevant here as they just refer to mechanisms for mounting something in Linux. The point is that irrespective of what hosts those files and how you mount them, the path will vary by OS and MC stores the literal path in the library thus an application level translation will be required.

Indeed.  Roderick, there can never be a network path that works to access the files on Windows that will also work on Linux and Mac OS.  They're fundamentally different naming schemes.

If you dig into WSL a little further you'll find that different paths are used to access the same files inside WSL versus outside WSL.  Ie a Linux app running under WSL might access a file as /mnt/share/file where the Windows OS would access it as Z:\file or \\host\share\file.  So even when Windows is launching Linux apps via the WSL framework, still different paths are used.

On top of that, installing WSL makes no difference to how paths are used outside of WSL.  That is, installing WSL on Windows makes no difference to how Windows apps access files, so it can't possibly affect the interaction between Windows MC and any other OS' MC.

There is no single path that can work for both Windows and Linux/MacOS at the same time, regardless of WSL usage - not even if Linux MC were run under WSL (not that that is possible, or useful.)

When a single Filename path is used to access the same network files on different OS - as MC does - some kind of translation has to occur before the path can be simultaneously valid on all.  (More specifically, translation has to occur to make a path simultaneously valid on Windows and any *nix OS; it is possible for Linux and Mac OS to use the same path without translation.)

If the above ideas don't work and something needs to be done in MC, it would make more sense to me to use a Global Variable which was different for each installation and stored the base address, such as suggested in this post, because then at least the operating system is doing the substitution, so the solution should work in all(?) places within the OS.

If a variable substitution was used as per matt's suggestion, then this is still an MC-specific thing.  Nothing to do with the OS.

A variable-based substitution is certainly one way to do it, ie the library is first updated with a find and replace, changing \\SERVER\SHARE to $BASEPATH, and then $BASEPATH is set in the configuration of Windows MC, Linux MC and Mac OS MC to point to, respectively, \\SERVER\SHARE,  /mnt/share and /Volumes/share  (for example).

Personally I still prefer my idea of substitutions being applied only in the Library Client code.  It seems cleaner and neater to me - only apply the changes where they are needed.  In an MC network that consists of two Windows MC and one Mac OS - as mine does - only the Mac OS would need to apply a substitution, and the library Filename paths could be left to working UNC paths for the two Windows hosts.  So no mass library update would be required, and the substitution would happen only on the Mac OS install and only while it synced the library back and forth.

Either solution works and I'd be more than happy with any fix that solves our problem.  But personally I think it's a bit cleaner to isolate the change to only where it's needed, namely the Library Client code.  That might also make for a simpler code change with less testing required.

[Cryph]

+1 -- by now it's more like +3
anytime I see a topic like this I comment... this is a major shortcoming of this software and like others, I'm a bit confused by the reluctance to implement a solution.
I also have very elaborate sync setups that work well enough, but I would love for my playlists and playcounts to sync, without any manual tricks.

If this is something that the developers never plan on implementing, please tell us this.
I continue to pay for new versions with the hope that one day this simple fix will be put into place.

[RoderickGI]

I bow to greater knowledge of WSL, CIFS, and Linux, MAC OS... and probably lots more. Like I said, I only did a quick Google on WSL and a little bit of reading, and even then I saw potential problems, which you have now confirmed. WSL is a "closed environment" by the sound of it.

However,

If a variable substitution was used as per matt's suggestion, then this is still an MC-specific thing.  Nothing to do with the OS.

I didn't write my suggestion well. I shouldn't have used the term "Global Variable" as it has MC connotations. I was relying on my interpretation of Matt's post too much.

My approach would be to use an OS Variable for each installation. The solution would be similar to your %BASEPATH% description, where the path to files in MC would be set to "%BASEPATH%\Media" and %BASEPATH% would be set in an environment variable to "Z:\" in the case of Windows, and as per your example for MAC OS and Linux. For Windows, the variable would be set in the Windows Environment, similar to the %PATH%, %APPDATA% and other environment variables. Perhaps the more specific variable name such as %JRBASEPATH% would be better. JRiver should provide some functionality to easily set that variable inside MC, which was my reference to "something needs to be done in MC".

With that solution, the substitution would indeed happen in the OS, and not in MC. Well, I guess it would happen in MC, but be driven by the OS.

Why keep aiming to do it in the OS? Well, I am assuming that this would be faster, and at the same time any other application, such as file sync software, that was capable of using an environment variable in their path settings could use this variable, and make the process simpler. But MC would need to be aware of environment variables and use them in paths in the library, which it doesn't seem to be capable of at the moment. A solution to that may be to copy the environment variable into a Global MC Variable, if MC can use them in paths. There are a lot of places (Options > File Locations) where MC will only allow browsing to a location rather than direct entry of a path, so this may be an issue.

So maybe your solution is simpler, and mine has too many disadvantages, or too much work to implement.


Frankly, despite the different naming conventions, I'm surprised that this issue hasn't been solved at the OS level, for all OS's.


Anyway, carry on. Unfortunately, I don't see a solution arriving any time soon.

[mattkhan]

An environment variable seems uglier from a user experience point of view but I don't really care how it is implemented tbh. Performance surely can't be a concern though as this really is such a trivial thing to handle (and actual file handling code is always os specific anyway)