On the cause of hangs/crashes


There have been a number of posts in the past about Picard hanging/crashing when attempting to process a large number of files. Suggestions to address this have included breaking up the music files into smaller batches. I have been doing a lot of testing recently of my Classical Extras plugin, which has involved a fair number of writes to the log file. My observation is that Picard will hang if there are an excessive number of writes to the log file (in the order of hundreds of thousands). I have run the same code with and without the logging against the same file sets and it will hang if the logging is turned on and not hang if it is off. This behaviour has occurred identically with various versions of the code, log writes and file sets.
So maybe the cause of hanging with large numbers of files is nothing to do with the main Picard code, but merely a function of the number of log writes. Note that the total size of the log file seems to be irrelevant - it is the number of writes in the current session that seems to be critical.
Has anybody else noticed this? Perhaps someone could run an independent check of my hypothesis? Or better still, fix it?


I experience this issue more often than not. But it happens to me at about 2000 songs. It was the reason I enabled logging. My theory - I am just a novice - was a process is hanging
I see four msvcr90.dll!endthreadex+0x6f processes just spinning. So I increased the priority of these to “above normal” and set picard.exe to “highest” (NOT real-time) and in a few minutes, the app was responsive again. This is the first time i have tried this and I’m sure results will vary - if duplicated at all.
I didn’t know the app was written using python until now so there may be other places to look.
I’ll post any additional results - because it’s bugging me even more now.



@wehavecookies4u, can I ask how long it took to tag those 2000 songs?


Tried that when Picard seemed totally unresponsive and after a few minutes it recovered!


Great. I have times where that hasn’t worked. (or i haven’t given enough time)
Large multi-track mp3’s (oversight) will also cause an issue.
A stop button would be ideal with a message of what track was interrupted.
More baffling is the inconsistent behaviour with the same tracks on two different machines.
i started to set up for a trace dump but a preview update caused some time without the machine. The other machine (both win 10) seems to be banging thru with a few hangs. I started to break up the albums into smaller sets and it runs thru. It starts getting SLOW. Clearing .\AppData\Local\MusicBrainz\Picard\cache\picard and temp seems to fix that.


How do you turn the logging off?


Not sure you can turn it off, but you can make sure that the “debug mode” box is not checked (go to Help->View Error/Debug log).


I do have this same errors, the picard keeps craching by even a very few songs (<10) So if i have had just one cent for each time it have had crached the last couple of days I have got this installed… well I wouldn’t have to work any further this year

Running on kernel 4.13.0-36-generic

When dos this happen, on almost all cover downloads, even if i disable them all and setting it to only use local images.

Running on wait for it, have to reload the app 3 times for this info… version 1.4.2


When you are experiencing crashes, please report them with following details:

  • system used
  • way to reproduce
  • debug log
  • exact conditions leading to the crash, and full console output if any

It is very hard to fix an issue without those informations, a way to reproduce it helps a lot.