Print

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

[steff]

I noticed the problem with MC23 and with MC24 the problem is still there and more frequent.

My music (and movies) is stored on a high performance NAS; NAS' disks are set to spin down after 30 minutes of inactivity.
MC24 is used only to play music, not movies.

I have several devices that read from the NAS (Android TV box, WD media player, Raspberry pCorePlayer, etc.) and Windows programs (Foobar, Media Player, VLC, etc.)
If NAS disks are down, whenever I try to connect with my devices and programs, I see different messages (depends on the device) saying "loading..." or "connecting..." and gears spinning or hourglass turning upside down and so on... all the above for 5 to 10 seconds
With MC the behaviour is totally different:
the MC GUI expands \ takes over the entire screen, overlapping even Windows task bar
MC GUI becomes blurry \ out of focus
after some seconds a window pops up asking to close the program or to wait
if I choose to wait... then after other 10 to 20 seconds in addition, MC starts to work again and plays music and so on.

This behaviour is very strange and not acceptable according to me

The same bahviour happens if I choose to play from memory for the time needed to load the file (maybe it is a huge DSD file...)

If I am in Theatre View, in addition to the above, the screen becomes greyed-out

If I try to play RadioParadise from Theatre View, it is the very same.

Let me say that if MC ha something to do and needs its time... it is OK, but this "hanging" IS NOT!

Any explanation?

Do not ask me to uninstall antivirus or to change the PC, etc... all this things have been done.

[JimH]

I know you think the hang is MC, and it's possible, but not likely.

Test local files to rule out the NAS as a factor.

[RoderickGI]

It's not a hang, but Windows thinks that it probably is. Which is why it pops up the "Do you want to close MC" message sometimes.

The behaviour is very common, although usually for only short periods. It is MC waiting for something to happen. Often for an external resource to respond, such as a NAS, or a Streaming Service (Radio Paradise). Just try to start RP and then click on another tab in MC. The screen will defocus and you will get the busy mouse icon. For other instances you will get the message. If the message is ignored and not responded to, I'm pretty sure that MC and Windows recover correctly.

Either MC isn't telling Windows it is still alive and just busy or waiting for something, or because the UI is involved in the process that is waiting, instead of remaining responsive, MC appears to Windows to have hung.

It is quite annoying, not because it happens, but because I never know if MC will recover, or if it has truly hung and I should just close it. I usually wait quite a while before I close it, and that is the real issue for me.

It would be nice if MC handled these situations better.

[steff]

I know you think the hang is MC, and it's possible, but not likely.

Test local files to rule out the NAS as a factor.

I can confirm that playing LOCAL files does not generate the issue: I supposed it was clear in my post.
The issue happens whenever MC waits something to happen or something to be completed: a file to be loaded into memory, the NAS to spin up the disks, a streaming service to respond, and so on.
The problem is that eany other Windows programs (Foobar, MS Media Player, VLC) or any other devices (pCorePlayer, WD TV, Android TV, etc) accessing the very same resources need to face the same latency or delay or whatever, but they can handle the problem in a smooth way.

I do not pretend MC to respond in real time if something dalays... but I pretend MC can handle avoiding the GUI to become blurry or to take over the entire screen, etc.

I am sure that JRiver team can understand what I am saying.

[steff]

I performed a test using Foobar playing music on the same NAS.
I can CONFIRM that the Foobar's GUI continues to be active and continues to respond during the time the NAS takes to spin up drives.
Moreover, if I set Foobar to load the full file into memory, Foobar's GUI continue to respond during the time it takes to load the file into memory.

In addition, setting again Foobar to load the file into memory before playback, when a file finish to play, before starting to play the next one, Foobar finish to load the file, while MC23\MC24 starts immediately to play while it loads the next file.
This is a nonsense: if MC is set to play the file from memory, then no playback should take place until the FULL FILE is loaded.

So, TWO issues need to be fixed.
1) the GUI behaviour (this is a bug)
2) the playback from memory (this is a setting to be fixed and not really a bug), maybe add a switch in the playback option to let the end user choose.

[JimH]

Possibly related:

https://yabb.jriver.com/interact/index.php/topic,117016.msg809308.html#msg809308

