Print

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

[flac.rules]

When MC is doing very intensive tasks that takes a while. For instance changing to a library with a lot of files and on a network. It has the tendency to "hang up" the whole system. The screen can freeze, network traffic can be disturbed and so on. It ends as soon as it is finished with the task. Could this be improved?

[JimH]

It's up to the OS to allocate resources appropriately.

Other possible factors are antivirus and NAS bandwidth.  Audio Analysis and thumbnailing could be turned off to help.

[flac.rules]

It's up to the OS to allocate resources appropriately.

Other possible factors are antivirus and NAS bandwidth.  Audio Analysis and thumbnailing could be turned off to help.

I am sure it is, nevertheless, it is the only program I have that exhibits this behavior, and it seems to be doing it on all computers in the situation i described. And as a user, I can't reprogram the OS.

There is no AV running, and bandwidth is 1 gigabit. (the bandwidth itself doesn't seem to be the problem though, there isn't huge amounts of data moving in the situation it seems like).

[steff]

OS, antivirus, network bandwidth, etc....
I can confirm... in the last weeks I setup MC23 on almost 5 different computers, from a low cost 400€ Intel Atom to a very expensive and powerfoul Intel i7.
Every time MC has to deal with a network, regadless the speed of the netowork and/or the NAS... it hangs until its job is finished.
Moreover the MC23 GUI expands to the full screen, becomes blurry and overlap the Windows taskbar.

It is not a matter of CPU or memory or network... it is a MC matter.

I have the responsability to manage 46.000 PC worlwide running hundreds of different applications and I never see a beahviour like this.

right now I am on the Intel i7, 32 GB RAM, it is a graphic workstation, connected to an enterprise grade NAS and 1 Gbps bandwidht fully avaialble. I loaded 500 GB of audio tracks... whenever I change the folder... MC23 starts "thinking", freezes, expands the windows and generally hangs until job finished. AV completely turned off (service disabled).
No problem at all browsing the very same music archive with a Raspberry running freeware software.

Let me say that MC is really a nice program, I love the theatre view (I got the license for this reason) but can be improved really a lot.

All the above problems do not appear with local files.

[JimH]

Every time MC has to deal with a network, regadless the speed of the netowork and/or the NAS... it hangs until its job is finished.

Still an OS issue.  Sorry.

[tij]

i have not programmed in ages ... so forgive me if i am wrong

if MC main process request OS to do something with LAN then wait before continue ... and OS takes it sweet time ... then MC becomes unresponsive till OS completes that task?

maybe create separate thread to hanle request to LAN ... so main MC thread remains responsive?

[JimH]

We do use threading a lot.

[Fitzcaraldo215]

OS, antivirus, network bandwidth, etc....
I can confirm... in the last weeks I setup MC23 on almost 5 different computers, from a low cost 400€ Intel Atom to a very expensive and powerfoul Intel i7.
Every time MC has to deal with a network, regadless the speed of the netowork and/or the NAS... it hangs until its job is finished.
Moreover the MC23 GUI expands to the full screen, becomes blurry and overlap the Windows taskbar.

It is not a matter of CPU or memory or network... it is a MC matter.

I have the responsability to manage 46.000 PC worlwide running hundreds of different applications and I never see a beahviour like this.

right now I am on the Intel i7, 32 GB RAM, it is a graphic workstation, connected to an enterprise grade NAS and 1 Gbps bandwidht fully avaialble. I loaded 500 GB of audio tracks... whenever I change the folder... MC23 starts "thinking", freezes, expands the windows and generally hangs until job finished. AV completely turned off (service disabled).
No problem at all browsing the very same music archive with a Raspberry running freeware software.

Let me say that MC is really a nice program, I love the theatre view (I got the license for this reason) but can be improved really a lot.

All the above problems do not appear with local files.

I have an older I7, 16GB and most files come from my NAS via gigabit Ethernet.  I do not have anything like the problems you describe.  When running JR 32-bit while converting Mch DSF files to PCM, applying JR bass management and using the Dirac Live VST plugin, initial buffering at the start of an album lasts just a few seconds, and the JR desktop GUI is on on my HiDef TV monitor, via an AMD GPU and HDMI.  There are no further delays or playback issues as each album is played.  CPU is in the 10-20% range and memory consumption is about 4GB, as I recall.  I do not use Memory Playback.

I have also during music playback added up to 5-6 separate, additional resource intensive  tasks in Windows, DSD rips, DSD ISO to DSF conversions, etc.  Playback is undisturbed.

So, I have no problem to report.  JR seems to work fine for me.

[flac.rules]

I have an older I7, 16GB and most files come from my NAS via gigabit Ethernet.  I do not have anything like the problems you describe.  When running JR 32-bit while converting Mch DSF files to PCM, applying JR bass management and using the Dirac Live VST plugin, initial buffering at the start of an album lasts just a few seconds, and the JR desktop GUI is on on my HiDef TV monitor, via an AMD GPU and HDMI.  There are no further delays or playback issues as each album is played.  CPU is in the 10-20% range and memory consumption is about 4GB, as I recall.  I do not use Memory Playback.

