Print

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

[marko]

Something else I'm seeing here, and have done through most of v17, that would also stop me doing this, is that while MC launches and loads really quickly, after a few seconds it goes all unresponsive for maybe 10 - 20 seconds. After that, all is good. I always assumed that this was just auto import running a scan for any file changes and put up with it, but now I am made to actually think about it, perhaps I shouldn't put up with it? Anyone else see that? Does it deserve a thread all it's own?

-marko

[JustinChase]

Anyone else see that? Does it deserve a thread all it's own?

I do, and even sent a log to Matt once, and he was very helpful in figuring out that MC was looking for a drive that had not been used for months.  I never figured out why it was happening, or how to fix it, so I also live with the not-so-occasional unresponsiveness of MC.

I would like it to go away though.  I'll try to capture a new log file this weekend and create a thread, or add to yours if you beat me to it.

[rjm]

Something else I'm seeing here, and have done through most of v17, that would also stop me doing this, is that while MC launches and loads really quickly, after a few seconds it goes all unresponsive for maybe 10 - 20 seconds. After that, all is good. I always assumed that this was just auto import running a scan for any file changes and put up with it, but now I am made to actually think about it, perhaps I shouldn't put up with it? Anyone else see that? Does it deserve a thread all it's own?

-marko

I'm so glad you raised this. I have seen this issue for a long long time.

I believe the periodic crashes I see may be related to this unresponsive startup issue because the crashes seem to most frequently happen during this period.

I suspect (but am not sure) that the unresponsiveness has something to do with creating a new thumbnail for the first time after startup because I see the hang most frequently when I start MC and immediately navigate to a folder with un-imported files which then causes MC to create thumbnails.

Maybe you and I see it more often than others because of large thumbnail caches?

[rjm]

20 seconds is more typical than 10 seconds

[JimH]

A drive spinning up could explain that.

What else do you have in common?

Starting in Theater View?

OS?

Virus checker?

Third party plug-ins?

Location of MC's library on an external drive?

etc.

[rjm]

Not a drive spin-up issue because hard drive activity is maxed out the entire period that MC is unresponsive, hence my guess that it is doing some heavy startup activity with my large thumbnail cache.

Do not use theater view.
XP.
Microsoft Security Essentials.
No 3rd party plug-ins.
Library on fast local drive.

[JimH]

Not a drive spin-up issue because hard drive activity is maxed out the entire period that MC is unresponsive...

That may be what you would see if the drive wasn't spun up.  I'm not sure.

[rjm]

That may be what you would see if the drive wasn't spun up.  I'm not sure.

I can see the light solid on and hear the heads thrashing which means it is already spun up and working to max capacity.

[Matt]

As a test, please disable any third-party plugins.  They're loaded in the main thread, so could cause a delay if they did something slow.

[JustinChase]

windows 7 x64
Avast anti-virus
library is on an SSD, nothing to spin up
don't start in Theater View
have no 3rd party plugins running

It does seem to be an issue with importing new media and/or thumbnailing the new media.

[Vincent Kars]

In my case JRiver starts up, display cover, I might even select an album but then is freezes.
I do have the audio on a NAS and the monitored folder points to the NAS.
The HD of the NAS has to spin-up possibly causing the delay.

I also have a working set on the local HD only.
There the same happens.

[struct]

I have seen the same thing for a long time now, just got used to it.  When I start MC I get an immediate standard screen and can start scrolling with no delay.  After a few seconds (maybe 4-5 sec) it freezes for a few seconds, and after that all is ok.  I have recently moved to ssd and found the delays is now much shorter (a few seconds instead of 10 sec).  I originally thought it might have been my slow drives and MC was grabbing more thumbnail images, but now testing, it seems independent on how far I scroll, so can't be that.  Seems like a fixed point in time.

W7 x64  
MC and caches on SSD media on local drives access through network path
Latest MC
No 3rd Party Plugin except PVDImport but it is "hidden"
Have gone through periods of no virus checker and still have delay.

[JimH]

The logs might show what is happening.

[marko]

I do, and even sent a log to Matt once, and he was very helpful in figuring out that MC was looking for a drive that had not been used for months.

Interesting. So, on my test setup, I used a restored library from my every day use MC, including the settings, so I logged it. The closest I could see to the above is shown below...

Code: [Select]

0038282: 1132: General: CFileSystemManager::GetDriveExists: Error using connection '\\NETTIE-PC\Users': 67
0038282: 1132: General: CFileSystemManager::GetDriveExists: Drive does not exist (drive: \\NETTIE-PC\Users, filename: \\NETTIE-PC\Users\Nettie\Music\iTunes\iTunes Media\Music\)
0038282: 1132: Handheld: CHHManager::InitializeProxyDevice: Finish (38064 ms)
0038282: 1132: Handheld: CHHManagerMap::EnumDevices: Finish (38064 ms)
0038282: 1132: Handheld: CWMDMThread::ProcessMainThreadMessage: Finish (38064 ms)
Now, I'm not certain if this is the hang, what's 38,000 ms, about 4 seconds? The hang is certainly longer than that. For example, if you're quick, you can launch MC, then get the "Logging" options open before it hangs, at which point, the logging options window loses all it's skinning, falling back to a Windows 7 frame that proclaims "Not Responding" in the title bar.