[swiv3d]

I play all of my files quite successfully from my simple little netgear NAS using MC 23 and MC 24, so it unlikely that this is an MC problem - more likely to be a network problem, in my humble view.

[Screwdriver]

Create a new admin account in Windows and install MC and see if you still have this issue. If you don't have the issue anymore, back up your user folders and recreate your account.

[Jamil]

I experience this same exact issue, and I posted about it previously.  This is a code design issue.  Based on feedback I received from my posted report of this issue, there appears to be no desire to fix it.  I think the best thing to do is ensure that JRiver's lead architect reviews this to add as technical debt to be fixed.  Perhaps Jim can make sure this gets done.

Yes -- it needs to be fixed.  It's just a matter of doing it.

With MC the behaviour is totally different:
the MC GUI expands \ takes over the entire screen, overlapping even Windows task bar
MC GUI becomes blurry \ out of focus
after some seconds a window pops up asking to close the program or to wait
if I choose to wait... then after other 10 to 20 seconds in addition, MC starts to work again and plays music and so on.

This behaviour is very strange and not acceptable according to me

[jachin99]

I had the same issue, and installing KB4345459 on both a Windows 7 & Windows 10 machine seemed to help the issue (Thanks tzr).  I don't want to use the word Fixed because I just made this change, and I will need to give the machines a while to make sure they have stopped hanging.  I hope that helps. 

[steff]

Because of this problem, I stopped months ago to use JRiver and I focused my attentions to other products.
I just received on my email the invite to pre-order MC25

My questions:
1) is the old problem already solved in MC24?
2) or will it be solved in MC25

[swiv3d]

I have been using mc23 and mc24 playing from ny NAS with no problems, it isn't even what I would call a high performance NAS.

[steff]

you did not read the full post.
MC was used to hang whenever it waits for something to happen.
Example: when the NAS speed up disks from sleeping.

[Spike1000]

With MC the behaviour is totally different:
the MC GUI expands \ takes over the entire screen, overlapping even Windows task bar
MC GUI becomes blurry \ out of focus
after some seconds a window pops up asking to close the program or to wait
if I choose to wait... then after other 10 to 20 seconds in addition, MC starts to work again and plays music and so on.

This behaviour is very strange and not acceptable according to me

This is a long standing issue. I don't see it as often as I used to, but do see it occasionally. It seems to be related to MC having a process 'blocked' or 'stuck' or just 'waiting' for something (like the disks spinning up in your case). Try searching for blurred, soft or maybe taskbar for previous sightings.

I don't think I've ever see a official fix for it in any release notes; but as I said I don't see it as often as I used to. I suspect the issue is deep within the 'core' code of MC so it's not high of the priority list of things to fix 

Spike

[steff]

I have at home a high performance NAS, based on an HP Proliant server running Ubuntu.
Several devices are connected to the NAS to play music, movied, display picture, etc.
Among them: NVidia Shield TV, WD TV Live, a bounch of Raspeberries running piCorePlayer, etc., some of them wired other are wireless.
All of them connected to a Cisco managed switch and the NAS can sustain a constant 200 MByte/s of transfer rate.
With any of them, no problem at all, even playing 4k video.

More than one year ago, I setup a Windows 10 PC, HP with touch screen display, to be used with MC23 in theatre view mode, then I upgraded to MC24.

I raised several times the issue I am experiencing but no feedback at all from the developing team other than: check network card, disable antivirus, etc...etc...
More over I am able to reproduce the problem with any other PC, even wired.
IT is not a problem of my infrastructure, it is MC bug.
The problem is still there and so, six month ago, I stopped to use MC24

I received in my email a message from JRiver team, announcing the new incoming MC25 and offering to me a discount on preorders.

Let me say that I am very disappointed: to pay for an upgrade when I have still problem on the old release, to pay without knowing what are the improvements over the previous.
More over... why piCorePlayer or Kodi or Foobar do not suffer problems at all while are completely free?

What am I paying for with JRiver MC ?
At least I pretend to be supported!!!

[Awesome Donkey]

Being supported and being able to reproduce an issue to fix the issue are two different things. Simply put, issues can't be fixed if the developers can't reproduce them.

