Print

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

[swiv3d]

Did you restart MC after switcing off Media network settings in General>Features?

[JimH]

This thread?
https://yabb.jriver.com/interact/index.php/topic,114101.0.html

[JimH]

Have you tried this on another machine?  It's possible you have a disk with problems.

[JimH]

Is it only with multi-channel files that you have the problem?

[trajanmcgill]

Have you tried this on another machine?  It's possible you have a disk with problems.

Yeah, my first thought was dying hard drive. Does it do this when reading the same file from another disk?

[TopDownDriver]

It appears so.  I also have a fair number of hi-res 192k stereo files which appear to play fine and start instantaneously when selected.

Thanks

[Spike1000]

My 2p as it only takes seconds,

Backup library, reinstall, restore library if needed.

or

Backup library, un-install, reinstall, restore library.

or Takes a bit longer

Backup library, un-install, reinstall, start again and re-import music.

There have been cases where 'weird things' just happen and re-installing MC simply makes them go away.

Spike

[JimH]

It appears so.  I also have a fair number of hi-res 192k stereo files which appear to play fine and start instantaneously when selected.

Thanks

If a stereo file works, but a multi-channel file gives you a long hesitation, then something is causing trouble reading the file.  Antivirus, bad disk, bandwidth limitations, etc.

kr4, who posted above, may have the most experience here with multi-channel files. 

[TopDownDriver]

I'm sorry, but that does not follow:

The files have been placed on either a NAS connected via a Gigabit network or locally on an SATA III HD.  The same results were observed.

We have eliminated Anti-virus from the system and double-checked that it is not interfering by going through the Task Manager and looking at the processes invoked.
It can not be a bad disk if other files work without issues from the same disks, including other large files (ie. 192k Stereo Files - which are about the same size as 96k Multi).
There are no Bandwidth limitations, I have run throughput tests on both the NAS and the drive and they have an overhead many times what is needed here.


Last point, which I made earlier, but may bave been lost.  Reinstalling on this machine makes no sense as I have observed the same behavior on our clients new/fresh computers.  This is only when it comes to the Multichannel files.  In general, 98% of our clients are not interested in Multichannel, so it has gone by the wayside.  However, one of our clients (recently) is.  So, I thought I would put forth some effort to try to solve this issue.

Through our efforts, we have determined that it is not a setting or other configuration issue in JRiver.
Through our effiorts, we have also determined that it is more than likely not something in the OS or with the hardware hat is causing the issue.

My only conclusion is that it is something within the JRiver processing engine which is causing the problem and it probably relates directly to the processing of Multichannel files.

in the interest of being throurough I will uninstall and reinstall JRiver this mornging and report back. I want to leave no stone unturned in trying to get to the bottom of this issue.  I would hope that the logs would have provided more detail.  If you need me to run a "debug" version of the software, I can as well.

I should also point out that I have a long career in the software industry and have designed and developed both audio and video systems for modern operating systems.  While not working as a programmer (I sold my company and retired a short while back) I believe that the only viable next step is a "deeper dive" into the inner workings of JRiver (if we hope to address this issue).

I thank you for your help and assistance is trying to figure out what is going on here.  I know it is maddening.  I will do a refresh of the system and report back shortly.

[kr4]

Through our efforts, we have determined that it is not a setting or other configuration issue in JRiver.
Through our effiorts, we have also determined that it is more than likely not something in the OS or with the hardware hat is causing the issue.

I do not think we can eliminate both of these possibilities simply because we have not found the culprit.   

My only conclusion is that it is something within the JRiver processing engine which is causing the problem and it probably relates directly to the processing of Multichannel files.

Consequently, I do not think that we can presume this although it might be true. However, I find this hard to accept because I have set up and used perhaps a dozen different machines for the specific function of playing high resolution multichannel files and not had such an issue on any of them.  That said, I have encountered it once or twice and it has only been necessary to tweak some parameter that was set by accident in order to restore good behavior.  Usually, it had to do with Memory Playback but I cannot recall specifics and, as we know, you have defeated that function.

My feeling is that there is probably some setting we have overlooked.

[TopDownDriver]

I do not disagree with your assertions however, I am out of options on what to check.

We have eliminated a lot of culprits.  I do not remember this happening in the past with earlier versions of JRiver.  I have set up more than two dozen clients with JRiver in the last few years (many more than that over the last 10).  I have only seen this is JRiver 23 & 24 (we use 23 here at the office and the last client had 24).  I do not know if it was in a previous version - I think it was not in JR 20 for example.

I am willing to keep trying.  I have uninstalled and am about to reinstall and restore the database.  We have about 200 Multichannel Albums in total.  Once restored I will begin to test and hope to post again within the hour.

