Print

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

[JustinChase]

I launched MC, and it gave me the 'bad shutdown' dialog box. I unchecked the 'use default library' option, then clicked okay.  it took me to a black screen, with the MC circle spinning, but didn't to anything else.  After several minutes, I checked task manager, and it was "not responding", obviously.  After many minutes, I eventually killed the process.  I then re-launched MC, but this time I left the 'use default library' option checked.  it did the same thing, but it was at least 5 minutes until I decided to write this post.  While writing, it finally launched okay.  I clicked on a view scheme, and that took a rather long time until it finally showed the view.

I grabbed the error log, and have attached it.

Hopefully there is some  useful information to help figure out why it hung for so long.  It's not the first time this has happened, in fact, it's not uncommon.

I'd love to see this kind of thing fixed at least to the point that whatever has hung MC does not prevent the GUI from responding.

[glynor]

This doesn't look good.

Thead 4288 is the main thread:

Code: [Select]

0000000: 4288: General: Starting logging: Date: 5/1/2014 7:39 pm
So, it goes along for a little bit and loads the default library here:

Code: [Select]

0003635: 4288: Database: MCDB::Load: Loading from path: C:\Users\myrna\AppData\Roaming\J River\Media Center 19\Library\
Then it handles some resizing stuff for the main UI window, and starts loading the Startup View:

Code: [Select]

0003885: 4288: General: CMainUIWnd::Resize: Finish (94 ms)
0003885: 4288: General: CMCUICore::SetMode: Finish (109 ms)
0003885: 4288: General: CMCPlayerApp::InitInstance: Showing startup view
0003901: 4288: General: CMainUIWnd::SetMCView: Start
0003901: 4288: General: CMainUIWnd::SetMCView: View info name: Start
0003901: 4288: General: CMainUIWnd::SetMCView: Hiding old view
0003901: 4288: General: CMainUIWnd::SetMCView: Creating new view
Then it initializes some extra threads.  Stuff starts going badly pretty quickly.

It loads the View Container Window:

Code: [Select]

0003901: 4288: General: CMCViewContainerWnd::Create: Start
0003901: 4288: General: CMCViewContainerWnd::Create: Creating window
0003901: 4288: General: CMCViewContainerWnd::Create: Initializing
0003901: 4856: General: JRIpcServerThreaded::Thread: Start
0003901: 4856: General: JRIpcServerThreaded::Thread: Starting server loop for: JRWeb Client {8B75DE64-4910-4052-AEF0-106CC05205B5}
Notice, we're at 3901ms after loading on the main thread.  Here's the equivalent section from my Previous Log, by the way:

Code: [Select]

0001187: 3432: General: CMCViewContainerWnd::Create: Start
0001187: 3432: General: CMCViewContainerWnd::Create: Creating window
0001187: 3432: General: CMCViewContainerWnd::Create: Initializing
0001219: 8352: General: JRIpcServerThreaded::Thread: Start
0001219: 8352: General: JRIpcServerThreaded::Thread: Starting server loop for: JRWeb Client {CDD1C204-6C06-4214-A871-2E21381B513B}
I'm only at 1100ms at this point, but that can be explained by the "improper shutdown" popup dialog you got, which appears at the very head of your log and seemed to take three seconds to load:

Code: [Select]

0000032: 4288: General: CMCPlayerApp::InitInstance: Loading skin
0000156: 4288: General: CMCUICore::SystemPowerManager_UpdateActions: Start
0000156: 4288: General: CMCUICore::SystemPowerManager_UpdateActions: UI Mode: -2000; Playing: 0
0000156: 4288: General: CMCUICore::SystemPowerManager_UpdateActions: Finish (result: 0) (0 ms)
0001857: 4288: General: CMCUICore::GetPopupShowing: popup showing=true, window class name=JRiver Popup Class
0003542: 4288: General: CMCResourceHelper::GetIsModalPopupShowing: Message box showing
I have no similar delay in mine, but I also didn't show the popup in my log.  It might have just been waiting for you to respond to the dialog for much of that time.  So, I'd say we pretty much match at this point.