I have also during music playback added up to 5-6 separate, additional resource intensive  tasks in Windows, DSD rips, DSD ISO to DSF conversions, etc.  Playback is undisturbed.

So, I have no problem to report.  JR seems to work fine for me.

I am not talking about regular playback.

[Fitzcaraldo215]

I am not talking about regular playback.

Ok, but if you expect some help, why be so mysterious and elusive?  Please, give some specifics about exactly what you are attempting to do and more specific symptoms of the problem.

[steff]

Still an OS issue.  Sorry.

Unfortunately it is not an OS issue.

Maybe I did not explained in the correct way the problem.

Let me show a very simple example: browsing an archive hosted on a NAS or on another computer, even using 1 Gbps wired ethernet, is not of course a matter of micro-seconds... it depends on the number of folders and files.
So it is absolutely NORMAL to experience a delay in the MC23 responsiveness... ok? this is not the problem, it is normale ad acceptable.

What is NOT normal is that during this time MC23 hangs... its windows expands to the full screen, overlapping even the Windows taskbar (so unable to do anything else) and become totally blurry.
This is not normal!
the delay is nornal, the behaviour during the delay is not.

Moreover, if the delay is significative... then you can even face the Windows pop-up saying that MC23 is not responding and asking if you wish to wait or close the program.
This is not normal!

when my end user are working with the SAP GUI and they submit a huge query, maybe thay have to wait several seconds, but the application does not hang!
when others are working with CAD\CAE programs and they deal with several Gbytes data... it is a matter of minutes, not seconds but the interface of Catia or ProE does not hang end no one receive a message from windows to eventually kill the applications.

hope to be more clear now.

[RoderickGI]

Actually, except for the window expanding to full screen, overlapping the taskbar and so on, I have occasionally seen Windows Explorer exhibiting this "locked up, won't respond" condition since upgrading to Windows 10. Internet Explorer as well. Typically when I am searching for something using Windows Explorer, where even the progress bar for the search locks up, and trying to close Explorer just won't work. Although I have never seen the popup asking if you should wait or close the application. I also see long delays to display the contents of a network folder using Windows Explorer, and at other times it is almost instant. I do see the issue on MC at times. I nearly always just tell it to wait, unless I don't have time. It often comes back within seconds, and sometimes never comes back, but usually only if I have been doing a lot of tagging or moving of files, or using a Client extensively and them return to use the Server.

So I think most of the issue is an OS issue, but I have been unable to determine what is driving that it. It could be my virus scanner trying to check a whole disk, it could be the Windows Indexing function trying to index and/or catch up on the file changes. Sometimes Windows even tells me it is indexing files. It does happen too often in MC, but then for me, MC is often making small modifications to many, many files, and so either the virus scanner or indexing could be the issue. It does look to me that MC is waiting for some other thread to complete, or even more likely, MC is being prevented from doing anything until some OS thread has passed control back to it. It could be that MC retains a lock on the last file it touched (or seems to always) and some other Windows process (virus scanner or indexing) is waiting for MC to release that lock so it can do its thing and return control to MC.


The comparison to SAP is entirely unfair. MC looks like it has a database, but it is actually a flat file system that is programmatically operating as a database. SAP running on Oracle or any of the other options runs a full-blown database server with built-in database functions. Much of the data processing is happening on highly optimised algorithms built into the database. Often the User Interface is a thin Client and is not doing any processing, so it can go on and do other tasks, particularly handle user interaction. CAD\CAE programs operate in a very similar way, unless you are running them fully on a stand-alone Workstation, and even then there are support services running under the hood. Not a relevant comparison to a US$50 consumer product at all.

But I agree that I see it too often with MC, and it would be nice to know why, and how to avoid it. However I think it might be installation specific, with Windows, Drivers, other applications, and Hardware all contributing. So very difficult to find a definitive answer.


Regarding the window expanding to full screen, overlapping the taskbar and so on, I think you need to look to your video card, driver, default Windows resolution, and so on to find an answer. There are a few, very few, situations where Windows will sort of defocus the current window and change the resolution, font, or something. I can't even think of an example at the moment. Nor have I seen it in a long time.

[Spike1000]

Regarding the window expanding to full screen, overlapping the taskbar and so on, I think you need to look to your video card, driver, default Windows resolution, and so on to find an answer. There are a few, very few, situations where Windows will sort of defocus the current window and change the resolution, font, or something. I can't even think of an example at the moment. Nor have I seen it in a long time.

I've seen the 'overlapping' of the task bar many times. The defocus/blurry screen is caused by the window (MC is full screen) being re-sized to map over the space where the task bar was. The 1 to 1 pixel mapping is lost as the screen is re-scaled to fit the larger space, this causes it go a bit blurry. It's not a resolution change as I think you're describing it so I don't think it's a driver/video card issue as you describe.

