Topic: MC 12 close to freeze system (Read 4719 times)

globetrotters1 · « **on:** May 10, 2008, 08:58:31 am »

Within the last days I installed MC 12.0.492 and I'm intrigued by the improvements made to many functions!

The only problem I run almost daily once or twice into is: if I play music, import some new albums and have a process running with analyzing imported music tracks (just imported some minutes before), the system locks up, but doesn't freeze completely - I see CPU 99% idle - I can move the mouse, the Windows Explorer gets unresponsive (also cannot be closed), no windows paint anymore, it's just like MC12 would run in a loop somewhere

No worries, I did all possible before I ask here (re-install etc etc etc)

Any hints?

KingSparta · « **Reply #1 on:** May 10, 2008, 09:03:18 am »

MC will generate a activity log, so you maybe able to tell whats going on.

it is under the help dropdown in mc

globetrotters1 · « **Reply #2 on:** May 10, 2008, 09:32:49 am »

now I have such a logfile, it's huge, what do you want me to post here? the last 30 lines? or what?

To kill the stuck processes I saw the following CPU usage
Media Center 12.exe - 1%
ekrn.exe - 50%
System Idle Process - 49%

no windows painted anymore
windows explorer couldn't be terminated anymore
media center was stuck

KingSparta · « **Reply #3 on:** May 10, 2008, 09:46:54 am »

EKRN.EXE is related to Eset NOD32 Antivirus software.
http://www.eset.com/

globetrotters1 · « **Reply #4 on:** May 10, 2008, 11:07:24 am »

good to know, but it seems that some file doesn't get released and MC12 / NOD32 lock each other up - or am I wrong?

I use NOD32 since years without any problem and on many computers and with hundreds of different programs, so I suppose that the problem might rather be MC12... without intention to insult anyone, please understand me right! But it seems to be a problem here and I suppose other people might run into the same problem too. I'm also not very keen on running the Media Center computer without any kind of virus protection, as it's a part of the network and the network is hooked onto the Internet (although with a router linked in-between the network and the Internet connection modem).

The problem is furthermore easily reproduceable and (which makes me think a bit...) it just didn't happen in older versions of your program (for instance in version 12.0.456 or such) - there it NEVER happened

Isn't that a clear sign that the problem lies rather with this version of MC12?

hit_ny · « **Reply #5 on:** May 10, 2008, 12:00:41 pm »

It might make you case stronger if you temporarily switch off NOD32 and then try to reproduce the problem.

If it does not happen then something with NOD32 +MC is in conflict.

However if it happens again and you know how to reproduce it then you have a better case to show there is maybe a bug with MC12.

globetrotters1 · « **Reply #6 on:** May 10, 2008, 01:59:09 pm »

MC12 alone runs fine, NOD32 with all other programs runs just fine too

Since the upgrade to MC 12.0.492 I get these lock-ups... which never occurred before with older versions of MC12!

JRiver changed a lot within the functions which are running at exactly that lock-up moment (analyzing music, renaming files/folders) and it is very easy to reproduce - and - I did nothing to update NOD32 to a new version or such - that should say enough. I was a professional programmer myself in my life and I know how easy it is to forget to release a handle, release a lock on a file and such. And as a programmer/analyst I developed a certain sense for a programming problem. Understand me right, this is NOT a problem to blame something to a certain person, it's just a sign that you might be able to find the cause of this problem with looking into the program...

And if I can provide some more details, do some test work, then tell me what to do and which log parts to publish here to find the bug, thanks

Martin

JimH · « **Reply #7 on:** May 10, 2008, 02:05:00 pm »

Uninstall your virus checker to test. There are similar problems in the thread called "Weird Problems". Link in my signature.

globetrotters1 · « **Reply #8 on:** May 10, 2008, 02:22:44 pm »

Now I know where it is:

MC12 locked itself up alone - WITHOUT any other process running! no virus checker, nothing else than the normal O/S processes...

MC12 locks itself up in analyzing 2 files at a time, both with 100%... together with changing some tags of the same files... period... no-go
If I switch to 1 file at a time, no lock-up occurs - probably it occurs too but I couldn't reproduce it with only one file

Enough signs?

Thanks

JimH · « **Reply #9 on:** May 10, 2008, 02:24:46 pm »