However, in your case, it looks like there's two 'issues'...

1) MC appears to lock up when waiting for sleeping hard drives being accessed/sped back up then MC becomes responsive again once the drives are awake. IMO, this is normal, I've seen other apps do the same thing while waiting for the sleeping drive(s) to be ready. I think this issue can be ignored for now.

2) The "white out" of the entire screen/MC window, including the taskbar. Ahh, this is probably the thing that bothers you the most while MC is waiting. However, I think this is probably 'normal' too because MC handles its own window drawing (which my guess is why it appears full screen), which is different than other Windows applications (but it's not the only application that does its own window drawing, Adobe apps and Steam are two other examples). In addition, it could be related to Windows as well (or even caused by Windows itself), as Windows will pop a box if you start clicking in the locked up MC window saying MC isn't responding with Wait and Close options even though MC is waiting and will become responsive again when the drive is accessible again. I'm not sure if this could be 'fixed' (or worked around) where the UI is accessible while MC is waiting, at least not easily. But I do recalling that at one point the JRiver devs tried to minimize the issue in Windows with a wait message box. Haven't tested that in a long time.

So, I believe the first 'issue' I'd consider normal when handling drives spinning up from sleeping. The second 'issue' might be a mix of how MC handles window drawing and possibly Windows itself since it displays the little box about MC not responding when it's just waiting. As far as I can tell, the only way to prevent the first and second 'issues' would likely disable sleeping on the NAS.

P.S. I'm pretty sure I've seen the full screen white out issue several times before with two other apps which does it own window drawing; Adobe Photoshop and Steam.

[Awesome Donkey]

This was brought up here: https://yabb.jriver.com/interact/index.php/topic,119028.0.html

This is my opinion/insight to this issue: https://yabb.jriver.com/interact/index.php/topic,119028.msg822981.html#msg822981

[steff]

The very first important point is that JRiver team confirm that this issue does exist or could exist.

To be clear, the issue happens every time MC needs to perform a task and needs to wait something to happen. Examples below:
1) if NAS disks are down and I ask to MC to play a file. It takes some time to have the disk speed up
2) if I tell to MC to play from memory, then MC before to play needs to load all the file into memory
3) if I tell to MC to play a stream (Radio Paradise???) then MC needs to wait to have data

Of course I really do not pretend MC plays immediately if data, for whatever reason, are still not available.
This is not the problem at all.... I am a technician and I can understand that.

On the other hand it is not acceptable that MC hangs during this waiting.
Not acceptable to see:
- the MC GUI expands \ takes over the entire screen, overlapping even Windows task bar
- MC GUI becomes blurry \ out of focus
- after some seconds a Microsoft Window pops up asking to close the program or to wait
if I choose to wait... then after other 10 to 20 seconds in addition, MC starts to work again and plays music and so on

All of the above heppens every time MC needs to wait for something to happen.

The problem is not to wait, but the way to wait!!!

Why Kodi or piCorePlayer or Foobar or even Windows Media Player or VLC can handle the waiting without that mess?
You can not pretend to me that this behaviour is "normal".... it is normal to wait, it not to have mess.

That's all.

[mattkhan]

that is just MC performing a slow operation on the main gui thread isn't it?

if so, the behaviour is normal *if* the app performs slow operations on the main thread (so the answer to your Q is that those other apps must not perform such operations in the main thread)

[steff]

Sorry, but I did not understood very well the question.

Imagine you need to download a document from the Internet and it takes 10 minutes because your DSL speed is quite low.
Do you consider acceptable to have the computer hanging with Microsoft WIndows pop-up asking to kill the program?

I am sure you are not.
That's the point.

[Awesome Donkey]

To be clear, the issue happens every time MC needs to perform a task and needs to wait something to happen. Examples below:
1) if NAS disks are down and I ask to MC to play a file. It takes some time to have the disk speed up
2) if I tell to MC to play from memory, then MC before to play needs to load all the file into memory
3) if I tell to MC to play a stream (Radio Paradise???) then MC needs to wait to have data

Those are all tasks where MC has to wait (to some degree), so that looks correct.