Anyhow, this was a failed attempt at setting my wife's laptop as a "hand held device" about 10 months ago. It never really worked out (because my wife's a technophobe) so I moved on to a different solution.
As this was the test machine, I hit the "redetect devices" option and restarted MC, and sure enough, the big lag has gone. I performed highly technical testing to verify this, which involved launching MC, then moving the mouse up and down a list, watching the "hover marker". Usually, about 5 seconds in, it would stop following the mouse, and the freeze was on for 10 seconds or so from that point. Now, having redetected HH devices, there is the slightest of hiccups, literally a fraction of a second, and that's it. No more freezing.

Now, here's the thing...
I absolutely do not want to be hitting the redetect button on the main MC setup. So, instead, I am going to try something else and will report back shortly...

-marko

[marko]

So, here's what I did...

I opened Regedit and went to HKEY_CURRENT_USER\Software\JRiver\Media Center 17\Portable Devices

It was chock full of phones and various usb drives that had been plugged in to my PC over the years, including my wife's laptop!
I deleted all of the entries here except for my own iPod and the virtual device I set up for my Granddaughter (folder on local, internal drive), and the lag is all but gone. Using my highly technical testing methods outlined above, it blips twice, then a few seconds later the panes do a little shuffle, settling their width, and then all is good.

So, in conclusion, still not seamless smooth, but infinitely better.
I should not have to hit the "redetect devices" button to fix the lag. That would mean I would have to go through the whole rigmarole of setting up my iPod and the local device plus any others I might wish to keep, and I don't want to do that. Who would?
Why are these dead devices causing problems?
Could we have a list of detected devices that we can pick from for removal from MC?

-marko

[Jong]

38000ms is 38 secs   

[marko]

That's more like it!! Cheers Jong

After cleaning up the registry, the times have come way, way down:

Code: [Select]

0010951: 7096: Handheld: CHHManager::InitializeProxyDevice: Finish (78 ms)
0010951: 7096: Handheld: CHHManagerMap::EnumDevices: Finish (171 ms)
0010951: 7096: Handheld: CWMDMThread::ProcessMainThreadMessage: Finish (171 ms)
and my iPod still syncs as desired.

-marko

[JustinChase]

Interesting.  I had to go one deeper, to "Detected Devices" to see anything, but here is what I see there.  I'm not sure which of these is really my phone (HTC EVO/Supersonic).  The others are USB drives I've used, but I don't care if they get reset/killed.  I'll probable just reset them with MC, since it's not too hard to set my phone up again (one playlist).  Just thought I'd share, in case it helps resolve this.

*Can't do it now, since I'm actually syncing the phone while I'm typing this

[rjm]

Amazing! Cleaning the registry seems to have solved my startup hesitation.

I deleted 7 unused items from
HKEY_CURRENT_USER\Software\JRiver\Media Center 17\Portable Devices\Detected Devices\

And for good measure I also deleted all items in
HKEY_CURRENT_USER\Software\JRiver\Media Center 17\Portable Devices\Conversion\
that did not have a matching item in Detected Devices.

When I navigate at startup to a folder with a couple un-imported videos I still see the hard drive max on for about 30 seconds until MC builds the thumbnails but unlike before this fix, MC remains responsive and smooth.

I will monitor and report back as to whether this also solves the periodic crash I see. This will take a few weeks for me to be sure.

One more observation that I don't know if relevant....

Before cleaning the registry I exported the key with regedit to create a backup in case I needed to undo the registry change. When I inspect the exported reg file with a text editor I see another device that was not visible with regedit. Very strange. Not sure what this means. Could it suggest registry corruption?

Thanks marko. This startup lockup problem has been bugging me for a very long time.

[Matt]

Why are these dead devices causing problems?

At some point you must have added a virtual device that points to a UNC path that's no longer valid.