Open to any and all suggestions.

[Awesome Donkey]

Random thought, but checking/monitoring DPC latency when these buffering issues occur might be worth looking into as well.

[trajanmcgill]

It can not be a bad disk if other files work without issues from the same disks, including other large files (ie. 192k Stereo Files - which are about the same size as 96k Multi).

That's not a conclusion which follows. One part of a disk can be unreadable or full of errors while another appears just fine. I've definitely seen dying disks display this sort of issue, where certain files are read okay and others are impossibly slow. Reading the same file from two different but fast sources would answer that question, but reading different files from the same source would not.

[TopDownDriver]

Yes, agreed.  However it is ALL of the Multichannel files on a redundant NAS which have this problem and NONE of the hi-res stereo files.

[TopDownDriver]

System is back up and here are the reports from LatencyMon - with the file type in question playing.

Also, reinstall - same problems with Buffering.

[kr4]

Yes, agreed.  However it is ALL of the Multichannel files on a redundant NAS which have this problem and NONE of the hi-res stereo files.

Is it possible to send me a file that is consistently problemmatic?  It would be great if it was one that I already have.

[TopDownDriver]

Nothing is consistently problematic.

For example - I will play one file and it will start immediately.
Sometimes the next file (non-sequential/random) will buffer, other times not.
Generally within the first five non-sequential plays a file will buffer from between 1.5 and 3 minutes.
Occasionally (about once in 10 files) the file will cut out in the middle and buffer from between 1.5 and 3 minutes before playing again.

Currently, I am testing with the Beatles White Album in 96k Multichannel format (WMA Lossless).  Though the behavior is the same for other albums and does not seem to matter if they are in FLAC or WMA Lossless.

[JimH]

Nothing is consistently problematic.

For example - I will play one file and it will start immediately.
Sometimes the next file (non-sequential/random) will buffer, other times not.
Generally within the first five non-sequential plays a file will buffer from between 1.5 and 3 minutes.

That behavior just has to be something somewhere in the system, not in MC.  Reading files should be consistent, especially if the files are on a local drive.  If you saw it on a network, I'd expect that the network might have other traffic that caused the problem, but not on a local drive.

Try a Google search for how to debug this problem using Windows system tools.

And don't rule out Windows Defender.

[kr4]

That behavior just has to be something somewhere in the system, not in MC.  Reading files should be consistent, especially if the files are on a local drive.

Agreed.

[DJLegba]

Reading files should be consistent, especially if the files are on a local drive.

You should be able to eliminate OS file reading as a suspect by using Windows Explorer to copy files from the NAS or wherever they're stored to the C: drive on the Windows 10 host. Windows will show you the transfer rate in the "more details" copy progress window. Compare multichannel files with similarly sized stereo files, and with 192k files you don't have trouble playing.

[TopDownDriver]

Done this.  48 Mb/sec. from the NAS.

[TopDownDriver]

Any further thoughts?  While my customers LOVE JRiver, we are getting more and more calls for multi-channel support from our systems.  Now with DVDFab introducing a one-step ripper for these file types, it is now easier than ever for our clients to do.

I would like to continue to support and sell JRiver MC - so long as we can get it to work reliably with multi-channel files.

[JimH]

I would like to continue to support and sell JRiver MC - so long as we can get it to work reliably with multi-channel files.

It does work reliably with multi-channel files.  I'm sorry it doesn't for you.

[TopDownDriver]

I can confirm on at least two different Windows 10 installations that it does not (at least it "buffers" for a long period of time on non-sequential files).

If it is not a problem in JRiver, then "my bad".

However, I have gone through all of the testing and configuration options, and tried both JRiver 23 and 24 with the same results (albeit on different systems).

I would like to get to the bottom of this and do not care if it is in the software or the environment.  Just would like answers to what is going on.

Any chance a "debug" version would help further identify what is causing the prolonged "buffering" issues?

[Matt]

Would you be willing to make a few files that cause the slow buffering available to me?  I'm matt at jriver.

Thanks.

[TopDownDriver]

Sure, they are too large to upload here.  Any chance there is a better way to get them to you.

Remember, the buffering is inconsistent and occurs when randomizing the files (ie, click on one, click on another, etc.)

Now that I think of it, perhaps it has something to do with flushing the buffer before playing the next file?

Let me know how I can get them to you

Thanks Matt

[Matt]

I think you might need to make a DropBox account or similar.  Or you can try attaching them to email one at a time.

[JimH]

You should be able to eliminate OS file reading as a suspect by using Windows Explorer ...

That wouldn't show what could happen if antivirus is getting in the way, which can happen for one program but not another.

[JimH]

