More > JRiver Media Center 27 for Linux
Cross-platform server/client question
pepar:
If anything, you have re-railed it.
I am a purist (otherwise known as anal) regarding sources being sources, processors being processors and amplifiers being amplifiers. Plus, as I was poking around in the MC bitstreaming settings I did not see DTS nor did I see any way to grid out what codec I would want to apply to a given input codec to derive rear channels from 5.1. There is far more flexibility in using the surround processor to handle the surround processing. :)
I am going to move from using a 4th Gen Intel NUC for MC to a custom built 10th Gen mini-ITX box. There is robust hardware video decoding in the newer CPU/chipset generations and Windows has customization that allow access "to the metal." At this point, I will have only one MC box that is both server and client. I will even be able to move to a Windows-only license as opposed to the master license I have had for years and only now realized Linux is a no go for my needs.
Jeff
pepar:
Perhaps a field could be added as a local customization to client to point it directly to the SMB share?
mattkhan:
A fix for this has been requested numerous times to no avail so far unfortunately
pepar:
It's the first time I have encountered a road block with MC. Up to now it's put Swiss Army knives to shame with its capabilities.
max096:
--- Quote from: mwillems on August 06, 2021, 09:16:21 am ---Direct file access from clients provides significantly better performance/user experience especially with high bitrate video (much better seeking, lower latency, fewer pauses, lower server load, etc.). Streaming through the server (even without transcoding) has overhead and doesn't perform as well as the client just reading a file it can "see" directly on the filesystem whether locally or through SMB/CIFS. Direct client file access also allows for file name based MadVR directives (e.g. setting deint=film for specific shows), which (last I checked) couldn't be set through tag editing.
As an example, my JRiver clients and server are both hardwired using gigabit ethernet to each other and the same NAS. When the clients can access the media directly, Blu Ray mkvs start in about a second, have no problem seeking, and never stop to buffer. When the clients have to stream from the server the films take about three seconds to start, seeking takes a few seconds, and about half the time a film will stop after a minute or two to buffer (usually only once or twice a film, but sometimes more). This is with no transcoding enabled on fast hardware. The difference between the two scenarios isn't enormous on fast equipment with well-behaved networking (although the buffering pauses are irritating), but my experience is that with less capable hardware using wifi the difference between the two can be more significant (i.e. seeking can take a very long time).
The "use local files if available" option in the client settings is designed to facilitate this use case (where direct file access is possible). Sadly it's not possible in the cross-platform context currently TMK.
EDIT: added examples from my experience.
--- End quote ---
Fair enough. I never had any problems with it. Though, since I use MC exclusively for Music files it´s not really much to ask for. A 100mb music file is already pretty outlandishly big and thats still a very small file to ask for.
Would be great to have some kind of proper file seeking in MCWS instead. Though, ofc that would be a lot of work too.
Providing some sort of way to provide path aliases in MC that it can replace in the path to find the files would also be technically working (and be surely far less work). But you can probably infer from my first post here that I´m not really of the oppinion that that is a very good solution. It feels kinda like a life hack for what should probably work without it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version