More > JRiver Media Center 33 for Linux

Feature Parity with Windows for Home Theater

<< < (5/5)

marko:

--- Quote from: Hendrik on January 27, 2025, 02:35:55 am ---As of 33.0.61, there is now a new tool included in Media Network to handle this - both client and server will need to update to make use of it.

You set this up once on the server under:
Media Network -> Advanced -> Configure media path override on clients for local file access

You can setup a path replacement rule for each of the supported OSes, which matches your network setup - eg. mounting the media shares in that place to achieve local file access. Slashes should be translated into the right direction automatically.
The way this is setup, you'll still need a unified setup over all your clients - but thats not too different from running a Windows-only setup, and I imagine mounting network shares in the same path on all systems of the same OS should not be too big of a hurdle.

For Windows clients, you don't necessarily even need to mount a share, as you can also use a network path in the form of \\server\share\ as a replacement.

I imagine for now this is the most useful with linux servers and Windows clients, but all cross-platform combinations should benefit to a degree, and more once we add DVD/BD support in the future.
It also does not require to be for cross-platform at all, but just the difference between server local path, and network path on clients.

Please give this a try and let me know if it helps to solve that particular problem.


--- End quote ---
I run a Windows 10 server feeding a Windows 11 HTPC client.
I rely heavily on the "play local file if one that matches the library server" setting. Have done for many many years. Things on the HTPC are faster, loads on the server are a lot less (thanks AlexB). Core media folders on the server are shared and mapped on the client to match the server filenames.

Do I need to/should I, concern myself with this new override?

Hendrik:

--- Quote from: marko on January 27, 2025, 12:47:43 pm ---I run a Windows 10 server feeding a Windows 11 HTPC client.
I rely heavily on the "play local file if one that matches the library server" setting. Have done for many many years. Things on the HTPC are faster, loads on the server are a lot less (thanks AlexB). Core media folders on the server are shared and mapped on the client to match the server filenames.

Do I need to/should I, concern myself with this new override?

--- End quote ---

If you have it working now with a common path? No. But it does give you the ability to have a different path on the server and on clients, which may make the setup easier for everyone going forward.

BryanC:

--- Quote from: mwillems on August 18, 2024, 01:06:30 pm ---5)  Remote control and media keys

On Windows MCE remote controls and keyboard media keys work as expected in JRiver.  Using them on Linux is challenging and requires significant work on the user's part.   

There are two separate remote/media key issues.  The first issue is that some media key presses don't seem to be implemented or work correctly.  For example, using a standard MCE remote that worked perfectly on Windows, I have never managed to get the remote control number keys working in theater view on Linux the way they do on Windows. This is the case even using the exact same Linux environment that the devs use for testing (XFCE4 on Debian).  Theater view on Linux just doesn't seem to respond to the number keys on the remote control at all even though they're sending the correct keypresses.  To be clear, typing numbers on the keyboard works fine, but the remote control number keys do not work even though they're sending the same keycodes!  Check out this thread for a recent(ish) example of another user struggling with remote control configuration seeing a similar issue: https://yabb.jriver.com/interact/index.php?topic=136975.0.

Second, there's a separate issue in that many common Linux desktop environments (DEs) (like Gnome, KDE, and I think Cinnamon too) consume some of the media keypresses and expect programs to use the MPRIS API to get them, but JRiver does not use MPRIS so using any remote or media key that the DEs "manage" requires a user workaround.  So for many Linux users the most common remote or media keys (play/pause, stop, volume control) will fail out of the box, and require some fairly laborious workarounds to get them working (remapping keys using custom JRiver configuration, and then remapping the remote to hit those new keys). 

To summarize, if you spin up JRiver on a default install of Debian (which uses the Gnome desktop environment as a default), Ubuntu (uses a modified Gnome as default), or Fedora (also Gnome by default), the majority of the remote control keys just won't work with no feedback as to why they're not working, and only some of those keys can be made to work via workarounds on the user side. 

--- End quote ---

GNOME 48 has addressed this with Global Shortcuts, perhaps it can eventually be implemented in MC?

Navigation

[0] Message Index

[*] Previous page