I have never seen this screen related behaviour in any other application (I have experience in managing 100s and 100s of them in enterprise situations).
My guess is that this is caused by a key thread that gets 'stuck' (or maxed out) for a few seconds. It always recovers if you leave it, if you try and interrupt it you get a 'grey' screen and a 'program not responding' error. This behaviour I *have* seen in at least one other application and that is caused by a key thread getting 'stuck' (or probably maxed out in this case); again, in that case if you leave it it always recovers.

In my experience it's not related to the network as I see it most often with a high spec standalone laptop (i7, 16GB, SSD, W10 etc).

Spike

[flac.rules]

Ok, but if you expect some help, why be so mysterious and elusive?  Please, give some specifics about exactly what you are attempting to do and more specific symptoms of the problem.

I wasn't trying to be mysterious or elusive, in fact in my very first post i present a very concrete specific case where the problem occurs, and what happens.

[flac.rules]

So I think most of the issue is an OS issue, but I have been unable to determine what is driving that it. It could be my virus scanner trying to check a whole disk, it could be the Windows Indexing function trying to index and/or catch up on the file changes. Sometimes Windows even tells me it is indexing files. It does happen too often in MC, but then for me, MC is often making small modifications to many, many files, and so either the virus scanner or indexing could be the issue. It does look to me that MC is waiting for some other thread to complete, or even more likely, MC is being prevented from doing anything until some OS thread has passed control back to it. It could be that MC retains a lock on the last file it touched (or seems to always) and some other Windows process (virus scanner or indexing) is waiting for MC to release that lock so it can do its thing and return control to MC.


The comparison to SAP is entirely unfair. MC looks like it has a database, but it is actually a flat file system that is programmatically operating as a database. SAP running on Oracle or any of the other options runs a full-blown database server with built-in database functions. Much of the data processing is happening on highly optimised algorithms built into the database. Often the User Interface is a thin Client and is not doing any processing, so it can go on and do other tasks, particularly handle user interaction. CAD\CAE programs operate in a very similar way, unless you are running them fully on a stand-alone Workstation, and even then there are support services running under the hood. Not a relevant comparison to a US$50 consumer product at all.

It might be (and it probably is) an OS issue, but we as users can't do anything about the OS, fair or not, programs should try to behave as nice as possible, even when the OS does stupid stuff.

And this isn't something only CAD-programs do well. It is normal behavior for free programs also to handle this kind of time consuming tasks without "hanging up" and disturbing the system.

[Fitzcaraldo215]

I wasn't trying to be mysterious or elusive, in fact in my very first post i present a very concrete specific case where the problem occurs, and what happens.

OK.  There seem to be different issues described in this thread.  Yours was about changing JR libraries.  I used to do that, and it was a pain.  I now use a single main library with appropriate tagging and selective displays - Classical, Mch Classical, - By Artist, - By Composer, By Genre, Stereo Classical, Non-Classical, etc., etc. 

Others seem to be describing issues during actual playback.

[flac.rules]

It does seem like it is a pretty normal problem then.

I don't know if it is of any help, but when i first start the program, loading the library is fine, it puts a progress bar, and it works well.

[tzr916]

I don't change libraries and I have not seen your symptoms, but I can make MC go into "not responding" just by telling it to create a log file (Help>Logging>Report a Problem). The computer is still usable but MC is not, until after it finishes creating the log. Also, I have to limit the size of the MC log because anything greater than 3GB will end up being a corrupt zip file that has to be repaired by a third party program.

[steff]

I just identified another case:
Load Full Album into memory enabled
Album stored on a NAS

I am playing a FLAC without problem, then, while playing, without waiting the end of the file, I switch to another file.
What happens?
While still playing the "old" file, MC23 starts to load into memory the new one and you can see the network usage to grow.
When the new file is finally fully loaded into memory, then MC23 stops to play the old one and switch to the new one.

So... when MC23 is in the middle, while still playing the old one but loading the new one, then MC23 GUI expands to the maximum, overlapping the Windows taskbar and becoming blurry.
Everything is restored when MC23 stop with the old file and switch to the new one.

If the above scenario is applied during the "Theatre View", in the theatre view appears the Windows taskbar and it disappear when MC23 start playing the new file.

I really need MC23 to be modified: if memory playback is enabled, I do it because I do not want any disk or network activities during playback
If I switch track in the middle while playing, I pretend that MC23 stops playing the old file immediately, loads the new file and start playing it just when fully loaded.

It is quite a nonsense the bahaviour we have now. At least put a switch in the Audio Options...

[Spike1000]

I can make MC go into "not responding" just by telling it to create a log file (Help>Logging>Report a Problem). The computer is still usable but MC is not, until after it finishes creating the log.

I just identified another case:
I am playing a FLAC without problem, then, while playing, without waiting the end of the file, I switch to another file.
What happens?
While still playing the "old" file, MC23 starts to load into memory the new one and you can see the network usage to grow.
When the new file is finally fully loaded into memory, then MC23 stops to play the old one and switch to the new one.