On the other hand it is not acceptable that MC hangs during this waiting.
Not acceptable to see:
- the MC GUI expands \ takes over the entire screen, overlapping even Windows task bar
- MC GUI becomes blurry \ out of focus
- after some seconds a Microsoft Window pops up asking to close the program or to wait
if I choose to wait... then after other 10 to 20 seconds in addition, MC starts to work again and plays music and so on

Except it's not actually hanging or not responding, it's waiting. Windows is actually wrong when it says MC is not responding.

All of the above heppens every time MC needs to wait for something to happen.

Which is probably normal while MC is waiting.

The problem is not to wait, but the way to wait!!!

I kinda disagree. I can see how it appearing to be locked up would be annoying, but I've seen other applications (including Steam) do the exact same thing with local drives and SSDs.

Why Kodi or piCorePlayer or Foobar or even Windows Media Player or VLC can handle the waiting without that mess?
You can not pretend to me that this behaviour is "normal".... it is normal to wait, it not to have mess.

Well, look, I'm not a software developer. However, I do know the basics of software development as I've known quite a few software developers over the years and I've learned several things after talking to and observing them... 1) no two applications are the same - they can and do things differently than other applications and 2) in regards to bugs and issues, things usually are not what they seem to be.

Matt or Hendrik would likely know the specifics or can correct me if I'm wrong, but I believe the way MC waits is intentional and I'm not sure if it can be changed... or should be changed. Thinking about it some more, I'm not sure if I would want MC's UI responsive while it's waiting because I'm sure trying to do things while MC is waiting could cause other issues, like MC crashing.

that is just MC performing a slow operation on the main gui thread isn't it?

if so, the behaviour is normal *if* the app performs slow operations on the main thread (so the answer to your Q is that those other apps must not perform such operations in the main thread)

That's what I was kinda thinking too. But I'm also thinking it's intentional to prevent possible issues (like the user trying to do other operations while MC is waiting).

[Awesome Donkey]

Do you consider acceptable to have the computer hanging with Microsoft WIndows pop-up asking to kill the program?

Well, that's Windows doing that, not MC.

[Hendrik]

I have a NAS with HDDs that shut-off too, and I've never seen MC hang like that here. 99.9% of everything I play is video though, and the media type absolutely does matter since different playback engines handle different types of media.
If a drive needs to spin up, I get a proper waiting screen, with animation and everything.

[mattkhan]

That's what I was kinda thinking too. But I'm also thinking it's intentional to prevent possible issues (like the user trying to do other operations while MC is waiting).

it's not a great way to achieve that goal (if that is the goal) because it is not nice from a UX point of view. It basically means you move the operation to another thread and provide some other way to give visual feedback to the user that an operation is pending (and also prevent the user from attempting to fire off a million tasks while they wait by clicking around).

It sounds like you need to use MC in a certain setup to really have this problem annoy you though (e.g. I also have everything on a NAS but don't spin down disks and I don't use memory playback hence perhaps why I v rarely see this issue).

[steff]

Well, that's Windows doing that, not MC.

Please, do not consider me an idiot. I know perfectly that it is Windows and not MC
But Windows shows the pop-up for some reasons, right?

Why Foobar does not hang while it fully load the file into memory?
Why while Foobar loads data does not hang? It's windows does not override on the entire screen becoming blurry?
Why no pop-up cames from Windows saying that Foobar is not responding?

The PC is the same, the infra is the same, etc....

[RoderickGI]

Except it's not actually hanging or not responding, it's waiting. Windows is actually wrong when it says MC is not responding.

But that doesn't matter Awesome Donkey. I would bet that 80%+ of users who see that whiteout screen and the "Do you want to wait or close the application" click the Close Application button at least 80% of the time. I know I used to, and I still do sometimes, even though I know what is going on. For example, if my MC Server goes to sleep underneath my active MC Client, I get the busy icon when I try to do something that needs the Server running. If I click elsewhere in the MC interface I get the whiteout and message. In the past, and possibly still now because I have only just allowed my Server to sleep again recently, it was quicker to kill the MC Client and restart it, which reconnected it to the Server faster than just waiting. Bob is aware and has done some work on that, but it is still an issue.

