Print

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

[InflatableMouse]

My server is also my HTPC; it runs MC and is "the boss" over all media. It shares its library to the rest of the house.

My own PC has a network drive mapped to the same music files that the HTPC is serving. The PC's local library therefore plays files pulling them from a network drive - the same files MC's library server is serving. Does MC on my PC consider these files "local" even though they are on a network drive?

If so, if I connect my PC to the HTPC's library server and I play a file, will it choose my "local" file over the Library Server one with the option play local file if found turned on?

I think if that is the case, this is not wanted. I know I can turn the feature off but before doing so I'd like to know if this is indeed how it behaves and whether or not my conclusion that is is actually unwanted is right. I base my conclusion on the fact that MC's library server streaming is more efficient and more resilient to hickups than a plain reading from a SMB share.

Thanks.

[csimon]

Yes, this is my understanding of how the Play Local File If One Exists facility works. If the pathname to the file that the server delivers is resolvable on the client too (regardless of whether it's physically local or on a NAS - it means local relative to the PC) then the client retrieves the file directly rather than have the server stream it.

I'm not convinced that streaming would be more efficient. Network traffic is involved either way. If your files are indeed stored on the NAS then the server has to retrieve it via a SMB share anyway and THEN stream it to the client so 2 network steps are involved. If the client plays it locally then only one step is involved. that's why the option was provided, to remove the server from the equation.

Are you thinking along the lines that reading from a share is prone to blips, therefore having the server read, buffer and then stream should "even out" the blips? But wouldn't that be caterd for in the buffering parameters that you can set in the player?

[MrHaugen]

With the option on, the MC client will always look for a "local" copy to play first. It tries to connect to the share or mapped drive. This means that the path have to be exactly the same on both server and client. This makes the job for the server much easier, as it does not have to process much other than the normal file transfer traffic. Previously we had to wait quite a while before the server had sent enough data for the client to start playback. Often the whole file needed to be sent before playback. This might have changed now, but I still see no need of using MC to send the data instead of using SMB.

I've not tested much of MC's streaming capabilities, but I would think that MC is far away from being MORE effective streaming than doing a local playback. Even though the streaming was super effective, could you point out one real advantage of streaming instead of doing a "local" playback over the network??

[InflatableMouse]

I would assume a specific streaming protocol would be more efficient than simply reading from a CIFS/SAMBA network share. I don't believe it will sound better but I would think that putting a load on the server would affect plain file sharing more than it would affect a streaming server. One is handled by the OS the other is handled by MC.

[petrossa]

It doesn't work when the file is on a cloud server. I've uploaded a video to my dropbox account, when i try to replay it in MC18 it tries to connect to my library on my Server. It tells me it tries to connect to the IP adress of the server over the internet, instead of the network, and fails because that is blocked.

The program then goes into a loop trying to connect, failing, retrying. One has to close the program works to break the loop.

[MrHaugen]

I would assume a specific streaming protocol would be more efficient than simply reading from a CIFS/SAMBA network share. I don't believe it will sound better but I would think that putting a load on the server would affect plain file sharing more than it would affect a streaming server. One is handled by the OS the other is handled by MC.

I would assume the other way around. SMB have been around for a long time. It's quite effective. Streaming protocols have not been perfected that much. It's a child in comparison. And as in your case, it would have to access the share/disk anyway, in addition to routing it through MC and using streaming protocols. This makes me wonder how exactly those three steps can ever be more effective than going the direct route of sending it straight to the client? No, I think you have created a problem that does not exist. And even if it did, the differences would be so small it would not really make a difference.

[RussellS]

Even though the streaming was super effective, could you point out one real advantage of streaming instead of doing a "local" playback over the network??

I would totally agree with you that if the client is capable of playing back the video content locally then that is the way to go. However, if the client was not capable of playing back certain content you could then have the server convert the content and stream it to the client. This is something that I am currently looking at as I have a third client just in the spare room that is running on rather old hardware which will play back DVD's fine but will not play back HD content. Therefore if I turn off 'play local file' and select the video conversion to a suitable format then the client will play the streamed content.

Unfortunately, I have two issues at the moment with this approach. Firstly, you don't appear to be able to seek forwards or backwards on streamed content and, secondly, MC18 running on the server seems to sometimes lock up when attempting the video conversion.

[MrHaugen]

I would totally agree with you that if the client is capable of playing back the video content locally then that is the way to go. However, if the client was not capable of playing back certain content you could then have the server convert the content and stream it to the client. This is something that I am currently looking at as I have a third client just in the spare room that is running on rather old hardware which will play back DVD's fine but will not play back HD content. Therefore if I turn off 'play local file' and select the video conversion to a suitable format then the client will play the streamed content.

That's a good point. The conversion settings and local playback options should ideally be configured pr client in an ideal system. However, I do not believe JRiver would want to do that, as most computers today are rather fast and do not have much problem with HD content. That's just a guess from my side though.. If I were you, I would just upgrade the client