So... when MC23 is in the middle, while still playing the old one but loading the new one, then MC23 GUI expands to the maximum, overlapping the Windows taskbar and
becoming blurry.

If these (or at least one of them) turn out to be repeatable scenarios then hopefully the MC developers will look into it and be able to understand the root cause and mitigate/fix the underlying issue as it's causing a pretty 'ugly' UI glitch at the moment that's not great advertising for MC.

Spike

[dtc]

If I switch track in the middle while playing, I pretend that MC23 stops playing the old file immediately, loads the new file and start playing it just when fully loaded.

You can just hit Stop before selecting the new file.

[steff]

You can just hit Stop before selecting the new file.

I am really sorry to hear such answer.
Of course I can do that!!!
Of course I can even go back to my 30 € Raspberry and avoid to spend 400 € for a Windows laptop and 50 € for the MC license
Of course I can do many other things, but.... since MC IS NOT FREE and since I am paying for it, therefore if there is bug, it must be fixed... if there is a behaviour that can be improved, it must be improved... if there is a beahviour that is quite a nonsense even if it is not a real bug... and so on.

Again, of course I evaluated MC within the trial period, but... let me say that something can be always discovered after the trial.

Load full file into memory does not work and I spent days to demostrate such issue here and everybody was saying it was a problem of my PC or my NAS or my network. Finally we are sure that it is not working at all
It will be fixed next MC release. but when? I do not know.

Anyway... play from memory is something that an audio purist search for, to avoid to have network activities or disk access during playback. Stop. No more additional comments can be made.
Then why, having memory playback enabled, switching to another track does not stop automatically the player and starts to load the new file?
You can like it or not, but this shuld be the correct bahaviour.
if you do not like it, you can put a switch in the settings and let the end user to choose.

I already said that I like MC anyway because of the theatre view.
But since MC is not free, we must fix problems.

Usually end users are helped from the community when they deal with open source software.
Seems that with MC we have a not free software, but supported by the community.

[steff]

If these (or at least one of them) turn out to be repeatable scenarios then...

I tested this behaviour on all my laptops and appear whenever there is a quite intense or moderate network activity while playing at the same time.

Let me say that if memory playback is not enabled, then MC loads and plays the file little by little and there is no problem.
if memory playback is enabled then MC loads the file in a short time, loading for few seconds the network to the maximum allowed and if MC is playing... then I experience this behaviour.

[RoderickGI]

I just identified another case:
Load Full Album into memory enabled
Album stored on a NAS

I am playing a FLAC without problem, then, while playing, without waiting the end of the file, I switch to another file.
What happens?
While still playing the "old" file, MC23 starts to load into memory the new one and you can see the network usage to grow.
When the new file is finally fully loaded into memory, then MC23 stops to play the old one and switch to the new one.

So... when MC23 is in the middle, while still playing the old one but loading the new one, then MC23 GUI expands to the maximum, overlapping the Windows taskbar and becoming blurry.
Everything is restored when MC23 stop with the old file and switch to the new one.

I just tried very hard to replicate this issue using Standard View first maximised, and then sized to fit in the middle of my screen. I assumed that the scenario above was in Standard View, because you mentioned Theatre View separately later.

Using my Workstation I imported eight albums each with 14 to 22 tracks directly from my HTPC MC Server, using a URI such as \\HTPC\Music\, so that the files have to be loaded over the network.

My 1Gbps network was still to fast and Albums loaded to quickly to force any issue, so I throttled my network connection to 10Mbps. I then always got the little "Loading Tracks" message windows in MC, and my network was 90 to 100% loaded until the next Album fully loaded. In fact the little message window closed before the Album was fully loaded, and Windows showed the mouse icon as the busy icon. If I clicked on something in MC I got the "MC is not responding" Windows dialogue and MC showed as bleached out behind the dialogue window. I clicked the "Wait for the program to respond" option and MC stayed bleached out until it caught up again by finishing loading the next Album and started playing it. Playback of music never stopped during this process.

The MC GUI (Standard View) never changed size, and while I could make it bleach out with the "Not responding" message, that only happened if I clicked something after clicking play for the second Album, and before the second Album finished loading. I don't think you are talking about the bleaching when you say MC becomes blurry, in which case I never saw that either.

I didn't do the test with Theatre View.

While you could, and many have, argue that MC should remain responsive and not "bleach out" when it is busy and something is clicked on, I don't think that is the issue you are raising here. Certainly there is no bleaching or "MC is not responding" Windows dialogue when all the user has done is click play on a second Album while one is already playing, and while using the "Load full album (not decoded) into memory" setting.


EDIT: Wait. I didn't have my Task Bar permanently displaying, but had it automatically hiding. So I changed it to always display and maximised MC then followed the scenario. What I observed was that as soon as the "Loading Tracks" message window closed, which happens before the Album load completes, MC expanded downward to cover the Task Bar. When loading finished and the second Album started playing, MC contracted upward to redisplay the Task Bar. That looks like a Windows issue, as I have seen that sort of thing before in other applications. MC didn't become blurry at any time when I did this.

