MediaMonkey forum

Using 1148

I've backed off from working my library until the AAC and iphone issues were resolved a bit...

Upon starting to maintain my library again, I am finding the auto-tag functionality exceedingly slow...

For example:

When I initiate the auto-tag MM essentially locks up for up to a minute or more while it is doing "something"- this, for just one album, to simply correct the tracks....nothing else selected...this is PEGGING my CPU..what is happening here?

Something is definitely going on differently here...are there issues accesssing amazon?..is something different here?

All this BEFORE the "files to be tagged indicator" appears in the main window and the actual "tagging" seems to occur. Which then seems very, very much slower than previous MM incarnations.

This is making library maintenence almost impossible to accomplish in any reasonable timeframe.....it took over 5 minutes to auto tag one double album with tracks and art...something that previously might have taken 1 max.

Any help in understanding this would be appreciated. Need help on this.

Really strange, does anyone else seen this?

I cannot replicate, I can tag an album by using Auto-tag from Web in a several seconds despite the fact I've maintained library or not.

Could you generate a debug log?
Does persit this issue after re-scanning your DB?
Or if you move your old DB and re-scan for creating the new one and see if it helps.
Which OS/SPn do you use?

Thx.

Thanks for the reply Ludek.

I wouldn't call it strange. Extremely annoying maybe.

The behavior is not consistent. Yesterday for example, about 10% of the work I did had no problem with speed of execution. when the odd behavior occurs during the auto-tag process it is always after things are "downloaded" yet before the "tagging files" initiates.

The lockups occured with new as well as old files.

Dozens of errors were generated and emailed. Pretty much any change tagging wise I did would create a problem for MM...this is the most unstable I have ever seen it as a matter of fact. Even ripping new CD's created errors and lockups.

I am using network storage...and am somewhat suspicious of MM and function with these drives...but the fact that "sometimes" there is NO problem makes this hard to understand.

Rescanning....can I ask why you would suggest this? I have not rescanned for several releases. My library is very large and scanning is not a trivial matter.

I will rescan when possible and update.

Ok, I removed db and made a clean scan of all files. Scan took 8hrs....

Closed MM and started Dbgview.

Opened MM and randomly picked an artist and chose an album at random(I have NEVER actually listened to this album...lol).

Initiated autotag.

Here is log http://home.pacbell.net/cmx/autotagproblem.LOG

Note line 1154 time 12:45:22...this is where MM just locked up....pretty much freezing my computer...

CPU remained at max until 12:46:04....then process completed....

Total time for one album about two minutes.

This is what has been going on...although there were times when it would complete the same process in about 20 seconds total which has been normal in the past.

I am curious if my NAS has something to do with this.

There seems to be confusion and problems associated with NAS and mapped drives vs UNC..(I used UNC for this scan). I have been unable to find any definitive explaination or recomendation from the developers on this matter. Could this be formally addresssed and explained?

Thanks for any help with this. This release of MM has been very disappointing. From ripping to tagging to simply browsing my library....MM 1148 has been VERY slow and unstable.

Please advise if there is anything else I could provide that could help resolve these issues.

Update....

As an experiment I created 2 new databases consisting of only the Celine Dion folder used in the above example.

I created a unique database using a mapped drive locator and a unique database using UNC locator.

When autotagging the same album used above...there was no "lockup" the whole process completed in less than 30 seconds...for BOTH databases.

I then loaded the original complete database used above and I again experienced the same "lockup" described above for about 50 seconds in the same exact place....

?????????????????????????????????????????????

Update..........

Upon further testing..bizarre, BUT absolutely recreatable, consistent behavior.



Using the complete new 1148 scan of my complete library:

1.) I opened Artist node and selected the Celine Dion used above.

a) Upon autotagging the same 50-60 second delay DOES OCCUR as described and logged above.


2.) I opened the Location node and selected the same Celine Dion album. (Note here that this is with the Artist node "closed" or minimized".)

a) Upon auto tagging the delay DOES NOT OCCUR, tagging completed quickly and reasonably.


3.) If I simply open the Artist node in the Nav Pane and then use the Location node to actually select the album for autotagging....

a) Upon autotagging the delay DOES OCCUR.


So...you see the confusion that could occur while working. I did not try any other library access combinations for this example.....wanted to keep it simple and clear.

Sorry Ludek, using windows XP SP2. Files are on Buffalo Terastation NAS box...the actual file structure of which I am unsure.

It seems as though the size of my library(this due to the experiment with the single folder DB) and fact that the artist node is expanded creates this problem. Yes, now I agree...I would call that "strange" from a user perspective.


Thanks for any acknowledgement and help with this matter.

ok, thank you. From the log it looks like a problem of a big DB. We are looking into it.
Btw. How Big is your DB, 100k tracks?, 200k tracks?
Do you think that you could send us your DB for testing?

Thanks for the response Ludek.

121k tracks.

I am glad this more or less "defined" problem came up and seems to be realated to the DB size. There are many everyday instances where MM momentarily "lockups" or be comes "non-responsive" that seem to be related to the size of the DB. Hopefully this will help address these problems as well.

One thing that stands out from a user perspective is the lack of indication that a process is proceeding. One very notable example of this when searching. This noticable yet inconsistent lag that is not also occurs when doing other tagging processes such as renaming or dragging and dropping tracks between folders nodes.

There are two distinct types...

The type where the CPU is maxed and there is evidently a real problem.

The type where the CPU is shared, yet there is quite a lag with no indication that MM is proceeding other than CPU activity...searching is an example of this.


Thanks for help with this. Please advise if there is anything else I could do to help, especially with large database issues.


***email sent to support with link to DB upload.