What build are you running? MJ12.0.495 is available on the MC12 board?

globetrotters1 · « **Reply #10 on:** May 10, 2008, 02:26:37 pm »

MJ 12.0.492

and I checked your log, you didn't change anything which had to do with these processes...

JimH · « **Reply #11 on:** May 10, 2008, 02:27:26 pm »

It would be nice if you'd try it.

globetrotters1 · « **Reply #12 on:** May 10, 2008, 02:28:42 pm »

ok, Jim, I'll do just that... hold on a while, have to download it and so on... I'll report the results asap

globetrotters1 · « **Reply #13 on:** May 11, 2008, 10:33:54 am »

hello again

yes, with version 12.0.495 I have the same problem - MC12 gets stuck within analyzing music tracks, 2 at a time locks up the program!
and I can lock up the program also with analyzing 1 music track at a time and importing new tracks at the same time

A missing 'commit' on the database perhaps?

and a detail: the status column shows sometimes values of more than 100%, sometimes up to 110%...

hope that helps

JimH · « **Reply #14 on:** May 11, 2008, 10:52:56 am »

Quote from: globetrotters1 on May 11, 2008, 10:33:54 am

hello again

yes, with version 12.0.495 I have the same problem - MC12 gets stuck within analyzing music tracks, 2 at a time locks up the program!
and I can lock up the program also with analyzing 1 music track at a time and importing new tracks at the same time

Can you see if you can duplicate this with a single file type? It could be DirectShow related.

globetrotters1 · « **Reply #15 on:** May 11, 2008, 11:30:23 am »

Processing 1 file at a time works fine and never shows more than 100% - but can also freeze the program when working at the same time with the tags and importing new tracks

Question or new feature request:
Instead of giving the choice of processing more than 1 track at the same time, why not treating the list of tracks to process like a 'playing now' playlist and adding to the end of the list whatever new tracks I want to analyze - today I have to wait until the running process is terminated to start it again with a new batch and that is not very practical for someone who imports thousands of tracks, changes tags and has to analyze them... hope that was understandable

Thanks

JimH · « **Reply #16 on:** May 11, 2008, 12:15:40 pm »

Quote from: globetrotters1 on May 11, 2008, 11:30:23 am

Processing 1 file at a time works fine and never shows more than 100% - but can also freeze the program when working at the same time with the tags and importing new tracks

I understand that something is wrong. I'm just trying to sort out where it is.

I meant to import one file type at a time, not one file at a time. If you're seeing much hesitation doing either of those, then something is clearly wrong.

But it could be:
1. Virus checker
2. DirectShow filter
3. Network or drive related

So, if you can, please test conditions that eliminate each of these.

globetrotters1 · « **Reply #17 on:** May 11, 2008, 01:20:46 pm »

Jim,

1) I meant that if you choose within 'Analyze Audio' window 'Process 1 file at a time' then everything works as before with version 12.0.456... if you choose 'Process 2 files at a time' then it gets stuck often (but not always)

2) I processed a batch of 200 mp3 files and it got stuck after 6, next try after 78, next try after 200... so not always at the same spot

3) I somehow doubt that it's the virus checker (as I uninstalled it for these tests

)

4) I also doubt a bit that it's drive related, as I use this system since version 12.0.200 or such... and it always worked flawlessly! All backup processes work very fast and without any troubles whatsoever. And no flaws with any other processes. I use a 2TB RAID6 array for classical music, a 2TB RAID6 array for modern music and a M/B with a dual CPU and enough memory (4GB) under Win XP Pro.

5) I cannot determine if it could be DirectShow filter related, but as you re-wrote exactly these function, my programmers' 'nose' so to speak tells me that someone just forgot something (which is only human, we all know that)

If you need more info or test work, please tell me what to do or what to produce

Martin

globetrotters1 · « **Reply #18 on:** May 11, 2008, 01:43:54 pm »

and do you want me to start a new thread with my suggestion (see above)?

JimH · « **Reply #19 on:** May 11, 2008, 01:47:40 pm »

A new thread isn't necessary.

Try eliminating the RAID drives as a possible issue. Try a local library.

I appreciate your guesses on programmers noses, but facts are more useful.

Try getting a log of one of the pauses. You can mail it to matt at jriver with a link to this thread.

