Print

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

[clarus7]

I am trying to share a file server from a remote location. Using a site-to-site VPN, I verified that the VPN tunnel throughput is consistently >100Mbps from the PC that's running MC. I have mapped the remote server as a network drive in Windows.  Copying files from server can get ~100Mbps.  However, when I try to play file from the server in MC, looking at the network Ethernet throughput in task manager, I'm only getting <4Mbps of throughput, resulting in constant buffering.

Is there any configuration that can be changed to improve this behavior?  How can I improve MC read speed from the server to be close too the speed of copying files?

[mattkhan]

Are you using the use local file if available option?

[clarus7]

I have used local file server before and it works fine.  However, My server host over 60TB of data so it's not practical to duplicate it at two locations.

I have looked into this further. Using foobar2k, I can see that there is an initial bandwidth peak when playback started, presumably to fill up playback buffer, then bandwidth will settle at media bitrate.  playback was fine without buffering.  Contrast to MC, the peak to fill the buffer never happen, and subsequent data rate is always at or below the media bitrate. So increasing the size of the playback buffer is not going to help.  Knowing that the bandwidth of the VPN is not the limitation, I would consider this a problem with MC itself.  One additional datapoint is the ping time to the server is <70ms.  Understand that it could limit TCP thoughtput, but as it has shown that file copying (which is TCP traffic) can reach over 100Mbps, I don't see the round trip time of bandwidth to be the limitation here.

P.S. changing the subject to VPN problem is misleading.  I don't see a problem with the VPN. It is MC inability to sustain a reasonable media read speed over VPN.

[mattkhan]

I am not talking about duplicating it, I am referring to the option that tells MC to read the file directly instead of having the server serve it (potentially transcoding it along the way)

This then relies on the OS to deliver the file

Are you using this option? If not, try it to compare

[clarus7]

The server is strictly a file server, not transcoding anything.  The server has been mapped to a drive letter under windows explorer, so to MC it should be a local file, as Windows is handling the network portion. I believe this is what you are referring to.

[mattkhan]

Unless you use the option I mentioned, it doesn't (as far as I recall anyway)

Without seeing your settings, it's impossible to know if there is any conversion going on

You need to be certain otherwise impossible to know what the bottleneck is

[clarus7]

Please clarify which option you are referring to. I don't think I understand. I don't see such a setting in MC.
I am only playing back hi-res audio files, not video.

[mwillems]

I think part of what is confusing things is you're using the word server in an ambiguous way, so it is unclear if your server is also running a JRiver instance to which the client computer's JRiver instance is a client.  Most folks here use JRiver's media network options to create a jriver server/client setup, so mattkhan is talking about media network settings that can improve the performance of that kind of setup.  But maybe you're just talking about accessing remote files without a second instance of JRiver?

Could you clarify whether you are running one instance of JRiver that is accessing files directly from a NAS/remote file server, or whether you are running two instances of JRiver, one on the server and one on the client computer? 

[mattkhan]

good point, I was assuming it was referring to an MC server, sorry for the confusion

actually the point of that was just establishing whether MC is serving over the network or the OS is, if there is only 1 MC instance involved then it's a bit hard to see how MC is at fault as it will just be reading that from the filesystem

not easy to independently test this tbf, would need something like a vpn in another continent and then tunnel back to my own server after pinging it off that vpn

[clarus7]

Sorry if I didn't make that clear. I am only running only one instance of MC on Win11.  The NAS file server is only acting as a remote file storage. I thought that was implied when I said the server has been mapped as a network drive on Windows.

So all MC is doing is reading the data from the file server, not another instance of MC.

As I have explained earlier, bandwidth (>100Mbps) and latency (~70ms ping) of the VPN should not be an issue here.  Also foobar2K has no problem reading the same data from the same mapped network drive.  And I can copy files using the same path at ~100Mbps.

The expected behavior is the MC should read data into the buffer as quickly as possible when initial playback start, but it is not doing that.  It is currently reading at or below the media rate.

[mattkhan]

My fault, I read server and just assumed MC as a server

Anyway, how big are the files? Try the memory option which, I think, makes it load the whole file into memory first then play it. Measure network bandwidth while it does that and see if that is faster.

