Print

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

[pepar]

If my content server is unRAID, my MC library server is Debian and a client is Win 10, will the client read the content directly from the unRAID SMB share or will the file come through the Debian MC Library box? At least a couple of years ago the answer was it would only read from the content server if the link was identical, IOW, the client system OS must be the same as the Library Server machine’s OS.

[max096]

Do you actually want the clients to read directly from SMB? Why? To me this sounds like a bit of a logistical nightmare.

If you just want to send the raw files (without any decoding happening on the server) you can change that in media network settings on the clients.

[mwillems]

If my content server is unRAID, my MC library server is Debian and a client is Win 10, will the client read the content directly from the unRAID SMB share or will the file come through the Debian MC Library box? At least a couple of years ago the answer was it would only read from the content server if the link was identical, IOW, the client system OS must be the same as the Library Server machine’s OS.

It will get them from the Debian JRiver server rather than directly from the NAS because the file paths won't be the same on the JRiver client and the JRiver server.  If the JRiver server and client are both Linux (or both Windows) the client can access the content directly from the NAS so long as the file paths are the same both places.  Direct file access cross platform is not currently possible unfortunately due to file path differences between the OS's.

Do you actually want the clients to read directly from SMB? Why? To me this sounds like a bit of a logistical nightmare.

If you just want to send the raw files (without any decoding happening on the server) you can change that in media network settings on the clients.

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.

[pepar]

Thanks I was *just* reviewing previous posts on the issue and found https://wiki.jriver.com/index.php/Troubleshooting_Network_and_Slow_Storage. Alas, I was hoping there was a workaround that would allow unRAID content server, Debian MC Library Server and Windows client. I have just learned that bitstreaming audio codecs is not implemented in Linux which points me to having Windows clients. As I had been planning an all-Debian Media Center setup, this cross platform limitation now means I need to move my MC Library Server to a Windows box. So I will need to put up with Windows' obsessive obtrusiveness for the simple function of handling the MC Library.

If there is a "suggestion box" a workaround for this would be my #1, #2, #3, etc. suggestion.

[mwillems]

Thanks I was *just* reviewing previous posts on the issue and found https://wiki.jriver.com/index.php/Troubleshooting_Network_and_Slow_Storage. Alas, I was hoping there was a workaround that would allow unRAID content server, Debian MC Library Server and Windows client. I have just learned that bitstreaming audio codecs is not implemented in Linux which points me to having Windows clients. As I had been planning an all-Debian Media Center setup, this cross platform limitation now means I need to move my MC Library Server to a Windows box. So I will need to put up with Windows' obsessive obtrusiveness for the simple function of handling the MC Library.

If there is a "suggestion box" a workaround for this would be my #1, #2, #3, etc. suggestion.

It is a bummer, I've migrated almost all my clients to Linux, I just have one windows client left and have just decided to live with it.  The machine won't qualify for the Windows 11 upgrade due to TPM issues so I'll be all Linux soon.

As an unrelated piece of (admittedly unsolicited) advice, are you sure it's worth migrating everything to Windows just for bitstreaming?  I mean JRiver is pretty capable of high quality decoding (except for ATMOS, I think), are you sure bitstreaming makes a difference for your use cases?  If I weren't playing content JRiver can't handle, I'd be asking myself if it's worth putting up with Windows just to decode farther down the chain, but that's just me.  Sorry for derailing!

[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]

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.

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.

[mattkhan]

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.

enforcing use of a single process on a single host as the process capable of streaming content is an architecturally and functionally inferior solution, it's not a life hack and it is one of a number of feature gaps between platforms unfortunately (which renders mc linux a rather limited thing)

[max096]

enforcing use of a single process on a single host as the process capable of streaming content is an architecturally and functionally inferior solution, it's not a life hack and it is one of a number of feature gaps between platforms unfortunately (which renders mc linux a rather limited thing)

I guess this is somewhat of an oppinion based topic then. I think it would not have to be 'inferior'. Thatīs just the state of it now because now SMB is outperforming it.

I think if I connect to a thing to stream something I should not be required to know where the content is comming from, much less required to have direct access to the underlying storage. Has nothing to do with forcing people to use a single process on a single host. Thatīs another thing entierly. But for most people itīs gonna be that way for either of the solutions, because most people do not have a fleet of storage units to distribute load accross.

In a way the comparison Im about to make is a bit silly, but Im gonna make it anyways. Say netflix required you to mount a drive to your PC to stream content without hickups. What would you say to that? Yes itīs not really the same since in JRiver case you own the PCs behind it. Netflix also wonīt stream a blue ray at full size, but thatīs not because they would not be capable of it. Bandwidth costs money that customers wonīt pay and people donīt have 1gbit internet. And you can be darn sure even though you connect to "one thing" itīs a fleet of processes (gigantic server clusters in fact) behind it.

And going beyond just Unix and Windows style paths. If you ever want to create a mobile, web or TV app that streams content optimally you kind of hard locked yourself out of this with the sentiment that requiering direct storage access is superior. Because for either of them the situation is by far worse than "oh sh*t the path looks a bit different".

[pepar]

I like the engagement that this topic has spurred. I get the impression that it’s come up before. Perhaps this will elevate it in the minds of the ppl steering the project and a closing of this “feature gap between platforms” will ensue.

From my years of “enteracting” in this space I would think the way forward would be to implement the feature rather than remove the options from the tree. Nudge, nudge. Wink, wink.

[mattkhan]

@max096 it seems like you're conflating two distinct things

1) the ability of any MC instance (client or server in MC terms) to (efficiently) playback any media it has access to
2) the ability of an MC server to (efficiently) deliver media to any renderer (MC or not)

MC certainly has gaps on both fronts but this thread is about point 1, your argument seems to be largely about 2 which is a much bigger problem requiring, one would think, more engineering resources than changing the root path and dealing with / vs \ in a path

[mwillems]

@max096 it seems like you're conflating two distinct things

1) the ability of any MC instance (client or server in MC terms) to (efficiently) playback any media it has access to
2) the ability of an MC server to (efficiently) deliver media to any renderer (MC or not)

MC certainly has gaps on both fronts but this thread is about point 1, your argument seems to be largely about 2 which is a much bigger problem requiring, one would think, more engineering resources than changing the root path and dealing with / vs \ in a path

I also think leveraging SMB (or other file access type methods) when its possible will be smart even if MC could seamlessly stream high bitrate media.  Network filesystem protocols like SMB have gone through lots of development, optimization, and enterprise battle testing over the years.  While SMB is by no means the most performant possible network filesystem , it's performant enough (at my house) to more or less saturate a Gb connection in direct transfers going from zero to full speed in about 1.5 seconds.  The MC server (hosted on the same hardware using the same network infrastructure) is not particularly close to being able to provide that level of streaming performance right now, but MC could probably get to a place where MC's streaming was more or less seamless for large files without ever reaching performance parity with SMB. 

So while it would certainly be optimal if an MC server could serve media in a completely transparent manner (and I agree with Max that that seems like a sensible long-term goal), given that network filesystems are very performant already, selectively piggy-backing on them when possible seems like a clear performance win until MC actually exceeds SMB's performance.  I don't think leveraging a client's ability to play "local" files is a solution to every problem, but it's a solution to a certain class of problems that's implemented already.  Basically, "play local files if available" is a free performance improvement for most home setups, just not for setups involving more than one OS