Then, it spawns a background reader thread, and goes away from the log for a bit, and you get one of these:

Code: [Select]

0003916: 1184: Reader: CWinINetReader::DownloadFromHTTPURL: Start
0004213: 1184: Reader: CWinINetReader::DownloadFromHTTPURL: Retry needed, trying again...
0004213: 1184: Reader: CWinINetReader::Connect: Start
0004213: 1184: Reader: CWinINetReader::Connect: Finish (0 ms)
0004696: 1184: Reader: CWinINetReader::DownloadFromHTTPURL: Success
0004696: 1184: Reader: CWinINetReader::DownloadFromHTTPURL: Finish (780 ms)
0004696: 1184: Reader: CWinINetReader::Thread: Finish (780 ms)
0004696: 4288: Reader: CWinINetReader::Open: Finish (780 ms)
My log is riddled with that pattern, though not till a bit further down.  I use the IE engine instead of Chromium though, and it looks like with Chromium it asks the JRiver servers for any updates to the engine when it loads the first time (and the initial failure is probably a redirect).  So, that (in itself) doesn't look that unusual, and it returns back quickly enough.

So, it finished opening whatever from JRiver it wanted to get and the main thread comes back at 4600ms.  But it still hasn't finished CMCViewContainerWnd::Create, making the view container window.

The very next lines are still the main thread:

Code: [Select]

0574802: 4288: Reader: CWinINetReader::Close: Start
0574802: 4288: Reader: CWinINetReader::Close: Finish (0 ms)
Woah, that was a jump.  Then it goes away again and JRWebApp and Chromium start doing their thing in background threads.  Then, finally CMCViewContainerWnd::Create comes back...

Code: [Select]

0582149: 4288: General: CViewHeaderWnd::Initialize: Start
0582149: 4288: General: CViewHeaderWnd::Initialize: Finish (0 ms)
0582149: 4288: General: CMCViewContainerWnd::Create: Finish (578248 ms)
0582149: 4288: General: CMainUIWnd::SetMCView: Loading view
578248 ms is 9 and a half minutes.  That's right at the head of your log.  It is not failing to do it, but is having an incredibly hard time creating the initial view container.

My Previous Log follows the same basic pattern (with differences because of IE vs Chromium but nothing too weird) but, here's mine:

Code: [Select]

0001500: 3432: General: CViewHeaderWnd::Initialize: Start
0001516: 3432: General: CViewHeaderWnd::Initialize: Finish (16 ms)
0001531: 3432: General: CMCViewContainerWnd::Create: Finish (344 ms)
0001531: 3432: General: CMainUIWnd::SetMCView: Loading view
So, that's what the problem is.  It is getting stuck when trying to create the initial view window itself.  The Library has long since been loaded (that happens pretty quickly and appears normal in your log).

From there on, it looks like it is doing a lot of looping and waiting for stuff to return.  But it doesn't much matter, as you're 9.5 minutes in at that point.

[glynor]

Turn off Chromium, if that wasn't clear.  That might not be it, as the Chromium and JRWebApp loops look like they're working, at least at first, but those could be just the message loops.

MC uses web views all over the place though (many of the View headers are JRWeb based).  But either way, it goes to open the initial view window, needs to load the Chromium engine, and then right after it finishes checking for updates, it hangs for 9.5 minutes.

Something in there seems borked.  You might have a bad Chromium engine stuck in there (you could try nuking the install, and re-installing), but I'd turn off Chromium first.  If you can't get it to load stably enough to be able to turn it off, you could uninstall and clear settings, which would do it.  Or, if you're on a 64-bit version of Windows, I can export a REG file for you with the appropriate options key.

[JustinChase]

This doesn't look good...

578248 ms is 9 and a half minutes.  That's right at the head of your log.  It is not failing to do it, but is having an incredibly hard time creating the initial view container...

So, that's what the problem is.  It is getting stuck when trying to create the initial view window itself.  The Library has long since been loaded (that happens pretty quickly and appears normal in your log).

