Newbie question… I am a relatively new user, and had been using the program for a little while now and then notice that a file with the name of picard.exe.log has grown to be 3.7 GB in size! What is this file for? And can I delete it?
Thanks
After seeing my Windows 10 update fail a couple times, I found out it was due to a lack of available space on C:. My research eventually led me to the users\name\appdata\roaming\musicbrainz folder, where I found the same picard.exe.log file markinhfx mentions in his original post. However, my log file was 53GB.
As a developer myself, I understand that logs are necessary, but you guys need to implement some sort of cleanup function or at least limit the size of the log by default. 53GB is ridiculous.
Thank you for writing a cool product.
Wow - what on earth can fill a log like that? My six month old install is 156KB of log file.
Made me laugh looking inside as it keeps repeating an “error” of:
I: 11:56:20 Plugin directory ‘D:\Program Files (x86)\MusicBrainz Picard\plugins’ doesn’t exist
Errr… yeah. The folder doesn’t exist. Plugins shouldn’t be in there anyway as mine seem to be in %APPDATA%\Musicbrainz\Picard\Plugins\ and seem to work fine.
So I have a log, but all it logs is Picard’s own daft mistake. And clearly no one at Picard is looking at the logs or daft mistakes like that one would have been solved.
But getting to 53GB with a TEXT file is quite an effort. Must be pretty horrendous trying to use Picard in that state. Must be really comical as to the speed difference in Picard once you deleted that thing.
Kinda worrying that there is no mention in the OPTIONS or the INI file about this log. Must be some way of killing it.
It’s actually on a media server. I was experimenting with tools that could help me organize files and MusicBrainz was one that I read about. I haven’t used the application in over a year so I’m not sure what was in the log file. It was pretty comical, though. lol
This log file isn’t managed by Picard itself. What’s in it ?
If one has debug mode enabled, Picard can output a lot of info to stderr though. And if the output is redirected to a file it will grow without limits. But that’s not the app by itself (which has internal log in recent versions, limited in size, and optionnally saveable).
1 Like
This is a log file managed by Picard. My one holds a handful of “server not found” type errors from various MB lookups. The have time stamps but not dates making it hard to tell how old it is.
Random example below:
E: 12:23:17 u’Error downloading https://musicbrainz.org:443/ws/2/recording/f0cc2da9-d757-419a-9ca7-6da2caef9256?inc=artist-credits+artists+aliases - server replied: Not Found’
E: 12:23:43 Network request error for https://musicbrainz.org:443/ws/2/recording/f0cc2da9-d757-419a-9ca7-6da2caef9256?inc=artist-credits+artists+aliases: Error downloading https://musicbrainz.org:443/ws/2/recording/f0cc2da9-d757-419a-9ca7-6da2caef9256?inc=artist-credits+artists+aliases - server replied: Not Found (QT code 203, HTTP code 404)
E: 12:23:43 u’Error downloading https://musicbrainz.org:443/ws/2/recording/f0cc2da9-d757-419a-9ca7-6da2caef9256?inc=artist-credits+artists+aliases - server replied: Not Found’
It would still take quite an effort to get that up to multi GB sized file!
Nothing in the options about disabling it. And with a name of picard.exe.log there is nothing else that created it. Also the date stamp of the file changes every time Picard is used on this PC.
Picard application itself doesn’t create this log file: you can ensure this by reading source code at GitHub - metabrainz/picard: MusicBrainz Picard audio file tagger (that’s open source…).
And therefore it will not “manage” nor rotate it.
So i guess it is created by the packaging system, which build packages for Windows, which captures stderr output and store it in this file.
One can safely delete or truncate this log file though, Picard doesn’t need it. Stop Picard, delete the file, start Picard.
Verbosity is very limited in normal mode, but if debug mode is enabled it can grow fast, which may be explain huge sizes some users got.
1 Like
I saw a picard.exe.log file for v1.42, but nothing with v2.0 beta. If this file was created (and appended) by the packager and was allowed to grow out of control, I wonder if that might also be contributing to the slowdown when trying to batch process a large number of files?
1 Like
Yes, that was my thinking, perhaps an explanation for slowdowns reported by windows users. 2.0 is packaged differently.
2 Likes
I thought we were talking about the current Picard and not the beta.
I am only a user and don’t really have time to read through all the source code of an application. I’m not trying to argue, I was just commenting on the log file.
And it really is a Picard log file in Picard’s AppData folder. Documenting a few errors in lookups and other issues within Picard.
Is the “packaging system” in use on every run of Picard? You are making me curious now. If this file is not part of Picard why is is full of so much Picard specific info? It really does look like part of a debug text file.
I was about to attach it to this post, but this forum doesn’t like text files.
Looking at the contents of the log file, it can easily be a contributing towards a small part of this issue. If the artwork being looked up is kicking out errors due to it not being found, these kinds of errors are being written into this log.
I have experienced those “slow” times myself and they are clearly disk related. Especially if lots of artwork is being downloaded and written to the temp folder at the same time. Just need to have a few albums with multi-paged Booklet Artwork being downloaded and Picard will be so busy it will seem like it has frozen to the OS. Just walk away and make a cup of tea and it will sort itself out.
If that artwork was being retrieved at a time of heavy load on the CAA server, there would be more errors going into this log.