It is just a very bad user experience. Most users, as evidenced by quite a few threads, think that MC has crashed or hung, and it doesn't help to get into definitions of the two with users, even though it helps identify the problem.

All that is needed is a message that says "MC is busy. Please wait a moment.", maybe with some indication of what it is waiting for, and most of the complaints would go away. Behaviours to fix a perceived problem would also change.

While Steam particularly can become unresponsive, I have "never" seen it, or any other applications including Adobe software, white out the screen or have had the option to close the application, just because it is waiting on a perfectly normal Windows process. I have seen similar messages like "The program is not responding" when a program has actually hung irretrievably, that being a Windows message.



Perception.Is.Reality.

The fact that it seems acceptable to expect users to just know that MC is waiting and will recover is one of the reasons that I think MC is still considered a geeks application. Normal users expect to understand what is going on, without understanding applications or Windows internal processes. A suitable message would make that happen.

The problem is not to wait, but the way to wait!!!

As you may have guessed, I agree with this. 

If a drive needs to spin up, I get a proper waiting screen, with animation and everything.

Any chance you could share a little video, or even an image of what this looks like Hendrik? It would make Steff and I feel better. 

[Awesome Donkey]

Hmmm, yeah, you're right RoderickGI. Having a descriptive wait message would help greatly with this. The only thing I'm not sure about is preventing Windows from assuming MC is not responding and displaying the message box.

[steff]

I'm not sure about is preventing Windows from assuming MC is not responding and displaying the message box.

This is up to the people who know how to deal with Windows internals and know how to write code.

Let me add another case I experienced in the past and I just verified right now.

I just identified another case:
Load Full file into memory enabled, files 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, MC 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 MC stops to play the old one and switch to the new one.

So... when MC is in the middle, while still playing the old one but loading the new one, then MC GUI expands to the maximum, overlapping the Windows taskbar and becoming blurry.
Everything is restored when MC stops 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 MC starts playing the new file.

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 MC stops playing the old file immediately, loads the new file and start playing it just when fully loaded, without seeming to hangs\crash

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

[Spike1000]

Ahh, this is probably the thing that bothers you the most while MC is waiting. However, I think this is probably 'normal' too because MC handles its own window drawing (which my guess is why it appears full screen), which is different than other Windows applications

Is this a consequence of a single 'cross platform' library used to handle the window drawing for Mac, Linux and Windows editions? If it is I'd be raising an issue with the suppliers to see if there is an improved version available .

Spike

[steff]

Would someone test the behaviour of Foobar, maybe after set playback from memory?

This is what I expect from MC.

[mattkhan]

If it is I'd be raising an issue with the suppliers to see if there is an improved version available .

As far I know, it is there own library

[JimH]

steff,
Please continue the same thread instead of opening new ones.  I've merged two threads.

Did you notice this post about a Microsoft patch:
https://yabb.jriver.com/interact/index.php/topic,115542.msg809523.html#msg809523

A bug in the OS or a bug in the NAS firmware might only show up when you use a single application that triggers the set of circumstances that lead to the bug.  So don't point fingers based on "everything else works".

[steff]

do you mean KB4345459 ?
OK, I will check later in the evening. Anyway, the PC is updated with all the patches available in the Windows Update.
It means I never manually installed a single KB.

By the way... I said that all my music is stored on that NAS (it is not a NAS appliance, but a HPE Proliant running Ubuntu and serving SMB shares...) but, in order to reproduce the issue, I already pointed MC to a share on a Windows 10 computer: same behaviour.
I installed MC on 3 different computers running Windows 10 and one with Windows 7... still same behaviour.

[JimH]

do you mean KB4345459 ?
OK, I will check later in the evening. Anyway, the PC is updated with all the patches available in the Windows Update.
It means I never manually installed a single KB.

Yes.  Being up to date doesn't mean "no problems" with Windows.  Microsoft has made a lot of mistakes recently.

By the way... I said that all my music is stored on that NAS (it is not a NAS appliance, but a HPE Proliant running Ubuntu and serving SMB shares...) but, in order to reproduce the issue, I already pointed MC to a share on a Windows 10 computer: same behaviour.
I installed MC on 3 different computers running Windows 10 and one with Windows 7... still same behaviour.