If you have another machine to test, it would be interesting to see if it has the same problems.

[TopDownDriver]

Agreed.

However, Anti-Virus (Defender) is as disabled as I can get it in Windows 10 through the Group Policy Editor.
Also, have excluded all the folders and processes used by JRiver, just in case.

[TopDownDriver]

I did have access to another system running the latest build.

However that has been delivered to the customer and I no longer have access to it.  It did show the same issues when tested with the multi-channel files.  Here at the office we do have a Media Network set up and it occurs on both the main computer and the clients as well.

(Disabled all of this during previous testing to see if it was the Media Network settings which were causing the issues.)

[JimH]

Agreed.

However, Anti-Virus (Defender) is as disabled as I can get it in Windows 10 through the Group Policy Editor.
Also, have excluded all the folders and processes used by JRiver, just in case.

Did you read and follow the directions in the Windows Defender thread?  There is no way to disable it.

Antivirus programs should not be set to check media files.

[TopDownDriver]

You can indeed basically turn it off as far as it will go: http://www.wisecleaner.com/how-to/119-how-to-turn-off-windows-defender-in-windows-10.html

You can also add exclusions to it, which I did.

[TopDownDriver]

I think I "may" know what's going on.

Now, this does not seem to relate to the file stopping in the middle and rebuffering, but...

If I play a multichannel file, in general the first starts and plays immediately.
However, if I then double-click on another while the first one is playing, it will begin to buffer and can take as long as 3 minutes.
HOWEVER, if before I double-click on another file, I first STOP the one playing, the next one played will indeed play immediately.

It seems that the issue is a conflict in flushing the buffer and filling it at the same time.  My guess is that clicking STOP first, BEFORE launching the next file causes the buffer to be dropped.

Now, I can not confirm that this has anything whatsoever to do with the buffering mid file, but this might shed some light on something within JRiver.

Hope this helps (continuing to experiment)

[Matt]

What happens if you switch the track change mode between cross-fading, gapless, gapped, etc.?

[TopDownDriver]

Tried each at a setting of 1 second.  No difference.

[JimH]

You can indeed basically turn it off as far as it will go: http://www.wisecleaner.com/how-to/119-how-to-turn-off-windows-defender-in-windows-10.html

Dig a little deeper on that subject.  Here, for example:
https://yabb.jriver.com/interact/index.php/topic,117947.msg817206.html#msg817206

But try a Google search.  Please don't assume that Windows is innocent.

You can also add exclusions to it, which I did.

If you missed just one, you could see this kind of behavior.

[TopDownDriver]

Understood, though I think we've basically eliminated Defender as the culprit in this case.  We've hobbled it as much as possible with no change.
Still the other programs seem to work fine with it fully enabled.

Time to look elsewhere.

[RoderickGI]

I'm coming late to the party. Sorry. I thought you had quite enough help, and I don't have an answer anyway. I also haven't tested anything.

However, some observations:

From the Latency Monitor report; DPC count (execution time <250 µs): 243394. Assuming an average of 125 µs, that adds up to 30.4 seconds in a 2 minute 39 second run (or was that a 03:22:00 run?). That seems quite high. But I'm no expert on Latency Monitor.
Note: The Per CPU Data in the Report.txt file doesn't seem to be consistent with my assumption above, but I'm not sure I'm reading that right. The report says each processor DPC load is sub-second, which wouldn't be an issue.

The Hard Page Faults for MC23 seem high as well at 4131. I would expect MC to be reading files made up of sequential sectors, so most of each file would be read to memory on initial request. I think.

It may be worth spending more time with Latency Monitor, and having it running while the problem is caused.

It is worth noting that ndis.sys was the most used driver, and that during that 00:02:39 time period, it was working for 69.89 seconds. May not be an issue, but...

It looks like MC is taking lots of small nibbles at the files.

BTW, did the problem actually happen during that Latency Monitor run?

What is your audio playback device?  Sound card, USB DAC, network based device, etc.

As for playback, Multichannel LDPCM over HDMI to a Theta Casablanca Processor.

So, are you using the i7 HDMI out port? i.e. No discrete video card involved?

Intel iGPU capabilities haven't exactly been stellar, particularly HDMI support, which has been quite lacking. Last I heard, it still has problems with high resolution audio, or more correctly, later processors actually have reduced capabilties compared to earlier processors. I assume that you have the latest drivers for the processor, but maybe do some research around HDMI on iGPU and see if anything shows up. At least one report I read said that an earlier driver actually had better capabilities, but that may not be an option as the driver needs to support the processor version, and earlier drivers probably won't.

