[quote="Lowlander"]MM3 didn't allow to cancel and would also fail on occasion for me. I normally would run the DB_Audit addon before optimizing the database to ensure it would run.[/quote]

Yes correct, with MM3 the option to cancel during the process is greyed out. With MM4 it isn't but that doesn't matter it does seem to be deactivated but it was only because the whole system locked up and wasn't obviously going anywhere that I realised once in this function there is no sensible way out other than to use task manager and stop the process shutting down MM thereby losing any other information that may not have been saved up to that point.
I have sent in the debug log with several images quiet a while ago now showing how during the lockup my play count went from "0" to "054" and the particular track now can't be played.
I haven't heard back yet.

MM3 didn't allow to cancel and would also fail on occasion for me. I normally would run the DB_Audit addon before optimizing the database to ensure it would run.

[quote="Peke"]Opening Support ticket and attaching compresses debug log should help show us what is going on and where slowdown is.

Also Maintain Library in MM3 before Import in MM4 could help.[/quote]


Hi Peke
I will do a debug and send it in today

My MM3 library was "maintained" before import into MM4, as I said in MM3 I can run full maintain in about 2-4 minutes because I do this so regularly.
I will start a new topic with my slowdown issues


*****EDITED***** DebugView log sent today.

I did optimize mine before the upgrade which may be why mine appears to be running faster. Biggest difference I've noticed is in autoplaylists... they run a lot faster.

Opening Support ticket and attaching compresses debug log should help show us what is going on and where slowdown is.

Also Maintain Library in MM3 before Import in MM4 could help.

Quick worked for me as well. My database contains 20,000+ tracks and is about 250MB. I haven't noticed any performance issues with 4.0 (so far it seems faster). I'm a DBA so I like to routinely run the full optimization anyway... that's when I noticed the issue.

Just to re-cap...
My MM3 library of over 100k tracks took a couple of minutes for Full File Maintenance to happen. I kept on top of this.
After installing MM4 and importing the MM3 data I noticed the performance was very sluggish so I ran file maintenance. This ran overnight for over 8 hours but never completed.
I could not cancel (as stated) and make an orderly exit from the function. I had to go to Task Manager and end the process entirely. All parts of MM were locked up.
I have since run File Maintenance (quick) several times with no problem and last night ran the full optimisation which completed in around 7 hours.

The MM programme is still very sluggish, so at least I have confirmed this is not due to the database requiring compacting so must be another issue.

My buttons are not grayed out but they don't work either. Usually, disabling will gray out the buttons to let you know they won't function.

I like the idea of a status indicator for the optimization. Again, it will only work if it's run in steps. I'm not an expert in SQLite so I don't know if there is one command to optimize a database but I'm sure it could be done individually. I'm going to submit a feature request for the optimization status (unless you'd like to?).

[quote="MDominik13"]If that's the case, the buttons (Cancel and OK) should be disabled once the process starts.[/quote]
They are/should be? Are they not for you?

[quote="MDominik13"]however, if the process is being run in individual steps (i.e. rebuilding indexes one at a time vs. one giant script), it should be possible to cancel the process.[/quote]
If the process is compartmentalized and can safely be aborted (in a similar manner to when you cancel a tagging option in that it finishes what it's doing for that specific task, then breaks the chain before moving to the next one), then I don't see why not. I'm not database expert though, so... yeah. If it is ran in parts, it might be nice if MM displayed a progress bar, displaying at what stage it's at "Cleaning up _____", etc. so that it at least appears MM is doing something and not just locked up (may also help identify when/if it actually is locked up during a Maintain Library).

I wasn't aware that the cancel button wasn't intended for you to cancel the process. If that's the case, the buttons (Cancel and OK) should be disabled once the process starts. With regards to being able to cancel the process, I know it's hard to stop a database process once it has started (in some cases not at all); however, if the process is being run in individual steps (i.e. rebuilding indexes one at a time vs. one giant script), it should be possible to cancel the process.

There has never been a cancel button to cancel out of the optimization once it's started though, and I think that is by design. The Cancel button present allows you to exit the window where you choose what optimizations are to be performed, while no "cancel" is offered to abort the optimization because I imagine it would be hard on a database to try and stop at some point in the middle of the process.

I think it's both. There appears to be a bug in the optimization function (which works in 3) where it gets stuck in a loop (I think). Part of the bug is that the cancel button doesn't work (I'm guessing because of the loop).

So this is an issue with performance then, and not necessarily that this action disables control over the UI and such, right?

I had the same problem. This isn't the same as in 3.0. I watched the database/journal files during the run and it appeared to get stuck in a loop at one point. Initially, the journal file ran up to almost the same size as the database (mine is about 250MB). Then, the journal dropped to 0 and the database shrunk by about 20MB. After that, the journal kept building up to 15-20KB and would zero out over and over again. I let it run for about 30 minutes but it never stopped doing this so I eventually had to kill it in thee task manager.

It has always been like this.