Thanks for your patience.

globetrotters1 · « **Reply #20 on:** May 11, 2008, 02:08:13 pm »

wow, lol, you ask for a lot of work - anyway, I try to create a new library with just several hundred music tracks on a drive which is not in any RAID array

but please be a bit patient with me, it's not the only thing I do in my life

I'll send the documents to matt

PS: and don't feel insulted about my remark with the programmers' nose - I know that you Americans react sometimes not the same way as we Europeans do when it comes to such side-remarks - no insult whatsoever intended

globetrotters1 · « **Reply #21 on:** May 11, 2008, 02:34:01 pm »

I created a database with just 450 songs, imported some new ones (3 albums) and ran an analyze job with 2 tracks at the same time

Twice it reported something of more than 100%, but it didn't get stuck - I try it with a lot more

My normal music database has right now 121'000 tracks to maintain and I suppose that can have an influence on update speed - right?

Anyway, I'm still busy with tests...

JimH · « **Reply #22 on:** May 11, 2008, 03:02:28 pm »

Quote from: globetrotters1 on May 11, 2008, 02:08:13 pm

PS: and don't feel insulted about my remark with the programmers' nose - I know that you Americans react sometimes not the same way as we Europeans do when it comes to such side-remarks - no insult whatsoever intended

Thanks. I'm not insulted. We've been down this path hundreds of times. Sometimes it's our problem. Often it isn't. Facts help. Opinion can get in the way. These problems all start out with some form of "This is the only application I'm having trouble with." or "It didn't happen with version 4.0.0." Sometimes that's the difference, but often it isn't.

What you may have seen with the local test is that the file access keeps up better. I know you've said you're not testing with a virus checker in place, but anything that steps in between MC and the file access will slow things down. The same is true for access to the registry and writing log files.

The size of the library shouldn't be a factor.

I do think we're getting closer to knowing where the problem is.

globetrotters1 · « **Reply #23 on:** May 11, 2008, 05:19:56 pm »

Sure, I understand all that and have experience with that kind of problem. Although I also know that a certain 'intuition' or let's call it 'nose' comes with this kind of work in a professional environment and (my humble opinion) helps a lot in daily life... anyway, let's move this kind of discussion to a private email discussion if necessary...

I'm just interested in knowing how to avoid that kind of trouble I have...

It's interesting that you mention that the size of the library shouldn't be a factor. As I have now 121'000 music tracks online and switching from Artist view to Genre view lets my dual-CPU system 'think' for something like 20-25 seconds until it starts to paint the window (and within this time it is totally unresponsive!). I remember the time with something like 10'000 tracks, there it was instantaneously. So I suppose the library size has some impact on processing speed.

Anyway, I have to install an additional local hard disk. My system disk is very fast but too small for a library of several thousand tracks and just meant for the O/S and the programs. Just 400 music tracks or so won't do it. So, you see, I have something to do to make these tests possible outside of the RAID arrays... I get back to you as soon as I have that setup ready

Thanks for your patience and kind help, which is as always very appreciated!

JimH · « **Reply #24 on:** May 11, 2008, 06:14:18 pm »

You're welcome.

Quote from: globetrotters1 on May 11, 2008, 05:19:56 pm

It's interesting that you mention that the size of the library shouldn't be a factor. As I have now 121'000 music tracks online and switching from Artist view to Genre view lets my dual-CPU system 'think' for something like 20-25 seconds until it starts to paint the window (and within this time it is totally unresponsive!).

Test it locally and you can be sure you're right. My guess is that it is something else.

Matt spent several days last week working on speed. We were testing with a library of 320,000 files. The speed of changing from the Start Page to Audio Panes went from about 50 seconds down to less than 5. I've tested the same library myself.

I think you could just make a copy of your library files on your local machine, make a new library and use these files, and see what happens.

BTW, have you made any "special" settings in Windows to try to raise MC's priority? If so, reverse them.

Matt · « **Reply #25 on:** May 12, 2008, 08:52:54 am »

I think there's a problem when analyzing more than one file at a time. This feature was added just a build or two back.

Someone else reported a dead-lock with multiple analyzes running concurrently. We'll take a close look today and let you know what we find.

INTERACT FORUM

Author Topic: MC 12 close to freeze system (Read 4719 times)