More > JRiver Media Center 27 for Linux
Cross-platform server/client question
mattkhan:
--- Quote from: max096 on August 06, 2021, 02:18:26 pm ---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.
--- End quote ---
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:
--- Quote from: mattkhan on August 06, 2021, 04:41:27 pm ---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)
--- End quote ---
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 its 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:
--- Quote from: mattkhan on August 07, 2021, 03:50:14 am ---@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 :)
--- End quote ---
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 ;D
Navigation
[0] Message Index
[*] Previous page
Go to full version