Speculation.... MC doesn't adjust it's internal buffer size dynamically to account for slow networks thus isn't starting the next read far enough in advance to avoid buffering

If the problem is resolved by the memory option then the above sounds plausible (but only MC devs can say for sure)

The other Q is whether/how windows, or the server, handles network shares with respect to reading file contents, possibly this is tunable? What is the server exactly?

[zybex]

Speculation.... MC doesn't adjust it's internal buffer size dynamically to account for slow networks thus isn't starting the next read far enough in advance to avoid buffering

It's possible MC is disabling the OS read-ahead with FILE_FLAG_NO_BUFFERING, or using FILE_FLAG_RANDOM_ACCESS. In this case the read-ahead buffering would need to be done properly by MC on slow networks (70ms is slow in this context).

[Hendrik]

We don't disable any OS-level caching or buffering, and also read in reasonable blocks (not byte by byte). Not sure why it wouldn't manage to read even something like an audio file at a high enough bandwidth.

[clarus7]

[Memory playback - load decoded file into memory] is already enabled.
I have also adjusted the prebuffering to 20 seconds.  All it does is it delay the onset of buffering when playback start.
As I said, observing the bandwidth utilization when playback start, it doesn't look right. I would expect an initiate spike to fill the buffer before settling down to media bitrate.
I have attached a bandwidth usage graph capture from Task Manager to illustrate my point.  Both software is playing back the same file from the same mapped network drive. The bitrate of the file is just under 5Mbps.

[zybex]

We don't disable any OS-level caching or buffering, and also read in reasonable blocks (not byte by byte). Not sure why it wouldn't manage to read even something like an audio file at a high enough bandwidth.

What about the RANDOM_ACCESS flag? It was being used on the Thumbnail reader until you removed it:
https://yabb.jriver.com/interact/index.php/topic,127472.msg885286.html#msg885286

[mattkhan]

Let me ask again, how big is the file?  What format is it?

Compare to the other option as per

https://yabb.jriver.com/interact/index.php/topic,111406.msg770015.html#msg770015

Also compare to without loading into memory

Ultimately given the niche scenario, it's unlikely anyone else is going to reproduce so it's on you to narrow it down to an MC problem systematically otherwise I think, not unreasonably, you're likely to get the "it's the os/network/hardware" answer

[clarus7]

File format is flac. bit rate ~4800kbps. (this is a 192-24 file)
The file size in this example is 112MB. However, the problem is not specific to a file. It's a general problem with anything with bitrate above 1Mbps.

I have attached the network throughput for the three different modes of memory playback.

loading non-decode file into memory shows that it can read at high bandwidth and finish quickly. However, this will break gapless playback as it has to wait to read in the next track completely before resuming playback.

If these three mode/capture shown does not indicate a specific problem with flac file playback when using "decoded file in memory playback". Please let me know what else would you need.  The bandwidth usage show that MC is not reading file as quickly as it should even when memory and bandwidth is available.

In addition, I try a different file format - SACD ISO file (5.6Mbps). Even when you specify "load full file into memory", it doesn't pull in the full track before it start playing. It does not show a peak in bandwidth during the initial buffering stage, only average at about 7.5Mbps. Fortunately, it is sufficient to maintain stutter free playback. Switching to "load decoded file into memory" doesn't change the bandwidth usage behavior.
I also try cue+wav file of a CD (1.4Mbps). The bandwidth usage is very similar to the SACD ISO file case average 7.5Mbps.

Based on these observation, seems like there is a specific problem with handling flac file memory playback with decoded file into memory.
For ISO/Cue file handling, there seems to be a ceiling for bandwidth usage.

[Hendrik]

What about the RANDOM_ACCESS flag? It was being used on the Thumbnail reader until you removed it:
https://yabb.jriver.com/interact/index.php/topic,127472.msg885286.html#msg885286

As the old thread indicates, its not actually used frequently, and definitely not for media files.

[clarus7]

Trying to follow up on this thread. Is there any additional information that I need to provide?

[JimH]

Can you test without the VPN?  Just to help determine where the problem is.