From there on, it looks like it is doing a lot of looping and waiting for stuff to return.  But it doesn't much matter, as you're 9.5 minutes in at that point.

Thank you so much for taking the time to review this and provide such detailed feedback.  It felt like longer then 10 minutes, but that's probably just because everyone was waiting to watch a movie, and staring at me like I'm an idiot

Hopefully this information will be useful to Hendrik in finding out what caused it and eliminating this horrible lag.

Apart from whatever is causing the lag, I hope that at least the GUI can be functional while it's going whatever it was doing.  Allowing me (or anyone) to navigate and interact while the background has it's issues will at least let one feel like it's not totally broken.

Turn off Chromium, if that wasn't clear.  That might not be it, as the Chromium and JRWebApp loops look like they're working, at least at first, but those could be just the message loops.

MC uses web views all over the place though (many of the View headers are JRWeb based).  But either way, it goes to open the initial view window, needs to load the Chromium engine, and then right after it finishes checking for updates, it hangs for 9.5 minutes.

Something in there seems borked.  You might have a bad Chromium engine stuck in there (you could try nuking the install, and re-installing), but I'd turn off Chromium first.  If you can't get it to load stably enough to be able to turn it off, you could uninstall and clear settings, which would do it.  Or, if you're on a 64-bit version of Windows, I can export a REG file for you with the appropriate options key.

I did just change it to IE, and will report back if I see this problem again.

[glynor]

To be clear, there is something weird about you.  This isn't common, even with Chromium as the engine.

Something is broken about your installation, specifically.  Now, that could be a bug in MC that only appears in rare conditions, or it could be that your system is just broken.  However, I recently started a thread in the beta board about the Chromium engine, and a bunch of people responded that they'd been using it for years (and still were) with no issues.

In any case, that kind of behavior is not something I've EVER seen on any of my machines, unless something was badly broken.

Also, to note:

Apart from whatever is causing the lag, I hope that at least the GUI can be functional while it's going whatever it was doing.  Allowing me (or anyone) to navigate and interact while the background has it's issues will at least let one feel like it's not totally broken.

MC spins off all sorts of things into background threads to keep the main thread responsive.  However, the way GUI programming works (generally) is that if something updates the GUI (the stuff you see) this MUST be done on the main GUI thread.  You can do a lot to prevent these kinds of issues, and MC does, but if stuff is broken and unexpected, and it happens when doing things as basic as trying to create the window itself, there is nothing you can do to "hide it".

Again, your system is messed up.  I'm not sure how, or why, but something is borked.

I think trying without Chromium, unless you had a particular technical reason to enable this non-default option, is a good course of action.  You could try uninstalling entirely and reinstalling from scratch to try to make sure you have a proper version of the Chromium engine.

It could also, certainly, be interference from Security software, blocking the network connections (or additional thread spawning) that MC does.

[JustinChase]

To be clear, there is something weird about you. 

OUCH!! 

This isn't common, even with Chromium as the engine.

Something is broken about your installation, specifically.  Now, that could be a bug in MC that only appears in rare conditions, or it could be that your system is just broken.  However, I recently started a thread in the beta board about the Chromium engine, and a bunch of people responded that they'd been using it for years (and still were) with no issues.

In any case, that kind of behavior is not something I've EVER seen on any of my machines, unless something was badly broken.

Also, to note:

MC spins off all sorts of things into background threads to keep the main thread responsive.  However, the way GUI programming works (generally) is that if something updates the GUI (the stuff you see) this MUST be done on the main GUI thread.  You can do a lot to prevent these kinds of issues, and MC does, but if stuff is broken and unexpected, and it happens when doing things as basic as trying to create the window itself, there is nothing you can do to "hide it".

Again, your system is messed up.  I'm not sure how, or why, but something is borked.

I think trying without Chromium, unless you had a particular technical reason to enable this non-default option, is a good course of action.  You could try uninstalling entirely and reinstalling from scratch to try to make sure you have a proper version of the Chromium engine.

It could also, certainly, be interference from Security software, blocking the network connections (or additional thread spawning) that MC does.