Try local files.

[steff]

No problems with local files, since NAS disks do not need to be speed up, since the transfer from disks to memory for memory playback is 100 times faster, and so on.
Still problem with streaming, since by design data come from the Internet.

[rec head]

I've seen this happen a lot and agree that a simple "Please wait" would suffice. When I get the Windows dialogue I usually just quit and restart MC because I know how long that will take compared to the vague "it looks like it crashed" waiting period.

[Hendrik]

Somehow I thought we already had a wait dialog for spinning up drives. But maybe that doesn't trigger for normal playback? I definitely saw it before.

If not, we could probably test adding such a dialog on Windows at least. Moving more actions to worker threads requires more long-term work since it has to be careful when communicating with the UI.

[millst]

This absolutely is an issue with the internal design of the software. This is not a Windows problem. As mattkhan noted earlier, the main/UI thread of MC is waiting for some long running task to complete. Since that thread is unresponsive, Windows thinks the app might be locked up. Sure, other apps demonstrate this behavior, but that doesn't make it right.

The right way to do things is to run any task that might not finish immediately on a background thread. That keeps the UI responsive. MC already does this for lots of things. Example, the UI doesn't lock up when running import. It happens in the background and the UI simply reports status in the action pane.

Unfortunately, that change isn't always as simple as it sounds, which is probably why it's been like this for so long. When a task happens in the background, the user might start clicking on all kinds of things that don't play well with that...resulting in bugs/crashes. Showing a static busy dialog that still allows MC to respond to OS requests, redraw/refresh the window, etc. might be an easier fix.

[AndrewFG]

Just out of interest, what are the files that MC is trying to load when you encounter this issue? Are they media files? If so what format, and how big are they? Do you have A/V software running on the PC? And/or on the NAS server? I would suggest you try setting the A/V software to (temporarily) ignore the respective file types or files, and see if that ameliorates the issue..

[JimH]

This absolutely is an issue with the internal design of the software. This is not a Windows problem. As mattkhan noted earlier, the main/UI thread of MC is waiting for some long running task to complete. Since that thread is unresponsive, Windows thinks the app might be locked up. Sure, other apps demonstrate this behavior, but that doesn't make it right.

Windows sometimes says that when everything is perfectly normal but the machine is pegged.

If a file access is blocked (by anything) the OS may become unresponsive.  Try opening a machine that doesn't exist in explorer, for example.  (enter \\nomachine)

The right way to do things is to run any task that might not finish immediately on a background thread. That keeps the UI responsive. MC already does this for lots of things. Example, the UI doesn't lock up when running import. It happens in the background and the UI simply reports status in the action pane.

MC already does this for anything it can.

[DJLegba]

Somehow I thought we already had a wait dialog for spinning up drives. But maybe that doesn't trigger for normal playback? I definitely saw it before.

If not, we could probably test adding such a dialog on Windows at least. Moving more actions to worker threads requires more long-term work since it has to be careful when communicating with the UI.

I see the wait dialog (if you mean the one that says something like "Spinning up drive") on the MC server when the external USB drive has shut down. It doesn't last long.

[steff]

Yes.  Being up to date doesn't mean "no problems" with Windows.  Microsoft has made a lot of mistakes recently.Try local files.

I verified my 3 installation of Win10.
KB4345459  is not present and moreover is not installable.
Seems that KB4345459 is for Windows 7 and 2008 r2

[steff]

to add some more considerations,
the issue appears in several situation: it is NOT only a problem to speed up NAS' disks.
Once the disks are running, it appears also whenever the memory playback is active, while MC is playing and you switch to another file:
while MC load the new file into memory, MC continues to play the old one untile the new is completely loades and the GUI stops responding, becomes blurry, etc.... etc.

For the onew asking what tipe of files and their size...
I use (well, I got the license of 23, upgraded to 24 then stopped to use) MC just for MUSIC, no picture, no video, nothing else.
My music collections consists of FLAC files, 16bit \ 44 kHz ripped from my own music CD, then other FLAC file up to 24 bit \ 384 kHz and also DSD up to 1 GByte each.
The problem happens regardless the file type, resolution, sampling rate, coding, etc.
The larger the file, the longer the time to wait the GUI restart to respond.