Also, do all of your builds with the problem use the Theta Casablanca Processor? Same version? Same firmawre? When using HDMI, it could be any component in the HDMI chain that is causing the problem. HDMI components talk to each other, and will change settings... or not, depending on capabilities.

Perhaps try with a discrete video card installed, and/or with HDMI output to a different set of devices? Worth eliminating as a possible cause.



The other thing you can do is use some of the Microsoft Sysinternals tools to try to narrow down exactly what is happening when the file is being buffered. They aren't easy tools to learn, but they may shed some light. There are lots of tools in the Suite.



PS: I understand that a couple of other applications play these files without issue, so it does sort of point to MC. But when the other applications play them, does the Theta Casablanca Processor report it is receiving the same signal type? i.e. Could the other applications be doing something you are unaware of to the audio before sending it to the processor? Are all applications using the same output mode, such as WASAPI Exclusive? Or is Direct Sound putting in an appearance?

Or maybe MC is trying to be too smart, and is treating the LDPCM (log differential pulse code modulation) differently to regular LPCM (is there a difference?), and is therefore doing some conversion, or not doing a conversion the others are? What does the MC Audio Path say?

[TopDownDriver]

Ok, where to start.  Thanks for the thorough report.

Latency Monitor - as I read it the latency was very low, as was the processor overhear.

Since the data was coming over the Gigabit Ethernet from a NAS, the number of Hard Page Faults is not out of line.  There are other things happening on the network, but they were of low-bandwidth requirement at the time.

The error was induced while Latency Monitor was running in order to create the best situation for diagnosing the problem.

NDIS.sys is the network driver.  This is why the "nibbles" are small and NDIS is being used a lot when the files are being read.  However, the general overhead is quite small.

The output is to the Theta Casablanca (a high-end processor) from an internal HDMI.  There is no option for either a different output for multichannel other than HDMI and no option for a dedicated sound card.  However, this should not affect the issue as unlike compressed audio (in which the HDMI output gets involved) this is simple multichannel LDPCM and is reported as such from the other software I have tried as well.

I have used Sysinternals before and am familiar.  Don't know what you are recommending in specific and what you think they can offer above and beyond what we already know.

The issue currently appears to be mishandling of the Buffer by MC.  It is not uncommon for someone to underestimate what is truly needed for such a complex file and/or not fully flush the buffer before attempting a new file.

The most telling issue is that pressing stop before a new file is run does not exhibit the issue.  Whereas simply playing one file after another (randomly - not sequentially) does cause the problem,

Thanks

[Hendrik]

The issue currently appears to be mishandling of the Buffer by MC.  It is not uncommon for someone to underestimate what is truly needed for such a complex file and/or not fully flush the buffer before attempting a new file.

Playing multi-channel audio isn't that exotic of a task anymore, and if there was a fundamental issue, we would be seeing more then one person reporting such issues. We have lots of people successfully playing high quality multi channel files, some even poking their head in in this thread.

As such, the more likely culprit is something common to the way your systems are setup.

In any case, there are a few things you can do to try to pin-point where the problem comes from:
- Enabling downmixing to stereo in MC, that will tell us if reading/decoding is the source of the problems, or the output
- Use another audio output temporarily, maybe like the analog audio outputs on the mainboard, just to see what happens, to rule out trouble with the HDMI audio driver

[Spike1000]

Done this.  48 Mb/sec. from the NAS.

I assume that's MB/s.   

That's more than enough! Are jumbo frames turned on at both ends? It should be possible to get close to 100MB/s on Gigabit connected NAS with jumbo frames enabled. Handy speed boost for people using gigabit connected storage.

Spike

Note: My broadband gigabit router baulks with jumbo frames so I use 'business' class switches to connect the devices in the house together.

[JimH]

Did you ever try this?

It might be worth checking the power settings.

[TopDownDriver]

Yes.

They are all set to Maximum with no sleep or turning of for anything.

I have also sent some sample files to Matt to take a look at to see what might be going on.  Hoping he finds something.

Peter

[Matt]

I can reproduce the slow buffering.  That's kind of a big deal.

It's using FFMpeg, so I sent an email to another team member and we'll see where it goes.

Thanks a lot for your help.

[TopDownDriver]

GREAT!

Extremely glad.  Beginning to think I was going nuts.  Happy to help!

[JimH]

Good to find the problem.   Sorry for the wild goose chase.  What is the source of the file?

[TopDownDriver]

A couple of multichannel tracks from The Beatles White Album (50th Anniversary).

These were ripped with the new DVDFab multichannel audio ripper.

[JimH]

Can you test files that weren't produced by that ripper?

[Hendrik]

A new tool that writes WMA files? Whats this, 2008?

Nobody in 2018 should be using WMA any longer.