So Steff, is that what you are seeing?




Regardless, could you make a video of the issue and post it to YouTube so we can see exactly what you are seeing. Start with nothing playing, play the first album, then click play for a second album, as per your scenario above.

[dtc]

It will be fixed next MC release. but when? I do not know.

The original problem with flac files is fixed in the current  Beta release. Should be released shortly I assume.

By the way, I am just another user trying to help you find a solution.

[RoderickGI]

Ah I missed that, and I was testing using MC23.0.96, so I had that fix.

I wonder if that is the issue here though, as I still see some of the symptoms.

23.0.96 (1/24/2018)
6. Fixed: The option to load a non-decoded file to memory wasn't working properly for FLAC files.
https://wiki.jriver.com/index.php/Release_Notes_MC23

[steff]

I am resuming here a test case that I am able to reproduce anytime on 3 different PC (Intel CoreM, Atom and i7)
all of them running Windows 10, Home or Pro, Windows updated and MC23

Environment:
FLAC or DSF files hosted on remote NAS or another PC using CIFS\SAMBA mapped network drive
Windows taskbar is not hidden
MC23 windows is expanded to the maximum
Load file into memory option enabled

1) start playing xxx FLAC\DSF file
2) xxx begins to be loaded into the memory, no sound so far, ok
3) xxx is fully loaded and it starts to be played, sounds good
4) without stopping xxx, switch to play yyy file
5) let me assume it takes 10 seconds to load yyy into memory (my FLAC or DSF are quite huge, 24\352 or 11 MHz)
6) while xxx is still being played, MC23 starts to load yyy into memory
7) when yyy is fully loaded into memory, then xxx stops and yyy begins

Problem A
During the above step 6):
- MC23 window expands over the Windows taskbar, overlapping it
- MC23 becomes no more responsive
- you can see the mouse pointer becomes a spinning circle
- MC23 window becomes totally blurry
- sometimes, not always, depending on how long it takes to complete the step 6), a Windows pop-up appears saying that MC23 is not responding and asking to choose to wait or to close the program.
Considerations:
- stop playing xxx file before moving to file yyy is a workaroud to avoid above problems
- the fastes is the network, the shortest is the problem lasting, but MORE INTENSE
If the theatre view is enabled, then the bahviour is a little bit different: the Windows taskbar appears on the Theatre View.

Problem B
- Playback from memory is something choose by audio purists to avoid (as much as possible) disk and network activities during the playback
- If a MC23 end user choose to play from memory, having in step 6) xxx being played and yyy being loaded from network is TOTALLY WRONG
- MC23 needs to be modified in this way: if memory playback is enabled, then xxx must be stopped before yyy starts to be loaded. Alternative solution: put a switch to control the behaviour

[flac.rules]

Not a very critical case, and I only tested it once, but its easy, so worth a try.

Advanced-tools, audio calibration - > Create test files (let them be written to a network-connected area), it takes a little while, if you click on the main window while its working, the window maximizes and taskbar is hidden. It is "not responding" until the task is finished. (you have to click pretty fast, the task doesn't take that long)

[RoderickGI]

Okay, that is a clearer description. It seems that what I saw is what you are seeing, except what I call "bleaching" you call the MC interface becoming blurry.

Problem A:
Honestly, I don't think it is good that MC interface becomes unresponsive while it is loading a file or album to memory. A user should still be able to switch views and do some other activities while audio files are loading.

The expansion of a maximised application over the Task Bar when it does become unresponsive I think is a Windows issue. If you didn't have MC maximised it wouldn't happen. You could just size MC to fill most of the screen as if it was maximised and you wouldn't lose access to the Task Bar. I did that and it worked fine. MC will remember its size and position each time you start it. I was able to use other applications while MC was unresponsive. Alt-Tab is still available to you, and maybe Ctrl-ESC.

Problem B:
How MC works here is personal preference. If you can hear an impact on the audio quality while the second file is being loaded, then maybe a setting to stop playback of the first file while the second is loading would make sense. I certainly don't need that setting, and I suspect many other users don't either.

But as an audio purist, when you decide to stop playing the first file and start playing the second file, and you are willing to wait in silence while the second file loads, the simple answer, as suggested above, is to hit Stop before loading the second file. It isn't a big ask to do that.



Anyway, the issues you have are now clearly documented. No doubt the JRiver developers have seen the discussion. They will decide to do something about it, or not, just like any software developer no matter the size and cost of the application.

[steff]

added a note to my test case

If the theatre view is enabled, then the bahviour is a little bit different: the Windows taskbar appears on top to the Theatre View.

Regarding problem B)
What should be the reason to enable the memory palyback?
Why some people need memory playback?

[RoderickGI]

Memory Playback has always been controversial. I'm not going to engage in that debate.

[steff]

Memory Playback has always been controversial. I'm not going to engage in that debate.

Sorry, but... if there is a feature in a product, whatever the product itself, I suppose there is a "need" that the feature addresses.