If someone is interested, since my work let me have access to ICT resource, I just finisched to test anther scenario:
brand NEW HP with Intel i5
Windows 10
wired network @ 1 Gbps to a Cisco 3850
EMC Unity full flash serving file \ NAS

same behaviour I have at home

regarding antivirus:
the common best practice are in place: everything belonging to MC is excluded from the scan
No AV running on the NAS

[JimH]

regarding antivirus:
the common best practice are in place: everything belonging to MC is excluded from the scan
No AV running on the NAS

Try uninstalling the antivirus software.

[RoderickGI]

Try opening a machine that doesn't exist in explorer, for example.  (enter \\nomachine)MC already does this for anything it can.

I tried that to understand your point Jim. Windows Explorer accepted the input, the UI remained responsive and I was able to click on other drives, and after a few seconds a message window popped up on the screen saying "Windows cannot access \\nomachine".

This was perfect. If MC did the same, there would be no discussion.


If I click on the "Network" item in Windows Explorer when one of my PCs is asleep, I get no response for some time. The UI remains responsive and I can select another local drive and Windows Explorer will display the contents.
If I click on the "Downloads" directory either under "Quick Access" or "This PC", Windows Explorer takes a while to display the contents, as it always seems to have to reindex the contents. It displays a message in the output pane of "Working on it...". The UI remains responsive and I can select another drive or directory and Windows Explorer will display the contents.

This isn't a beat up JRiver issue, at least as far as I am concerned. We are reporting what we feel is a genuine issue. An issue that is inconsistent with the user experience with other applications.

[Hendrik]

It might help to have a list of situations it happens in the most, since many may have different sources. If I'm looking at playback primarily:

- I know it can happen when starting audio playback, either from a sleeping drive, slow network, or memory playback loading big files. Thats probably all the same source, since opening the file just takes too long for the UI, and something we can try to address. The cause is pretty simple, the solution .. we'll see. Worst case it'll just get a wait message.
- I know that video playback through DirectShow (ie. on Windows) is not affected, since that uses more threading today already, and I use that with a drive-sleeping NAS daily.
- I've read something about Radio Paradise. I think we did some improvements to RP startup time in the past during MC24, so thats hopefully not a big issue anylonger?

[mattkhan]

Sounds like memory playback of dsd located on a network drive is the thing to use to test this.

[RoderickGI]

It's great to try to identify and resolve the causes. I was just trying to reproduce the issue of my Server sleeping under an active Client, as I know that has been improved and I wanted to see what the conditions were for seeing the issue now.

My first test showed that just manually sleeping the Server isn't enough. MC just wakes it again straight away. So it may need to hibernate the Server, or wait for the Server's NIC to power down, or wait for my router's ARP table to drop the record for the Server. I'll try to narrow the cause down some more.

But the real concern, at least for me, isn't the cause of the issue, but is MC's response. I don't know if the response could be improved without identifying all the causes, but if it could, that would be a big improvement.

[Hendrik]

The underlying "cause" isn't really that important (ie. why its slow), as long as one of them can be reproduced, the action you perform in MC is what really matters. If you try to play an audio file, and its slow to open, it doesn't really matter why its slow, it just is. But if the same thing happens when trying to play audio, and trying to play an image (for example), then those are really distinct actions that may require different fixes, since different media types are handled quite differently. And not to speak of entirely different actions than playback. But lets stick to playback for now and see what comes of it.

[steff]

Try uninstalling the antivirus software.

Windows 10 comes with Defender installed and enabled.
It is not possible to UNINSTALL the antivirus, as far I know.
If you install another AV on top, then Win10 disable Defender

I tried to:
1) just disable Defender. It is not a un-install. Defender is still present, but not scanning
2) installed another AV (Symantec) that disabled Defender and configured Symantec not to scan

In both scenario, I did not get any improvements

in any case, with Defender active and scanning or Defender disabled, several paths are excluded from scanning: MC binary folder, the library, the profile, the network shares, etc.
No AV running on the NAS