Unfortunatelly debug log doesn't always tell exactly where problem occurs. For some reason, your freeze problem doesn't create automatically generated freeze reports and we are looking into this particular problem (EDIT--see: http://www.ventismedia.com/mantis/view.php?id=5676 ). Anyway, although the description of both issues sounds completely different, it's really possible that they were both fixed by the same fix. However, only the next build can show whether it's really so...

Jiri

I see you created an issue about this, http://www.ventismedia.com/mantis/view.php?id=5654. I also see the comment "It looks like it could be a dup of 0005644, let's wait for the next build, whether it fixes the problem" in that issue.

That other issue, 0005644, is described as "It happens to me that MM freezes randomly on a quad-core system. It seems to be almost 100% reproducable on a conversion of MP3 to MP3 using all 4 cores."

The bug I have been reporting is not on a quad-core system, has nothing to do with conversion and happens when editing flac and wma lossless files. So the comments "...looks like it could be a dup..." and "...let's wait for the next build, whether it fixes the problem..." are, well, I don't know. Did you look at and use the debug log I produced?

1247, Vista

MediaMonkey hung again while adding album art, this time to WMA Lossless tracks. This time I was indeed using the debug version, however DebugView had not been started. DebugView was started after MM was hung and no messages was being emitted then.

But, I did manage to get a debug log of a similar problem. I restarted MM, and DebugView, and tried to replicate the problem. This time MM succeeded adding the three album art jpgs. But, later on I re-ordered the album art, MM hung again and this time I captured the log:

http://rapidshare.com/files/235369393/1247.froze.reorder_art.LOG.html

The scenario was something like this:
1- started MM 1247
2- played the album (i.e. it was added to Now Playing)
3- analyzed volume
4- added album art
[until this point MM was ok, analyzing volume had completed, album art adding was completed, the album was still playing]
5- right-click Album Art, select Edit Album Art Properties
6- re-ordered the images by moving the third/bottom image to the first/top position, click OK
7a- dialog box starts to go away, but doesn't; MM fails to re-paint the areas the dialog box has occluded (only the borders between the various MM panes get re-painted)
7b- status bar updates and says "12 tracks to be tagged"
8- MM hangs
9- the last few seconds of the song that was playing plays over and over

The tracks are WMA Lossless, album art stored in the tracks. The symptoms are EXACTLY the same as when MM hangs with other types of encoded files, e.g. flac files. Again, it seems to be a synchronization issue internally in MM - after clicking the OK button, MM fails to get repainted, the status bar gets updated with "nn tarcks to be tagged", but MM then hangs.

Note, the log file posted is not complete from starting MM; I did a Clear Display at some point after step 4 above

@fourteen
You must misunderstand me and I apologize for that (English is not my native language).

I was actually thinking like Rusty wrote as like him as I was unable to replicate your issue.

So as developer I'm hoping that you will be able to replicate and find error again so that we can work on fix immediately, but as an regular user of MediaMonkey I'm hoping that error will not come again and you can continue using MediaMonkey without worrying of an possible bug.

No matter what the results are we are more than interesting to get to bottom of this issue.

[quote="Peke"]Than it would be more helpful to send us debug log as described at viewtopic.php?f=6&t=341 using latest version 1244.[/quote]
[quote="Peke"]Then continue using Debug Version Until you get error or even better do not get error but MM working correctly.[/quote]
Nice...
From your comments it sounds like you are not interested in hearing about any problems with your software unless it is accompanied by a debug log. And if it is not possible to generate such a log (as I reported) then you are apparently not interested in hearing about the problem(s).

Forteen,

If you don't mind, please use the debug version. Hopefully eventually the bug will crop up and we'll be able to get to the bottom of it.

-Rusty

Then continue using Debug Version Until you get error or even better do not get error but MM working correctly.

[quote="fourteen"]...I then installed the debug version of 1236 to get a log but using the debug version, I could then no longer replicate it.[/quote]

As stated earlier, I was unable to replicate it using the debug version. Then I was only able to replicate it using the non-debug version, and consistently so.

Than it would be more helpful to send us debug log as described at http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=341 using latest version 1244.

Rusty,

Thanks for following up on this.

1- All my tracks are local, on the local computer, not on the network.
2- I am fairly certain MediaMonkey completely froze, and it was not a slowdown. As in other cases I have reported when MediaMonkey has frozen, the dialog box you just clicked OK in does not "completely go away". MediaMonkey should repaint the areas the dialog box occluded, but it does not - only the borders between the various panes/areas (e.g. the tree and tracks listing) get repainted. And to answer your question, the progress bar did not progress.

To me it indicates there is a synchronization issue internally in MediaMonkey, which is scary.

Reading http://www.ventismedia.com/mantis/view.php?id=5607, if the tagging occurs in separate threads, presumably separate from the main/UI thread of MediaMonkey, then MediaMonkey should still be responsive regardless of the number of threads, shouldn't it?

Again, in my case, the one reported above, it was not on the network and it was not a slowdown, it was a freeze.

Fourteen,

i think I was able to replicate the problem by performing the Album Art tagging operations over a network. I found, though, that tagging still proceeded, albeit at an extremely slow pace.

Tracked at: http://www.ventismedia.com/mantis/view.php?id=5607

two questions to help me understand whether this is the same issue:
1) are your tracks that trigger the problem on a network?
2) if you watch the progress bar, as tagging proceeds, do you notice a slowdown? or is it just a sudden freeze?