The need to to have memory playback si to avoid disk or network activities during the playback, and this is obvious.

Then, swithcing fron one track to another and having MC loading from network while playing is something that does not match to the above sentence "... to avoid disk or network activities during the playback..."

That's all.

[BillT]

Sorry, but... if there is a feature in a product, whatever the product itself, I suppose there is a "need" that the feature addresses.

There is no "need" for a lot of features in products. Features may be added because it's good marketing (my washing machine has umpteen pointless washing programmes, about 4 is more than enough) or enough people clamour for a feature, or maybe the developers like the feature.

A lot of modern devices are virtually unusable because of feature bloat combined with appalling interface design. (You could argue that JRiver suffers from these.)

In the case of memory playback I'd guess that it was fairly easy to add and kept a small, vocal section of users quiet. (Despite the fact that there is no "need" at all for memory playback!)

[Spike1000]

Memory Playback has always been controversial. I'm not going to engage in that debate.

Here here! If this thread turns into a another unnecessary debate on memory playback it will get shut down.

To the other members contributing to this thread (ie not RoderickGI) please use another thread for that discussion if you must, or ideally, read the other historical threads on it and refrain from posting at all.

Spike

[Awesome Donkey]

Audiophile myths and claims aside, using memory playback useful when doing 1:1 comparisons with my main library and backup library. If memory playback is disabled, a file that's playing is in-use (and locked) and it throws off my tools to check for changes between libraries. With memory playback enabled, it doesn't do this, so that's why I use it.

[steff]

From the JRiver WiKi
"Play files from memory instead of disk (not zone-specific)
This option loads an entire file into memory so that the disk is not accessed during playback"

This is what declared by JRiver.
But is is not (always) thrue.

Switching track while playing, let the old track to be played while the new one os being loaded.

So please modify MC23 adding a switch to optionally stop playing old track when switching to a new one.

I can explain here what I noticed.
First af all: many laptops today do not have wired ethernet connectivity... just WiFi.
The two ones I am dealing today are HP: x2-10 and 1012... both have 802.11ac and I connect @ 600 Mbps with a SUSTAINED transfer rate of 40 Mbps... so really a good throughput.
I noticed that playing a high resolution file from a mapped network drive is always stuttering quite a lot, but loading it into memory in advance IS NOT!
So... memory playback is a must have for my case.
Moreover... I run the DPC Latency checker tool and I also noticed that every time my audio dropped, I have a big "spike" in the latency and at the same time there is a network burst in the data transfer
OK... then I forced the WLAN adapter to work with 802.11n
WOW!
Big improvement!
Forcing 802.11n will lower the bandwidht, the network burst are much lower, but the duration is longer (of course)
Having lower network burst ... the spike in the latency is much lower and so... less freuqent audio dropouts.
At the of the story, forcing 802.11g will lower much more the network burst and there is no more latency spikes and no more audio dropouts at all!!!

I hope this is clear and could help others.

regards.

[millst]

If the rest of your applications and Windows itself are responsive when the JRiver UI becomes non-responsive, then the problem lies in the design of JRiver itself. UIs are almost exclusively single-threaded and are executed on the application's main thread. If the UI is not responsive, it's because so much work is being done on that thread that it can't service the user's requests.

The main solution is to make better use of threads/processes. I/O requests (network, disk, etc.) take time and should never be performed on the UI thread. If there is a lot of processing that must be performed on the UI thread, then another solution is to throttle that execution. It will take longer, but the UI will still be responsive.

-tm

[mattkhan]

attempting to play files so large you can't stream them so you have to enforce a period of silence between tracks seems a like terrible user experience to me. The moral of the story seems more like use content your network can handle so you don't have to sit around in silence!

[RoderickGI]

Steff do you get stuttering of the audio when a second file is being loaded and the MC interface becomes unresponsive? I didn't get any stuttering in my tests.

Do you hear a difference in the sound while this issue occurs?

If you don't get either stuttering or hear a change in sound, and you are only using memory playback for the reasons you gave, and not just because you believe network activity is just a bad thing during playback, then I would think that the situation is, if not desirable, at least meeting your need. The primary need you have seems to be stated clearly here:

I noticed that playing a high resolution file from a mapped network drive is always stuttering quite a lot, but loading it into memory in advance IS NOT!

MC is achieving your goal. It just isn't pretty.

As I said above, I am sure that the developers have seen this thread by now. Maybe a fix is now on the list of things to do. JRiver never makes promises about changes like this, which do not involve a bug but do impact the user experience. It really is a case of waiting to see if a fix is implemented. I have personally waited as much as two years for something that I thought was an obvious improvement that many users would want. But I've also had some issues fixed within hours. That is just the way it is. You have suggested a quick fix which would be easy to implement; A switch to stop playback while a new file is loading. A long-term and better fix for most users would be to make some changes in the threading of tasks MC does, but that would not even meet your wish to have no network activity while playback is occurring. That takes me back to my point above; Do you just want no network activity, or do you want no stuttering and clean sound all the time?