I realize it's not common, but I've seen many threads over the years about slow response from MC, so it's not just me.

Again, hopefully Hendrik can/will take a look, and perhaps see something to at least point me to the right direction to see what's wrong.

I've had this library, in one form or another for probably over a decade.  I've considered just starting a new library, from scratch, but I have no desire to re-create all my views and playlists from scratch.  I don't know of any other way to get those back, without restoring the settings in a library restore, which seem as likely to bring back my problem, so makes the whole thing an exercise in futility, I think.

[glynor]

I don't think, though I could be wrong, that this has anything to do with your Library (from what I can see in the logs).

You may try changing the Startup Location in MC to something else, to see if that solves it, assuming getting rid of Chromium doesn't cover it.

[JustinChase]

I don't think, though I could be wrong, that this has anything to do with your Library (from what I can see in the logs).

You may try changing the Startup Location in MC to something else, to see if that solves it, assuming getting rid of Chromium doesn't cover it.

Hmmm... My startup location is 'last location'.  If I have continued issues, I'll change it to something else.

I was just thinking again that perhaps the fact that I restored a library saved by a different machine might have something to do with it.  just thinking out loud.  Both machines use the same directory mapping/drive letters, so that should not be a problem.

[glynor]

I'm wondering if you have some specific View in your MC Library that is broken (or perhaps loops infinitely with a bad expression in the search) that causes it when you happen to shut it down with that View last used.

But, I still think Chromium is the more likely culprit.  Or AV software, or something else borked on your Windows install.

[JimH]

Or a drive or other device that doesn't exist.

Checking for a network drive that doesn't exist takes a long time to return.

[glynor]

Or a drive or other device that doesn't exist.

Checking for a network drive that doesn't exist takes a long time to return.

Yeah, it can, but not 9.5 minutes.

[JustinChase]

I'm wondering if you have some specific View in your MC Library that is broken (or perhaps loops infinitely with a bad expression in the search) that causes it when you happen to shut it down with that View last used.

Or a drive or other device that doesn't exist.

Checking for a network drive that doesn't exist takes a long time to return.

How would I determine this?  Is there anything in the logs (Hendrik?) that points to something like this?  I suppose I could just start removing views, but that seems pretty extreme.

I had reported something like this a long while back, and Matt had pointed to an R: drive causing issues, but we never got to the bottom of it.

But, I still think Chromium is the more likely culprit.  Or AV software, or something else borked on your Windows install.

I have changed it to IE, and will take another look at any AV software.  Not sure what else to try at this time.

[JimH]

Look at the file locations in your files and in MC settings.

You can sort a view by location.

We had one a long time ago that was a bad device connected to a USB port.

Try a new (test) library.

[glynor]

Please note: Don't do any of that now. It is very important to always do one thing at a time. Otherwise you don't learn anything from your test.

You've already changed from Chromium to Internet Explorer. Wait for that to show results. If you still have issues then switch back to Chromium and try something else. If you do lots of different things all at the same time will never know what solved the problem or what didn't.

Edited: Fixed typos because Siri.

[Hendrik]

The log indicates that it indeed was downloading Chromium, and for some reason the download just took ages.
We should probably try to move that browser download to a different thread and refresh the web view whenever its done, but especially during startup thats a bit tricky.

[JustinChase]

Hmmm...

That machine has Chrome as it's default browser.  I wonder why MC would think it needs to download it again.  Weird.

I've changed to IE, so hopefully this won't happen again.  I'll report back if it does.

Thanks everyone for taking such a close look!

[glynor]

That machine has Chrome as it's default browser.  I wonder why MC would think it needs to download it again.  Weird.

Chromium and Chrome aren't the same thing.

[JustinChase]

Chromium and Chrome aren't the same thing.

Hmmm... Okay.

It sounds like Chrome is based on/uses Chromium, so it still seems like it should be able to use the Chromium core of Chrome browser.

I guess this isn't possible for some reason.  I don't need the explanation, just find it curious.

Hopefully using IE will resolve this issue for me.