Print

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

[bblue]

I believe this started in .39, but every two to three minutes of play, the GUI stops responding (no display updates, no input accepted) for between 24 and 30 seconds.  It's acting like being memory starved and doing garbage collection, but the W10 Pro system has 32GB ram with lots of headroom.  I've never seen this before very recently on same system.  None of the hard disks are SMART reporting any significant low level read areas (assuming a temp directory is used at some point in the transfer.

This is a workstation just for playback, the library is on a separate server.  Reads from the server are not related to the GUI stalls, regardless of whether or not the Play from Memory option is selected.  The server filesystem is mounted on the workstation in a dedicated drive position.

There's no change of behavior based on CPU utilization, 2% to 98% is the same as far as the GUI issue is concerned.

Anyone with ideas about this?  It seems to be specific to MC, as other programs don't exhibit the behavior by themselves or in concert with MC.  The music playback is not interrupted, just the GUI stalls.

[JimH]

This sounds like one of the Nvidia problems we've been seeing lately.  Please read this post and those following:

http://yabb.jriver.com/interact/index.php?topic=24031.msg704783#msg704783

[bblue]

Ok, I did.  Even though my problem didn't seem to exactly fit any of the posted problem descriptions in that thread, I checked a few things.

The driver I had installed was 353.82, since September when I installed the GT970 card.  I've never before seen this problem until about a week ago, through Windows 8.1 Pro 64-bit and subsequent conversion to W10 Pro 64 in December.

Checked with NVidia, and there have been quite a few releases since the one I was using, so I downloaded and installed 361.75 which just came out.  Absolutely no change in behavior.  I'm not too inclined to go older that my original since there were no problems with it until very recently (39 or 42 versions).

Can you query what has been changed over that span of time (2 weeks?) to determine what might have been 'improved' that could cause this?  I have reservations that it is really an NVidia problem.

[JimH]

A lot of things have changed, but we're not seeing the problem you've reported.

What changed on your end?

Antivirus programs can cause problems like this.

If you're playing from a server, the network could be a factor.  Try powering it all down and back up.

[bblue]

A lot of things have changed, but we're not seeing the problem you've reported.

What changed on your end?

Nothing at all since W10 was installed in late December.

Antivirus programs can cause problems like this.

Have had both Defender and Windows Firewall disabled, no change.  Also, defender has exclusions for all things MC.

If you're playing from a server, the network could be a factor.  Try powering it all down and back up.

Unnecessary.  I have already determined that the reads from the server before (or during) each song are as they should be, quick and predictable.  There also is no correlation at all between server reads and the GUI stalls on the server.

I have noticed that the stalls seem to appear more frequently when I'm moving around in a large playlist, or setting values in DSP.  Time to return to life is about the same, though.

Maybe not useful, but here is MC System Information (minus the system section.  It won't fit):

Library
    Total files: 60743
    Audio files: 59271
    Image files: 354
    Video files: 1081
    Other files: 37
Processing
    Thumbnails built: 99% (60390 of 60743)
    Audio analyzed: 98% (59426 of 60352)
Background Tools Running
    No tools currently running
Power
    Playback (disable automatic sleep)
Media Center
    Version: 21.0.42 Registered
    Install path: C:\Program Files (x86)\J River\Media Center 21\
    Interface plug-ins: Interface Plugins: TiVo Server (not running), MiniLyrics (running)
    JRMark: never run
    Memory used: 319 MB memory
    Handles used: 708 handles

[flac.rules]

I have had similar sounding problems, but I have yet to find a solution (except it seems to be realted to running a server-client setup)

[glynor]

These kinds of issues are most commonly Anti-Virus related. Almost always.

But there are other potential causes. The Troubleshooting Guide covers basically all of the common reasons this might happen (and was a big part of the original motivation for making the guide):
http://wiki.jriver.com/index.php/Troubleshooting_Guide

Please read through it.

[bblue]

One additional observation.  MC does not need to be playing to have the GUI stall problem.  I've had it in both pause and stop on different occasions, only to hit play and find that it is in a GUI stall, and will not continue on until the stall is over.

If there's no streaming activity, just MC's internal processing when idle or paused, shouldn't that change the likely candidates?

I've gone through Glynor's troubleshooting list, and found nothing that doesn't check out correctly.  I've done various drive consistency checks, with or without load, all is clear.  At this point the only drive besides the server that MC accesses is the C: drive, most notably in the Program Data directory hierarchy.

I've been hesitant to completely uninstall and re-install MC on this client, because there is no local library, and therefore nothing to make a backup of.  I realize that it mostly configures itself from the Server library to which it connects, except for the parameters that are locally set.  How do you go about saving all those so upon reinstall, everything is completely the same??

[glynor]

How do you go about saving all those so upon reinstall, everything is completely the same??

Load, just one time, the default Local Library (it MUST have at least one local Library, it won't let you remove the last one). Make a Library Backup. That'll include all settings, including the current setup in the Library Manager (allowing you to reconnect to your server after restoring the Backup).
http://wiki.jriver.com/index.php/Library_Backup

[bblue]

Thanks, Glynor.  That worked perfectly!

Unfortunately, it didn't change the issue with GUI Stalls at all.  In fact on first run, before either of the libraries had been accessed, it paused as soon as the UI came up.  That one was a little shorter, maybe 15-20 seconds or so, versus the typical 30.

Are there any areas that would benefit by manual cleanup when MC is not installed?

[bblue]

I thought I would bring this issue up again, as I'm still tolerating it.  It appears to be a little worse.

There are periods of time when the GUI (any keyboard input or output to the screen) is suspended.  Now the periods of no-response are as long as 35 seconds, and the stretch of time that it works before another stall is around 1:20.  That's about 1/4 of the running time stalled out, even though IF it's playing audio or showing video, there are no interruptions of the stream.

It is stalling and freeing even when the MC client is just sitting there, not playing, no jobs running and no playlists even loaded!  You can hit play for a new song and it may just sit there for a period of time with the Windows blue circle on the screen until that stall time is up, and then will continue on.  If it happens to stall in between tracks of an album, it makes the silence gap much longer.  The next song won't play until the stall is done!

It's only MC.  Nothing else on the computer stalls along with it (or at all) -- everything continues operating normally.

It only uses about 1% CPU whether running or stalled.  No changes there.

It's only using less than 300K RAM at any given time.

The only protection program I use is W10 Defender, and the stalls continue even if that is not operating.

It's not related to system indexing, as it still stalls with indexing disabled.

The NVidia drivers have been updated half a dozen times with no changes whatsover.  I'm on 368.22 right now.

Not a single other program on the system makes any change during these stall times in MC.  No other players or viewers exhibit it either.  Not even my DAW, which can run simultaneously to MC with no issues at all.

I have removed all versions of MC that I've had installed, installed the latest 21.90, same thing.  No differences.

Now I'm quite sure it'll be said that no one else is experiencing this, and the problem must be in my machine.  OK, where?  Give me some specific things to look for or test and try to find it, rather than generalized suggestions that have worked in some odd case.  Or maybe this is the odd case, I don't know.

What I do know is that it is extremely tedious working with MC with these regular, frequent, stalls going on.  There MUST be something that MC is doing that triggers this behavior.

Please, anyone with useful ideas or suggestions for debugging this?

Thanks for any help.

--Bill

[JimH]

Uninstall your antivirus software.

[bblue]

Uninstall your antivirus software.

Defender can't be disabled or uninstalled in W10, and is completely innocuous to any other software. 

Fix your software.

[bblue]

Defender can't be disabled or uninstalled in W10, and is completely innocuous to any other software. 

Fix your software.

Do you like your kind of response?  I DON'T.  Be helpful or don't answer.

For the sake of argument, however, there is an option in Defender where you can turn off Real Time scanning for a short time.  When I turned it off, there was no difference in MC's behavior.  It comes back on in a while, so even if that was the solution, it wouldn't help.

Plus I have everything having to do with MC excluded from any scanning by Defender.

--Bill

[JimH]

Did you ever update?  You're on 21.0.42 as far as I can tell.

21.0.90 is at the top of this board.

[bblue]

Did you ever update?  You're on 21.0.42 as far as I can tell.

21.0.90 is at the top of this board.

Right, yes I'm on 21.0.90.  I update about every three or so versions.  It was either 86 or 90 when I noticed the delays getting longer by about 5 minutes average.

[rlebrette]

Fix your software.

This kind of statement is not really fair. If you're the only person facing this kind of problem it's very difficult for the development team to fix something that's related to the environment.
I've six instances of JRiver on different configurations, mixing AMD and NVidia GPUs, pro and consumer soundcards with different Antivirus and nothing that looks like your problem.
It's unfortunately up to you to bring enough background information to the team to allow them investigating your specific problem.

[blgentry]

You say that you have files excluded from Windows Defender.  You might want to quickly read through this guide on how to set up Defender for use with MC:

http://wiki.jriver.com/index.php/Taming_Windows_Defender

It seems to have helped on some people's systems.

Good luck.

Brian.

[bblue]

You say that you have files excluded from Windows Defender.  You might want to quickly read through this guide on how to set up Defender for use with MC:

http://wiki.jriver.com/index.php/Taming_Windows_Defender

It seems to have helped on some people's systems.

Good luck.

Brian.

Thanks Brian.  Yes, I have seen that article when I first started hunting for this issue.  All the directories listed (and then some) are excluded, and all the filenames listed also are, but not in the same entry format.  Glynor gave the full pathname to each .exe, I didn't.  AFAIK, the basename (name of the .exe) is all that is needed in an exclusion.  If that is not true I'll have to redo it.  I have used just the basename in other exclusions and it seemed to be working.

Last night I turned off Real Time Scanning on Defender, which should in essence be the same as excluding everything.  It made no difference at all.

All drivers and chipset support files (.inf) are current and maintained, also.  I have tried disabling a variety of services and drivers but no changes.  No media or library files (except library backups) are on this machine, and all the services that pick up titling, cover art, etc., are on the server, not this machine.

--Bill

[JimH]

Disabling antivirus often does not work.  You could read the thread called "Antivirus Problems" here. 

[stevemac]

My $0.02 worth

Any chance it's looking for network drives that aren't accessible or waiting for drives to spin up?

regards,

Steve

[bblue]

Disabling antivirus often does not work.  You could read the thread called "Antivirus Problems" here. 

Jim,

I'm not finding results from this search.  Just references to the posts that you and I have made.  Same with 'Antivirus' by itself.

[JimH]

Use the advanced search.

[bblue]

My $0.02 worth

Any chance it's looking for network drives that aren't accessible or waiting for drives to spin up?

regards,

Steve

No, afraid not, Steve.  All the drives in the server (20) and this workstation (6) are set on 24x7 (and are NAS rated drives).  The workstation has two drives from the server mounted on it, but they are always up.  Both machines have SSD boot drives.  One 4Tb USB 3 drive on the workstation, which when plugged in is up all the time.

I have tested 'what happens if' the two images from the server to workstation weren't there, and it does not make any difference to MC on the workstation and its GUI stalls (except I can't play music because one of them is the mount point of the large media folder from the server.)  But the stalls happen whether it's playing music or not (except you don't hear any gaps in music when playing).

--Bill

[bblue]

Use the advanced search.

Ahh, thanks.  I went all through those, even to reading the details of the issue and cure.  For the most part they dealt with more destructive AV programs than Defender, and often included symptoms of very high CPU utilization, which I don't have.  MC sits at about 1% CPU regardless of what is going on in the system or MC itself.  Even during stalls, nothing that I can see from the outside seems to change.

I'll pull out procmon (process monitor) and a couple of other debug type software I have that show what is happening with I/O, external commands and the like with a given process and see if it shows anything.  Is there any point in watching or examining MC's logfile for information around stall-on and stall-off times? 

[JimH]

Yes, you could try reading the log file.

If the problem were mine, I would set up a test library on a local drive, keeping everything simple, then expanding the complexity.

Unplug as many devices as you can.

USB 3.0 drives don't like to be connected to USB 2.0 ports.

Reboot your entire network and all the devices, all the way back to the outside connection.

[bblue]

Well, that's tech 101 to be sure.  Having worked with computers, programming and maintenance, including banks of computers in an ISP, for over 35 years, I can say for sure that the last two items are irrelevant to this situation.  This is far more local (computer).

I misspoke the other day on which version of MC I was running.  Not 21.0.90, but 21.0.86.  This morning, at first I updated to 21.0.90 my usual way, by installing over the old one.  Got the same behavior as for the last few months.  Getting a hair, I uninstalled 21.0.90 completely including directories, registry entries and all.  Then installed it fresh.  The last time I did that was in December when I changed from Windows 8.1 Pro to Windows 10 Pro.

At this moment and as soon as I started using the clean 21.0.90 install, the stalls are down to 4-5 seconds in length, about every 3 minutes or so.  This is how it always used to be before the long stalls began, way back when.  I don't believe any stalls in the GUI should be happening at all, but this is certainly tolerable and for the most part non-obtrusive.

Before I did this I checked every file in the J River directory hierarchy to make sure they had sensible dates and actually belonged to MC.  They all did.  After 21.0.90 was in I compared the files in each, and they seemed identical (at least by name and placement).  So no clues whatsoever as to what changed (I didn't compare registry entries), just that something did.

The best way to see the stalls is to have the freq response 'meters' in the Title bar info.  They exactly follow the stalls and are easily noticed even on short stalls.

I'll post more if/when it changes rates.

--Bill

[JimH]

Well, that's tech 101 to be sure.  Having worked with computers, programming and maintenance, including banks of computers in an ISP, for over 35 years, I can say for sure that the last two items are irrelevant to this situation.  This is far more local (computer).

Congratulations on your confidence, but try to keep an open mind about where the problem is.

[Headcool]

I think using a profiler may be helpful. You can use Very Sleepy. It is a very basic and simple profiler, but maybe it can do the job. Most important is that the timespan of the stall should be a significant part of the whole profiling timespan since you can't adjust the timespan later. This means you have to start profiling several times and when no stall occurs after a few seconds, you have to restart the profiling task. Also the CPU utilization of MC should be as low as possible, so don't play a movie.

[bblue]

Thanks for the reference, Headcool.  That may prove to be helpful.  Since my recent re-install of MC has the stalls down to 3-4 seconds, it may be a little difficult to start VS at the right time, but we'll give it a try.

--Bill

[bblue]

Congratulations on your confidence, but try to keep an open mind about where the problem is.

Of course, that's the only way.  Thanks.

[Headcool]

Thanks for the reference, Headcool.  That may prove to be helpful.  Since my recent re-install of MC has the stalls down to 3-4 seconds, it may be a little difficult to start VS at the right time, but we'll give it a try.

--Bill

If you can't manage to get the timing correctly, there is still the option to take a better, more versatile profiler where you can mark time events while profiling and select a timespan later. The problem is just to find one that takes binaries without source code, runs on windows, is free, provides the right metrics, is easy to use and does the thing metioned in the sentence before.

[bblue]

If you can't manage to get the timing correctly, there is still the option to take a better, more versatile profiler where you can mark time events while profiling and select a timespan later. The problem is just to find one that takes binaries without source code, runs on windows, is free, provides the right metrics, is easy to use and does the thing metioned in the sentence before.

Not a particularly small task, I'd expect. 

[RoderickGI]

Well, it sounds like the problem is much reduced. But anyway...

You don't mention checking the Windows Event Viewer to see if anything unusual is going on. I just installed Windows 10 (upgrade in place) and I'm definitely seeing a few strange things, some of which have a noticeable impact on performance of the PC.

The one that caught me out recently caused Windows to stop me doing what I was doing, and asked me to close programs, because it was out of memory. It wasn't out of memory of course, but the "Committed" memory had just jumped to its maximum value, and Windows was trying to recover some space in the Page File to continue. If I didn't close programs straight away, Windows 10 crashed. These events were clearly reported in the Event Logs. I'm currently watching the Committed memory levels constantly to see if I can determine the cause. Internet Explorer is involved, so it could be anything.

Googling "committed memory windows 10" shows that quite a few people are having similar problems. This post and this post were good. Worth checking in your case.

The problem hasn't occurred to the same extent since I ran "SFC /scannow" which found some problems in my new Windows 10 installation and fixed them. Maybe it would be worth running that on your system.

[bblue]

RoderickGI: Yes, when I had the really long stalls I spent a bit of time in Event Viewer, but there were just the usual system messages, and a couple I was able to correct.  They had no bearing on MC.

Yes, sfc /scannow is a regular around here.  It's amazing how often it finds and fixes or finds and tries to fix errant libraries and the like.  But it can only do so much.  Things that sfc can't fix, are *usually* fixed by: 'dism /online /cleanup-image /restorehealth'.  (or /scanhealth if you want a list of issues).

I run each of those at least once a week.

Another solution which can fix some things, especially weird ones, is do a Win 10 in-place upgrade by executing setup.exe at the top level of the USB stick or CD/DVD of the same version (Home or Pro) that you're currently running while it's already running.  It'll leave everything installed alone, and fix/replace various elements of W10 that aren't right.  You may have to re-load some updates after doing that, but it'll happen automatically.

Oh yes, I *always* remove IE 11 from any Windows 10.  Solves problems.  Edge doesn't cut it, so that leaves Chrome, or my favorite Palemoon which is an optimized version of Firefox.  Even using IE 11 for just a few minutes it gets attacked with drive-by's, Trojan Horses, and other nasties that get through so easily. 


On the memory issues, I usually go to extremes whenever possible.  16GB minimum and 32GB when I anticipate some load.  Either no paging file, or a fixed size of 16GB, or even 8GB.  Never any memory issues.  But in a W10 in-place upgrade there are often problems carried from the old system that may have never shown up at all or in the same way as they do in W10, and it can be a bear finding their real origin.  So if you're cutting it close with memory needs, just add more -fast- memory, as fast as the motherboard will permit and you usually can be done with it.  YMMV.

Oh, and go through Programs and Files to uninstall anything old, unknown, or temporarily not needed.  I had a bunch of stuff from W7 and w8 that upon removing, even though W10 ok'd them, fixed problems.

--Bill

[RoderickGI]

You mentioned your IT background so I thought you would have such things covered. But worth posting anyway.

I haven't cleaned up old programs carried over yet, but I will get around to that. IE11 seems to be the real problem though, and as you say, edge doesn't cut it. I can't believe MS think it is anything like a replacement for IE, let alone a competitor for other browsers.

I've never found a tool that could just watch a Windows system and report abnormal behaviour that is observable by a human, like your GUI lockups. As you say, Very Sleepy looks like a lot of work.

I see some very minor "delays" in MC sometimes. Probably close to what you are seeing, though not consistent by any means, and not enough to bother tracking down. I'm just wondering now if we should both increase the priority of the MC processes, and see if the problem improves. I might have to research the impact of making the MC process "High" or "Realtime". Because I don't see any obvious resource issues when I see these "pauses".

[JimH]

You should not need to change MC's priority in the OS.  It is not recommended.

[blgentry]

A couple of things...

No media or library files (except library backups) are on this machine, and all the services that pick up titling, cover art, etc., are on the server, not this machine.

MC's library is recommended to be stored locally.  It's the database, so it gets hit "often" and requires "fast access".  My double quotes here are to indicate that I don't know how much of either is required (how fast, how often); just that this is what I've read around here.  ...and it makes sense.  You want your super fast access stuff (like the database that runs the program) to be local.

You should build a test library with locally stored library files and see how it works.  Library files are very, very small; they won't unnecessarily fill up your SSD disk.

Getting a hair, I uninstalled 21.0.90 completely including directories, registry entries and all.  Then installed it fresh.  The last time I did that was in December when I changed from Windows 8.1 Pro to Windows 10 Pro.

From this and later posts, I'm getting that your windows10 system is an upgraded system from 7 and then from 8.1.  I've been doing this for long enough that ANY upgraded windows system is a red flag for me.  Yes, yes, I know you have a ton of experience too. Perhaps more than I do.  That doesn't change the fact that upgraded systems tend to be problematic.  Not every one every time.  But enough of them.  ...and you have a mysterious problem.

I would be inclined to do a fresh install of windows10 and go from there.  Fresh OS installs, on any platform, are always more well behaved (statistically speaking).

Good luck with this.  I know from experience that being told to reinstall your OS when you have an application problem seems like overkill.  Ask me how I know.    In some cases, it's the right advice.  In other cases, not so much.  I don't know what your exact problem (or solution) is.  I'm just giving my best advice.  Again, good luck.

Brian.

[bblue]

...
I see some very minor "delays" in MC sometimes. Probably close to what you are seeing, though not consistent by any means, and not enough to bother tracking down. I'm just wondering now if we should both increase the priority of the MC processes, and see if the problem improves. I might have to research the impact of making the MC process "High" or "Realtime". Because I don't see any obvious resource issues when I see these "pauses".

That's an interesting thought.  I don't think I'd want to make any change like that permanent, but it could be interesting to how MC delays change (or not) in that mode of operation.

I'm not concerned at all about the random delays that you occasionally see when shifting views or similar.  I'm sure those have a reasonable explanation and are just part of normal operation.  But they're quite different than the predictable GUI stalls I see.  That they completely interrupt screen/keyboard I/O isn't acceptable when you're talking about a 20-30 second long stall every minute+ or so.  Mine is down to less than 5 seconds stall every 2-3 minutes right now, and it's more just a curiosity at those levels. 

The easiest way to see the GUI stalls if you have them, is to carefully watch the 'meters' in MC's main status window.  When they stop bouncing, you're frozen until they start moving again.  Some folks *might* have them and not realize it.

--Bill

[bblue]

A couple of things...

MC's library is recommended to be stored locally.  It's the database, so it gets hit "often" and requires "fast access".  My double quotes here are to indicate that I don't know how much of either is required (how fast, how often); just that this is what I've read around here.  ...and it makes sense.  You want your super fast access stuff (like the database that runs the program) to be local.

You should build a test library with locally stored library files and see how it works.  Library files are very, very small; they won't unnecessarily fill up your SSD disk.

Yes, I've tried a local library for testing, but it didn't make any difference.  I have a very robust switched 1Gbit local network, isolated from the outside world by NAT, and a separate firewall (two different Cisco routers, commercial grade).  The latency from machine to machine anywhere on the localnet is 0-1msec.  I've done repeated tests with Pingplotter watching for any irregular delays, or dropped packets -- there are none, even after steady state monitoring for days at a time.  Still, I suppose if there was a problem on server or workstation that was further into the ip stack than the ping responder, that delays might pop up.  I've never experienced it though.  I use Teamviewer to work on machines even around the corner, locally in my studio and there's never ever any kind of hiccup, delay or odd behavior.  The server is always serving something to the workstation (usually at 192k), and there are never any pauses or restarts.
So I've pretty much ruled out anything network as the cause of the GUI delays (especially since a local library doesn't change it).  The library is accessed by the server as a mounted local filesystem, which would be treated differently than the library communication

From this and later posts, I'm getting that your windows10 system is an upgraded system from 7 and then from 8.1.  I've been doing this for long enough that ANY upgraded windows system is a red flag for me.  Yes, yes, I know you have a ton of experience too. Perhaps more than I do.  That doesn't change the fact that upgraded systems tend to be problematic.  Not every one every time.  But enough of them.  ...and you have a mysterious problem.

Agreed fully.  I'd always prefer a new install than an in-place upgrade, if it weren't for the extreme load it places on me to build this workstation from scratch.  My W7 to W8.1 turned out to be a no go, and on that one I had to re-install 8.1 from scratch plus everything else.  I took just shy of a solid week to bring everything back to full operation.  There are 100's of programs and VST plugins, audio editors (Reaper, Pro Tools, Audition and a couple of others) one fussy video editor (Sony Vegas) and its plugins, and many other a/v utilities and utilities in general.  What an absolute chore that is.

W10 Pro went in pretty well, though it reinstalled some of the plug-ins incorrectly and I had to uninstall and re-install many of them, but everything else just worked.

I would be inclined to do a fresh install of windows10 and go from there.  Fresh OS installs, on any platform, are always more well behaved (statistically speaking).

Good luck with this.  I know from experience that being told to reinstall your OS when you have an application problem seems like overkill.  Ask me how I know.    In some cases, it's the right advice.  In other cases, not so much.  I don't know what your exact problem (or solution) is.  I'm just giving my best advice.  Again, good luck.

Brian.

Thanks Brian.  I know how you know!  I just can't dedicate a week of tedious work and downtime just so MC is 100% happy, though.  Right now, the short little stalls I can live with.  If that changes, well...

--Bill

[ssands]

This might have already been mentioned but the periodicity that you are seeing would indicate some process spinning up, doing its things, and starting its waiting period again. I assume you've watched task manager. What about Process Explorer (and similar) (from Microsoft SysInternals site)?
The mention of a fresh (not updated) install for Win 10 is probably a good option too.
It's sounds so frustrating, but there's got to be an answer, and it should be discoverable.

[bblue]

This might have already been mentioned but the periodicity that you are seeing would indicate some process spinning up, doing its things, and starting its waiting period again. I assume you've watched task manager. What about Process Explorer (and similar) (from Microsoft SysInternals site)?
The mention of a fresh (not updated) install for Win 10 is probably a good option too.
It's sounds so frustrating, but there's got to be an answer, and it should be discoverable.

Quite a while ago when I was having the really long stalls, I tried monitoring task manager, system explorer and proexp for patterns like that, but neglected to find anything.  That doesn't mean there weren't any, just that I didn't catch them.  I also used dpclat (a latency testing program) and was surprised to see no indication of load change on the system during these times.

You're right, it's terribly frustrating to find no indicators other than MC itself, but it's one reason I had originally concluded it was something in MC, not the system.  In my mind, jury's still out on that one.

--Bill

[blgentry]

Agreed fully.  I'd always prefer a new install than an in-place upgrade, if it weren't for the extreme load it places on me to build this workstation from scratch.[...]I took just shy of a solid week to bring everything back to full operation.  There are 100's of programs and VST plugins, audio editors (Reaper, Pro Tools, Audition and a couple of others) one fussy video editor (Sony Vegas) and its plugins, and many other a/v utilities and utilities in general.

Wow, that's quite the collection of audio/video software.  It occurs to me that maybe one of those packages (programs) might be doing something with the system that is hanging up MC.  In particular, Sony Vegas made me remember some older problems.  In theory this was all fixed in MC20, but I don't have direct experience so I'm not sure.

http://yabb.jriver.com/interact/index.php?topic=100745.0

Have you considered installing MC on a different machine?  The one you describe sounds kind of like a house of cards with so much A/V software on it *and* multiple windows upgrades.  I'm not saying either of those are definitely the problem, but I think you'd agree that both are question marks.

Good luck.

Brian.

[bblue]

Wow, that's quite the collection of audio/video software.  It occurs to me that maybe one of those packages (programs) might be doing something with the system that is hanging up MC.  In particular, Sony Vegas made me remember some older problems.  In theory this was all fixed in MC20, but I don't have direct experience so I'm not sure.

Yeah, I remember that.  It wasn't this issue, though.  I worked around it in the past by uninstalling MC, Installing Vegas, then Reinstalling MC.  Whatever that problem was, those steps resolved it for me at least.

Yes, there's a lot installed on this system, but in use not much is running simultaneously at one time.  With Reaper running, there might be 20-30 plugins active, but all of that is a fairly light load even at 96k for the session.  MC isn't running when other intensive programs are.  Its client's server might be going but not doing anything.  The server on another machine is handling library functions and serving.  In actuality when I'm using MC there's usually nothing more than Outlook mail and my browser with 8-10 tabs open.  Sometimes I will keep the Boinc project manager running at 60% CPU, but even then it doesn't change MC's behavior at all.

Have you considered installing MC on a different machine?  The one you describe sounds kind of like a house of cards with so much A/V software on it *and* multiple windows upgrades.  I'm not saying either of those are definitely the problem, but I think you'd agree that both are question marks.

Good luck.

Brian.

Agreed, thanks.  Actually I have a MC on every windows computer in the house (served by the same server).  But my workstation has all the quality hardware on it, the studio speakers, etc., so this is where I listen.  I suppose I could run another computer with just MC on it, but I lose the option of sharing/integrating the HD hardware between multiple sources without a lot of duplication or switching. 

I do room correction with Acourate and Convolution with this MC, and was toying with the idea of another Convolver-only machine (running Acourate Convolver) instead of using my DAW MC so I have proper room corrections on all digital audio going to the studio speakers, but even that makes some audio path combinations rather tricky or inconvenient.  Something like that will be necessary, eventually, though.

--Bill

[JimH]

Wow, that's quite the collection of audio/video software.  It occurs to me that maybe one of those packages (programs) might be doing something with the system that is hanging up MC.  In particular, Sony Vegas made me remember some older problems.  In theory this was all fixed in MC20, but I don't have direct experience so I'm not sure.

I don't think it was ever an MC problem.  Something about the Sony products was opening all of the ASIO drivers immediately when they started, and, for whatever reason, it caused them to crash.