Remember, with many other applications you often have no access to developers, and even bugs can be left in place for years, let alone perceived user issues.


I do think that this is a good idea:

The main solution is to make better use of threads/processes. I/O requests (network, disk, etc.) take time and should never be performed on the UI thread. If there is a lot of processing that must be performed on the UI thread, then another solution is to throttle that execution. It will take longer, but the UI will still be responsive.

I would like to see this done, as it is a very bad user experience for the MC User Interface to effectively lock up and become unresponsive when doing normal tasks. I see it too often. Even a popup message that said. "Please Wait" would be better than MC becoming unresponsive. But I know what it is, and it often only lasts seconds, so it doesn't spoil my day.


Finally, I can confirm that I saw large spikes in network activity while a second album was loading in my tests. The network was continuously showing ~100% load, then 0% load, then ~100% load, etc. for Media Center. It would be far better if the network load was more consistent and did not consume 100% of the bandwidth at any time. This does seem like a design flaw. I don't know what is possible to manage this, but maybe some throttling of MC to 50 to 80% of available network bandwidth, rather than the current "load the file(s) as fast as possible".

[steff]

If the rest of your applications and Windows itself are responsive when the JRiver UI becomes non-responsive...

YES, just MC become non-responsive.
of course, since MC's GUI expand over the Windows taskbar, I have to use Alt-Tab to switch so something else than MC GUI.
Anyway, this PC is dedicated to play music with MC, so I do not need to do something different.
It is just not so nice to have the GUI behaves in this way, it gets blurry... and if using the Theatre View, then the Windows taskbar pops up in front.
It is not nice...

[steff]

Steff do you get stuttering of the audio when a second file is being loaded and the MC interface becomes unresponsive? I didn't get any stuttering in my tests.

As I explained, YES... while the old file is being played and the new one is being loaded from memory, network is used up to 100%, the audio played is terrible.
The workaroud I found is to force the WLAN adapter from 802.11ac down to 802.11n or... even better... down to 802.11g
In this case I do not see huge network spikes... I do not see DPC latency spikes and audio is fine.

if we de-couple the playing activity from the network activity.. of course I do not have any problems at all... I can leave the WLAN adapter to its default 802.11ac... and with such high speed is a matter of few seconds.

[dtc]

With Loading Full Album (Not decoded), it can sometimes takes a while to load. That is why Matt added a Loading Files message if the load is going to take very long.  And, yes, the UI is unresponsive during that time. But I am OK with that. I am, after all, loading up a full album with the idea that I am going to play the whole thing. A little wait is OK and there is not much MC can do about the speed of the network and/or drives. Would it be better to have the UI immediately respond. Sure. But is it generally not a big deal. As I said, I am about to play 40 minutes or more of music. I can wait 20 seconds for loading. And, the Loading Files message tells me what is about to happen. If the loading is taking several minutes, then it can become an issue. But the only time I have long waits is on very large albums, like 5+ GB DSD albums.

When playing a full album from memory, if I select a new album to play, playback continues until the new album is loaded.  That is OK with me, as I would rather listen to the music than have silence while waiting. I do not have any glitches during the transition.  If I want silence during the  transition, I can always hit stop before selecting the new track. I know steff does not like that idea, but it works for me.  It gives me the flexibility I want and is not much effort.

With Loading Full File (Not decoded) with 23.0.96,  when I select a new track the loading is usually quite fast and the UI seems to stay responsive through that transition.  The playback does not stop immediately, but it certainly stops before the second file is fully loaded. The fact that music plays part of the time while the second track is loading is not an issue.


My primary use of memory playback is to avoid occasional glitches when loading large files from external disks (not NAS) on a slow computer. The current implementation does a wonderful job of avoiding startup glitches that can occur without memory playback. With my slow playback machine (JMark of something like 450) full album loads can be somewhat slow, but that is my fault for having such a slow machine with a usb 2 external drive. I am somewhat proud of being able to play 5+GB DSD files on what may be the slowest computer in the JRiver family.  But I did upgrade it to a full 2 MB of memory!


Bottom line - I am very content with the current implementation (with .96) of memory playback. Yes, it could be improved by having the UI responsive during loading of full albums, but that is a very minor issue for me. It does not start the music any faster.

[RoderickGI]

As I explained, YES.

My apologies. I didn't think through all the implications of these statements:

Having lower network burst ... the spike in the latency is much lower and so... less frequent audio dropouts.
At the of the story, forcing 802.11g will lower much more the network burst and there is no more latency spikes and no more audio dropouts at all!!!

Obviously if you have dropouts except when using 802.11g, then you have stuttering when using the faster network. Strange, given that the first file is still in memory and being played back. I would expect to see a CPU spike when you get a dropout, since playing the first file doesn't need network activity. But if the one thread is handling both the file retrieval and playback, I guess just switching tasks would cause a glitch.

That is all good information for JRiver to consider.


