Print

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

[Laffer]

Not sure if anyone else is getting this problem as have searched the forum but not found anything.  When closing MC17 it takes an absolute minimum of 10 seconds to exit.  Is this normal?  I have a pretty high end PC (win7 x64, 6GB, 3.6GHz, 240GB SSD).  Is this a bug or does MC17 not like something on my system?  Older versions of MC never exhibited this behaviour.

I read somewhere in the forums that MC17 is dependant on components of Internet Explorer!  Is that correct?  If so, not sure that will prove wise going forward!  I use Chrome and have never particularly bothered with IE, it is version 8 on my computer.

Had a quick look in the logs, could be reading them wrong but it looks like an awful lot is happening @ MC17 shut down, including contacting various IP addresses.

Any thoughts would be appreciated.

Laffer.

[JimH]

Are you using any third party plug-ins?

[Laffer]

No third party plug-ins at all, just what is installed with MC17.

Again looking at the logs, MC17 seems to do an awful lot in closing down.  I have now done some attentive 'observation' and after startup sometimes I am getting the windows waiting circle 5 seconds or so. If immediately after startup I click playlists then I can get the waiting circle for up to 8 maybe 10 seconds.  As previously stated about 10 secs delay after clicking close, sometimes with the blue waiting circle.

What is MC17 doing?  Perhaps more to the point can I turn all that off in any way?  Is it necessary?

[glynor]

See if it goes away completely if you temporarily disable the Media Network server.

I've long-had a similar issue on one of my machines, which Matt has been trying to track down, but I only see it on one machine generally.  If I disable the Media Network server functionality, it completely goes away.

[Laffer]

Installed 17.0.103.  Media Network disabled.  Also tried disabling Podcast auto download (I don't have any and don't use podcasts).

On start up, if I immediately click through a couple of playlists, I get an 8 to 10 second delay.

Very rarely, the program exits normally (immediately) but 95% of the time there is still a delay before close.

A couple of weird ones from the log :
0014009: 5360: Podcast: CPodcast::RemoveConfig: Finish (6771 ms)
0014009: 5360: Podcast: CPodcast::~CPodcast: Finish (6771 ms)

From a later log
0012995: 1464: Playback: CMJWaveFeeder::Thread: Finish (3978 ms)
0013057: 1164: Playback: CWaveOutBinPlayThread::Thread: Finish (4009 ms)
0015678: 6580: Podcast: CPodcast::RemoveConfig: Finish (7675 ms)
0015678: 6580: General: CLoaderThread::PerformAction: Finish (7675 ms)

Any ideas?  This is not a show stopper but incredibly annoying.  More than happy to send a log if interested............

[JimH]

In Tools/General/Features, try disabling podcasts.

In Explorer, are there any drives shown that aren't there?  Try unplugging all USB devices, etc.

[Matt]

Installed 17.0.103.  Media Network disabled.  Also tried disabling Podcast auto download (I don't have any and don't use podcasts).

On start up, if I immediately click through a couple of playlists, I get an 8 to 10 second delay.

Very rarely, the program exits normally (immediately) but 95% of the time there is still a delay before close.

A couple of weird ones from the log :
0014009: 5360: Podcast: CPodcast::RemoveConfig: Finish (6771 ms)
0014009: 5360: Podcast: CPodcast::~CPodcast: Finish (6771 ms)

From a later log
0012995: 1464: Playback: CMJWaveFeeder::Thread: Finish (3978 ms)
0013057: 1164: Playback: CWaveOutBinPlayThread::Thread: Finish (4009 ms)
0015678: 6580: Podcast: CPodcast::RemoveConfig: Finish (7675 ms)
0015678: 6580: General: CLoaderThread::PerformAction: Finish (7675 ms)

Any ideas?  This is not a show stopper but incredibly annoying.  More than happy to send a log if interested............

Is it possible you have Podcasting configured to point to a machine that's off?

Options > Podcast > Podcast Directory

[Laffer]

Thanks very much Jim and Matt.  From your replies I managed to put 2 and 2 together and came up with 4.

I was intending to play with the Video abilities of MC17 so put a network path (to my server, that is off more than on) into the 'Tools > Options > File Location > Other Video' setting.

I have changed that path to an empty folder on my SSD and all seems well now, MC is back to it's usual very responsive self.  However I am surprised MC didn't handle this better, as it looks like it was polling the non existent path (instead of setting a flag or perhaps vastly reducing the time out).

Anyway, once again, thanks very much.

For reference, these look a little more healthy now..... Note : I have not changed any podcast settings other than auto download (still disabled).

0005397: 6428: Podcast: CPodcast::RemoveConfig: Finish (15 ms)
0005397: 6428: Podcast: CPodcast::~CPodcast: Finish (15 ms)

[JimH]

I was intending to play with the Video abilities of MC17 so put a network path (to my server, that is off more than on) into the 'Tools > Options > File Location > Other Video' setting.....  I am surprised MC didn't handle this better, as it looks like it was polling the non existent path (instead of setting a flag or perhaps vastly reducing the time out).

I can't think of a good way to defend against this, since a server can be down or unavailable for many reasons.  A disk can spin down after some period of inactivity, for example. 

I wonder if you also had auto import set to check that location.  Turning that off might fix the problem.

Thanks for reporting what you found.

[Matt]

However I am surprised MC didn't handle this better, as it looks like it was polling the non existent path (instead of setting a flag or perhaps vastly reducing the time out).

This is much harder than it should be on Windows.

We do cache whether a drive / UNC machine is available, and only check once in a while.

But that first check can take 30 seconds (and sometimes much more) while the operating system does who-knows-what.  Type \\missing in your Run box and see how long it takes before Windows says "that didn't work."

Early in v17 we were looking for a faster way to detect a missing UNC path, but we never came up with anything reliable.  I guess if Windows itself can't do it, we probably can't either.

[Laffer]

Thanks very much for the replies.

Matt, it has been over 20 years since I did any programming and I have never written anything for/on/under Windows, so please excuse a potentially provocative observation and certainly not trying to teach my granny to suck eggs!

I can type \\missing in the runbox but then start and use other programs without ill effect, Windows does not 'halt'.  The reason this was so noticeable (and annoying) on MC is the fact you cannot do anything.  Even clicking on a playlist just does nothing, it is like the command is queued, then gets executed when control is returned to the interface between 6 and 10 seconds after clicking.

As I said, my programming knowledge is well out of date but I am surprised this is not just some function call with a return parameter or flag set that you can check at your desired interval?  In these days of multiple threads etc, seems very strange the interface gets locked up when submitting a network request.

Jim,
I don't use auto import (yes, call me a control freak!)  My answer above also applies to the "Drive suddenly not there" scenario too, but the app/play engine would have to have error handling built in for that eventuality (a source that is playing suddenly not being there).

Just for clarity, my music is kept locally on a RAID 0 and that folder is set correctly.  The only other folder setting I changed was the 'Other Video' setting.

Keep up the sterling work with MC.

[janh]

Most times when I finish MC, it takes 5+ sec to close. I don't bother much, thought that was "normal". I only play music files Wav.