Thx.

-Rusty

[quote="fourteen"][quote="rusty"]Can you confirm that:
-The bug is limited to WMA Lossless tracks
[/quote]
I believe (I am not 100% sure) I have had this happen with flac files as well.
[/quote]

Now, I am 100% sure it happens/can happen with flac files as well.
It did the other day, and again just now.

Just now, I was editing three different albums "simultaneously". I had copied/pasted in two album art jpgs into album#1, clicked ok, and off MediaMonkey went processing the tracks. Then I copied/pasted two jpgs to album#2, clicked ok and off MediaMonkey went processing those tracks (simultaneously with the tracks in album#1). Then I copied/pasted two jpgs to album#3, clicked ok and off MediaMonkey went processing those tracks (simultaneously with the tracks in album#1 and album #2). Then I realized I had marked one of the jpgs incorrectly in album#3 and right-clicked and "Edit Album Art Properties" and changed the image type on one of those jpgs, and clicked ok. Then MediaMonkey froze and became unresponsive.

After killing MediaMonkey, and restarting it, I could see that it had not completely finished processing any of those albums - the art was different for first and last tracks of each of the albums.

forteen,

I've attempted to replicated this numerous times and can't (Until today I was attempting to replicate via folder.jpg links, however, even with embedded tags, I cannot replicate). Hopefully you'll be able to replicate the issue with the debug build once, so that we can get a log of this.

Thanks.

-Rusty

[quote="rusty"]Can you confirm that:
-The bug is limited to WMA Lossless tracks
[/quote]
I believe (I am not 100% sure) I have had this happen with flac files as well. However, it happens very often with wma lossless files. It happens so often that I have started encoding some of my files in flac now to avoid the problem of having to kill MM, re-start it and trying to remember which album I was working on, find the art in the filesystem, copy and paste etc.

[quote]
-The tracks in the album are all contained within a single folder
[/quote]
Yes. I always store all tracks belong to one album in one folder.

[quote]
-The bug occurs with tracks that have only a single Album Art Image stored to folder.jpg which is in the same folder as the tracks
[/quote]
Huh?
All my art is stored in tags. I am not storing nor attempting to store any art as folder.jpg.
So the answer is no.

[quote]
-When you tag the new Album Art, the artwork is saved only to folder.jpg (i.e. the 'save to tag' option is unchecked)
[/quote]
No, see above.

[quote]
fyi, the next build (1241 or later) will fix a related issue ( http://www.ventismedia.com/mantis/view.php?id=5543 ) in which if folder.jpg is pasted, it doesn't properly replace the previous instance of folder.jpg in the directory. Since the replication steps for your bug involve replacing folder.jpg with a new folder.jpg, I'm hoping that this fix may resolve your issue.
[/quote]
My feeling is that that issue is not related at all since folder.jpg does not come into play here.

My feeling is that it is some kind of synchronization issue. As I have reported several times, after the images have been pasted into the dialog box and you click ok, the "status bar" in MediaMonkey updates to something like "11 tracks to be tagged" and the dialog box "attempts to away" - MediaMonkey attempts to repaint itself (the areas the dialog box occluded) but it hangs.
Have you tried to replicate this using wma lossless files following the steps I have reported?

Fourteen,

I still can't replicate in 1140. Can you confirm that:
-The bug is limited to WMA Lossless tracks
-The tracks in the album are all contained within a single folder
-The bug occurs with tracks that have only a single Album Art Image stored to folder.jpg which is in the same folder as the tracks
-When you tag the new Album Art, the artwork is saved only to folder.jpg (i.e. the 'save to tag' option is unchecked)

fyi, the next build (1241 or later) will fix a related issue ( http://www.ventismedia.com/mantis/view.php?id=5543 ) in which if folder.jpg is pasted, it doesn't properly replace the previous instance of folder.jpg in the directory. Since the replication steps for your bug involve replacing folder.jpg with a new folder.jpg, I'm hoping that this fix may resolve your issue.

Thx.

-Rusty