BTW: You are right, I found there is a huge performance leak because of rebuilding of full-text search index that takes half an hour on my DB while after optimization it takes only 2 minutes!

Fixed as http://www.ventismedia.com/mantis/view.php?id=7316

Thanks!

[1376] 3188 DB open SQL: SELECT WebCommercial, WebCopyright, WebFilepage, WebArtist, WebSource, WebRadio, WebPayment, WebPublisher, WebUser, PreviewStartTime, PreviewLength, CacheName, PreviewName, Copyright, Encoder, ISRC, InitialKey, Language, OrigLyricist, ParentalRating,PreGap, PostGap, TotalSamples, GaplessBytes, SignType, SignPart1, SignPart2, SignPart3, SignPart4, ContainerType, StreamCount, StreamInfo FROM Songs WHERE ID = 10 
[1376] 3188 DB lock finished, took 627714.
[1376] 3188 DB exec SQL: INSERT INTO SongsText (rowid,artist,album,albumartist,songtitle,genre,songpath,author,lyricist,conductor,groupdesc,subtitle,lyrics,comment,custom1,custom2,custom3,custom4,custom5,origartist,origtitle,origlyricist,publisher,encoder,copyright,mood,tempo,occasion,quality,involvedpeople) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) 
[1376] 3188 DB lock successful.
[1376] 3188 DB lock finished, took 97554533.

I only wanted to say that if you see instant:
[code]

[1376] 3188 DB open SQL: SELECT WebCommercial, WebCopyright, WebFilepage, WebArtist, WebSource, WebRadio, WebPayment, WebPublisher, WebUser, PreviewStartTime, PreviewLength, CacheName, PreviewName, Copyright, Encoder, ISRC, InitialKey, Language, OrigLyricist, ParentalRating,PreGap, PostGap, TotalSamples, GaplessBytes, SignType, SignPart1, SignPart2, SignPart3, SignPart4, ContainerType, StreamCount, StreamInfo FROM Songs WHERE ID = 10
[1376] 3188 DB lock finished, took 627714.
[1376] 3188 DB exec SQL: INSERT INTO SongsText (rowid,artist,album,albumartist,songtitle,genre,songpath,author,lyricist,conductor,groupdesc,subtitle,lyrics,comment,custom1,custom2,custom3,custom4,custom5,origartist,origtitle,origlyricist,publisher,encoder,copyright,mood,tempo,occasion,quality,involvedpeople) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
[1376] 3188 DB lock successful.
[1376] 3188 DB lock finished, took 97554533.
[/code]

Then it is the full-text search index rebuilding and it is most probably the cause.
Solution would be to add new checkbox [x] Rebuild full-text search index and remove the action from [x] Optimize database (complete)
Reported as: http://www.ventismedia.com/mantis/view.php?id=7315

This seems to be the same issue I reported [url=http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=54614]here[/url] although perhaps I reported it differently??
Same result though. A full optimization never seems to end, or if I left it long enough i.e. overnight and half the next day it finished, but doing it again after completion doesn't get any faster it goes into another laboriously long hour after hour process.
My database was checked by the SQL check plugin and had no errors. I clean installed MM4 1345 and 1346 and still got the same results. The database was fully optimized by MM3 prior to installing MM4 and took around 3 minutes!

My data base is around 430Mb. While running the MM4 optimization the MM-DB was 436 prior to starting. The optimization ran through once and the MM.DB file went to 408Mb in approx. 3-5 minute but then started to disappear and reappear on and off for another 35 minutes before I got fed up ended the MM4 process to get out of the programme. So the database was compacted but then the optimization went in another sort of process. I watched DBGVIEW and the process was optimizing individual files one after the other and I presume was gong to do this right through the 104k+ tracks ??

Where is the SQL number asked for by Ludek in the log I can't see it anywhere (if thats what he is asking for) or what is he asking for there in the previous post?

When running the full optimization in MM3 the Journal files rebuilds 1-1/2 times and is complete inside 5 minutes.

Full optimization of ~ 37000 tracks (audio) (180GB) takes about 7-8 minutes here. (Windows XP, Athlon XP 2500+, 1024 MB ram)

[quote="robojock"]I gave it a try :( my database is 570mb big and its been running now for about 6 hours and still counting :([/quote]

And what SQL do you see in DbgView ?

I gave it a try :( my database is 570mb big and its been running now for about 6 hours and still counting :(

I'll try that to see what's going on. I definitely ran the full optimization in 3.1 and it didn't take this long.

[quote="MDominik13"]No, I didn't see the tooltip. Was it in MM3 as well? As Lowlander pointed out, it never took this long for me in MM3. Pretty much the same database took several minutes but not hours.[/quote]


When complete optimizing is performed then there is re-created also the full-text search index for each song, this was added in MM 3.1 and can take quite a lot of time.
You can run DbgView and if you will see instant "INSERT INTO SongText .... " SQL queries then it is the full-text search index recreating.

No, I didn't see the tooltip. Was it in MM3 as well? As Lowlander pointed out, it never took this long for me in MM3. Pretty much the same database took several minutes but not hours.

But it never took this long in MM3, so it does seem something has changed.

[quote="MDominik13"]Yeah, even though it finally completed, there's definitely something wrong here.[/quote]
[quote="vpsaxman"]Last time I did the complete optimization it took almost 4 hours...[/quote]
[quote="Dreadlau"]Wow 1h seems excessively long.[/quote]

I don't know, did you see the tooltip?
[img]http://img708.imageshack.us/img708/3618/hours.png[/img]

Yeah, even though it finally completed, there's definitely something wrong here.

Last time I did the complete optimization it took almost 4 hours...

Wow 1h seems excessively long.

Guess patience is a virtue, huh? It took just over 1 hour to complete.