While the cause does appear to be the threading design of MC, I was wondering if some network change might alleviate the problem of stuttering. I tested on an ethernet connection and saw no stuttering. I would have to do some extra setup work to test over wireless, and I only have up to 802.11n to test anyway.

So are there any network engineers around here who could suggest Network Adapter settings changes that might prevent the file load over a wireless network from interfering with playback? A priority change perhaps? I was thinking Quality of Service type settings, maybe? Particularly if they would be implemented specifically to MC, so the general network speed could remain high (802.11ac), but the actual throughput could be throttled enough to allow the MC thread to play without stuttering. Maybe smaller bits of data over the network would do that? Turn off/on Jumbo Frames? Turn off large send Offload? Guessing here.

[JimH]

Have you thoroughly explored the possibility that antivirus software is stepping in and causing problems?  Here are some examples:  https://yabb.jriver.com/interact/index.php?topic=86096.msg588759#msg588759

On Win10, there have been more than a few problems reported recently even with Windows Defender

[JimH]

While the cause does appear to be the threading design of MC ...

It's possible, but I don't think you could conclude that yet.

[RoderickGI]

Well, I didn't say it was, Jim. Just that it appeared that way. 

Mainly because I could easily get MC to become unresponsive, although I did need to limit my network to 10Mbps to do that. But I never heard any stuttering or audio issues even when MC was unresponsive, and nor did other users who have commented, so obviously something else is going on in Steff's environment.

You are also correct that we haven't investigated the antivirus solution Steff is using, or whether exclusions for MC have been implemented. It is quite possible that an antivirus solution is causing the stuttering as it scans the large inbound audio files, even though they are going to memory rather than disk.

[flac.rules]

I am not running AV, and the ui issue is not just a memory playback thing. It seems to be a more general problem, possibly related to tasks that takes a while and access the network (all the examples in the thread seems to be of that nature).

[steff]

I DO CONFIRM, as already explained:
it is not a AV matter. Out of the box, HP laptops are equipped with Win10 and McAfee.
I first disabled McAfee, then uninstalled completely McAfee, so Win10 switched activating Defender... no changes in the behaviour
Now Defender is DISABLED, but still installed (no easy way to remove from the system) and moreover the JRiver program folder, the JRiver library folder and the netowkr folder where music is stored all of them are excluded from scan.

I remark the previous consuderation:
If I keep open the windows taskmanager and the DPC Latency Checker, I can easily demonstrate that:
1) CPU is always low \ very low; I disabled almost everything from Windows and during playback the CPU is below 10%
2) I see HUGE network spikes... the process is not smooth... but the file is being read piece by piece with spike up to 100% of the network capacity
3) During the network spikes, I can notice a spike also in the DCP Latency and audio dropouts

So I can demostrate that it is because of the network activity that I get audio dropouts.
Audio dropouts are mitigated lowering from 802.11ac to 802.11n and no audio droputs at all using 802.11g
It is not because of the ac\n\g protcols, but because of the huge amount of data being transferred in the time unit.
A huge but very short spike produces a spike in the DCP latency and audio dropout
Using 802.11g produces longer network spikes but less intense and no DCP latency spikes at all and therefore... no audio dropouts.

[steff]

Dear JRiver team
here you can find an old post regarding an annoying problem on the MC interface.

https://yabb.jriver.com/interact/index.php/topic,114167.msg789771.html#msg789771

Even if I initially bought the licence for MC23, then upgrded to MC24 and finally to MC25, I never used MC because of such problem.

Is this problem finally solved?

[Awesome Donkey]

I might be wrong, but I don't think they ever could reliably reproduce those type of issues (at least the very long "lock ups"). And that's the big gotcha about software development; if the developers can't reliably reproduce an issue (or reproduce it at all) they can't really fix it, assuming of course, it's actually a bug with the software and not a bug with something else (e.g. the OS itself). Could even be caused by other software like antivirus apps, which is why the antivirus question is asked a lot here. In the case you mention, that suggests to me something like slow network response (or a NAS or whatnot spinning up discs) type of deal. Doing anything over the network with spinning discs that need to wake up is always going to have issues appearing to "lock up" the app when they're spinning up. It's not really a bug per-say, it's more of a condition where MC is trying to read the files on a sleeping NAS/drive(s) and is waiting for the NAS/drive(s) to wake up before resuming operation. Pretty sure that part of the waking drives is handled by the OS itself, and not MC. Doing this over the network, depending on your network and how fast it is, can also cause the operation to be pretty slow.

That said, I believe they made some tweaks at some point during the development in MC25 to somewhat help with the "locking up" of the UI. You might give the latest MC25 build a try and see if it's improved any. Matt also made performance improvements when dealing with a large library with a huge amount of files as well. Other than that, how I'd probably deal with that issue is get NAS hard drives that's meant for 24/7 use, disable sleep on the NAS and let it run that way all the time. And I'd probably do this with a network setup that uses hardware that supports at least 1 gigabit (hardwired ethernet for the most important things, of course).