We've never been able to find a fast, reliable way to detect if a UNC path is valid.  I believe it's a weakness in Windows (type \\NETTIE-PC\Users in your Run box and you'll see Windows hang for 40 seconds too).  So when loading devices, we're checking if the device is valid and it hangs.

I'm not sure what should happen in this case.  It's reasonable to configure a virtual handheld to point to something that comes and goes (a backup drive, for example).

Maybe we shouldn't allow UNC paths for virtual devices?  Or maybe a virtual device should go away after it fails to load three times in a row?  Other ideas?

[rjm]

At some point you must have added a virtual device that points to a UNC path that's no longer valid.

I'm not sure that your UNC theory explains everything.

I do not see any UNC paths in the devices I deleted. I do see pointers to removable drive letters that are not connected.

But I also see pointers to unconnected drive letters for the 2 devices that are valid and are still in my registry.

It's possible I do not understand what I am looking at. I can send you my registry key backup if you want it.

[lise]

YES! I haven't fixed it yet, but it's been driving me crazy. I was just about to redo my machine from scratch just because of those lags in MC.  For me it started about 3-4 months ago, and many of those lags show a "MC is not responsing" dialog box before working again.

Edit--I cleared the registry as per instructions near bottom of page 1 of this thread and now it works like a charm.

[JimH]

At some point you must have added a virtual device that points to a UNC path that's no longer valid.

We've never been able to find a fast, reliable way to detect if a UNC path is valid.  I believe it's a weakness in Windows (type \\NETTIE-PC\Users in your Run box and you'll see Windows hang for 40 seconds too).  So when loading devices, we're checking if the device is valid and it hangs.

I'm not sure what should happen in this case.  It's reasonable to configure a virtual handheld to point to something that comes and goes (a backup drive, for example).

Maybe we shouldn't allow UNC paths for virtual devices?  Or maybe a virtual device should go away after it fails to load three times in a row?  Other ideas?

When we see that kind of delay, maybe we could ask the user what to do.

[JustinChase]

So when loading devices, we're checking if the device is valid and it hangs.

I'm not sure what should happen in this case.  It's reasonable to configure a virtual handheld to point to something that comes and goes (a backup drive, for example).

Maybe this doesn't need to be done upon startup.  Maybe only check when a user goes into handhelds, and if any handheld is not found at that time, then ask if it should be kept for later, or deleted.

I would suppose that whenever a user starts MC, they usually want to play some media pretty much right away, so doing all of these checks and thumbnail building just delays the users ability to play media.  Maybe all of these checks and such should wait 60 or 120 seconds before beginning, or until the time they are actually needed.

Doing everything possible to prevent delays for 'background' tasks should be a priority, IMO.

[Scolex]

Maybe we shouldn't allow UNC paths for virtual devices?  Or maybe a virtual device should go away after it fails to load three times in a row?  Other ideas?

What about a setting that appears the first time you attach a portable device that asks whether to keep or remove the device entry after being disconnected.
If delete is selected a record of the device specifics are written so it knows not to ask whether to be kept or removed in the future.

[marko]

Maybe this doesn't need to be done upon startup.  Maybe only check when a user goes into handhelds, and if any handheld is not found at that time, then ask if it should be kept for later, or deleted.

I quite like this idea, but it still wouldn't solve the the 40 second "not responding" issue. At least, not for the first run, and it would only fix it if I knew that the unc 'device' was the one causing the problem, and if I actually wanted to delete it. If I wanted to keep it, what then?

Is there no way to run these checks while at the same time allow MC to continue operating normally? Is that "polling vs event based"? (Mr ChriZ taught me that )
I'm guessing it's "not responding" because MC is asking "have the devices been checked yet?" over and over until the device checker says "Yes, here's the list". Can't MC just say "tell me when the list is ready" and then carry on with its business? If a user goes in to Hand Held Devices before the list is ready, MC could show a message along the lines of "Waiting for available devices".

I would suppose that whenever a user starts MC, they usually want to play some media pretty much right away, so doing all of these checks and thumbnail building just delays the users ability to play media.  Maybe all of these checks and such should wait 60 or 120 seconds before beginning, or until the time they are actually needed.

Regardless of when the check is ran, there is still going to be a 30+ second hang. If that happens to coincide with the end of a track, the next track will not play until MC is responsive again. I do think you have something there though. The original issue that spawned this discussion was file associations and playback initiated from Explorer. Perhaps, if playback is started in this way, MC should forego all those checks until playback is stopped?

-marko

[rjm]

Another approach might be to not check nor care if a UNC path is invalid.

Just report an error when the invalid path is actually required to do something.

[rjm]

Just want to emphasize how great this "fix" is.

I used to avoid opening MC for small tasks like "do I already have that pdf book?" because I knew I'd be hung for 30+ seconds. Now I start and stop MC like I do with any light weight app.

Very nice.

[ldoodle]

We've never been able to find a fast, reliable way to detect if a UNC path is valid.

Could you not embed a single byte ping to the UNC 'base path';

\\SERVERNAME\Films = ping -l 1 SERVERNAME -n 1

and take action based on the result of the ping? I do this in some batch files for remote shutdown, as even if a ping command times out, it's still only ~3 seconds.

[JustinChase]

Regardless of when the check is ran, there is still going to be a 30+ second hang. If that happens to coincide with the end of a track, the next track will not play until MC is responsive again.

I'll guess an average audio track is 3 1/2 minutes, so the chances of this hang coinciding with the end of the track is not very large, and I'd prefer to suffer this every once-in-a-while, than every time I start MC.

Hopefully a better idea comes along (or has already been suggested), but in case not, this hang would be better delayed with the possibility that it doesn't affect usage.