It is unlikely that the next update will fix this as long as we don’t know the cause for the crash and nobody else can reproduce it.
If you could provide the log output when Picard gets started from command prompt and you then reproduce the crash would likely help a lot.
Also it is yet unclear to me whether it always crashes on the same file, or if it is always the 5th (?) no matter what files you save. Does it matter where the files are located (e.g. local vs. network drive)?
It does not matter which album, always after the 5 song. I have no network drive, only local drives.
Yes Picard. ini. I habe delete it, trash is empty
Thanks for the screenshot from the console, but actually this doesn’t look like that this was taken in a case where Picard crashed after saving the fifth song. There would be much more output there. This rather looks like your previous problem where Picard did not start at all, but as I understood that’s working again.
In case the crashes on start re-appeared please try the installer I linked to at
With some luck this also fixes your saving after fifth song issue. If not I really need that debug output in order to get some clues for this issue.
And Crash
I’m also an end user, but puzzles like this get me interested. The fact that it always is 5 tracks that get tagged is strange. Why is this happening to you and not to other people?
Are these music files you ripped yourself? Or from another source? What are they - MP3, FLAC, WMA, AAC?
Daft question - if you have only half an album on the right with tracks 6 to 20 matched does that mean only tracks 6,7,8,9,10 get tagged and then it locks up again?
Are you also renaming and moving files, or just updating tags?
Please turn the debug logging back on. That should let the dev get a better idea of why this breaks over in such a regular place on your computer.
This is the kind of puzzle that I’d offer to setup a Window 10 PC to match yours if needed. What language are you running with? Is that German \ Germany or another German speaking country?
There have been 7 requests so far for you to provide debug logs. If you really want help with this issue, I suggest the first thing you should do next is to actually provide those logs. Screenshots and all are great, but they don’t give any information about what’s happening “under the hood”. The logs do. If you want help, you should provide the logs.
here ist the debug protokoll
F:\>"F:\MusicBrainz Picard\picard.exe" -d
F:\>D: 07:44:24,645 tagger.__init__:196: Starting Picard from 'F:\\MusicBrainz Picard\\picard\\tagger.pyc'
D: 07:44:24,645 tagger.__init__:198: Platform: Windows-10-10.0.17763-SP0 CPython 3.7.1
D: 07:44:24,647 tagger.__init__:199: Versions: Picard 2.1.3.dev1 (python3.7.1_20190201205244), Python 3.7.1, PyQt 5.11.3, Qt 5.11.2, Mutagen 1.41.1, Discid discid 1.1.1, libdiscid 0.6.2, astrcmp Python, SSL OpenSSL 1.0.2k 26 Jan 2017
D: 07:44:24,647 tagger.__init__:200: Configuration file path: 'C:/Users/Michael/AppData/Roaming/MusicBrainz/Picard.ini'
D: 07:44:24,647 tagger.__init__:202: User directory: 'C:\\Users\\Michael\\AppData\\Local\\MusicBrainz\\Picard'
D: 07:44:24,689 i18n.setup_gettext:55: unsupported locale setting
D: 07:44:24,690 i18n.setup_gettext:71: Using locale 'de_DE.cp1252'
D: 07:44:24,690 i18n.setup_gettext:73: Loading gettext translation, localedir='F:\\MusicBrainz Picard\\locale'
D: 07:44:24,705 i18n.setup_gettext:77: Loading gettext translation (picard-countries), localedir='F:\\MusicBrainz Picard\\locale'
D: 07:44:24,716 i18n.setup_gettext:80: Loading gettext translation (picard-attributes), localedir='F:\\MusicBrainz Picard\\locale'
D: 07:44:24,729 i18n.setup_gettext:103: _ = <bound method GNUTranslations.gettext of <gettext.GNUTranslations object at 0x00000239129E4668>>
D: 07:44:24,729 i18n.setup_gettext:104: N_ = <function <lambda> at 0x0000023912364D90>
D: 07:44:24,729 i18n.setup_gettext:105: ngettext = <bound method GNUTranslations.ngettext of <gettext.GNUTranslations object at 0x00000239129E4668>>
D: 07:44:24,730 i18n.setup_gettext:106: gettext_countries = <bound method GNUTranslations.gettext of <gettext.GNUTranslations object at 0x00000239129F1A20>>
D: 07:44:24,730 i18n.setup_gettext:107: gettext_attributes = <bound method GNUTranslations.gettext of <gettext.GNUTranslations object at 0x0000023912A06748>>
D: 07:44:24,807 webservice.set_cache:293: NetworkDiskCache dir: 'C:/Users/Michael/AppData/Local/MusicBrainz/Picard/cache/picard/' size: 7638780 / 104857600
I: 07:44:24,810 plugin.load_plugindir:267: Plugin directory 'F:\\MusicBrainz Picard\\plugins' doesn't exist
D: 07:44:24,811 plugin.load_plugindir:292: Looking for plugins in directory 'C:\\Users\\Michael\\AppData\\Local\\MusicBrainz\\Picard\\plugins', 0 names found
D: 07:44:25,692 tagger.main:857: Looking for Qt locale de_DE in F:/MusicBrainz Picard/PyQt5/Qt/translations
D: 07:44:25,779 browser.browser.start:69: Starting the browser integration (127.0.0.1:8000)
D: 07:44:25,862 ui.mainwindow.auto_update_check:1139: Skipping start-up check for program updates. Today: 2019-02-15, Last check: 2019-02-09 (Check interval: 7 days), Update level: 2 (dev)
Good Morning,
I would like to have sent the debugg protocol earlier, but it had not worked so far. Now it works. see above
hello, can you read something in the protocol?
Thanks for the details, but unfortunately this log does not help. It only shows the startup, what actually would be useful is a log in the case of Picard crashing.
But looking at your screenshots, this does not actually look like a crash at all, rather one of those cases where the Picard UI becomes very unresponsive during saving under some circumstances. Usually it recovers once saving is finished, and it also updates a few times during saving.
Have you tried just giving it a bit of time?
What files are you tagging (are they especially large) and where do you store them (e.g. slow network storage)?
I save the songs on an external hard drive. this has always worked with the precursor musician of music brainz picard. I now have the songs stored on internal hard drive as everything works. only with external not. But this has always worked with external hard drives.
I suggest you run a disk check on your external drive as Picard shouldn’t be treating it any different. Certainly strange that this is happening always on the fifth track each time.
How is it connected - USB2, USB3? Is it FAT32 or NTFS?
If you walk away and leave it for ten minutes - what happens?
Agree that it is strange that Picard v1.x.x didn’t do this.
I had a laptop to fix this week that was crashing due to the owner attaching three external hard drives to it and expecting it to power all of them. So unexpected things can happen. His fix is a powered USB hub.
I have also heard some strange stories with usb power.
Is this a laptop? the maximum power output on usb ports can be different.
The hard disk can need more power as the platters spin up than the normal random access so it could be going along fine for the first few songs and then dip below a power level where the hard disk stops working.
I think this is something you should really try and give feedback. I am pretty sure from what I have seen so far that Picard is still working, it’s just the UI that has become very unresponsive. It should recover after some time.
It is a known issue that this can happen during some saves that take extremely long (the fix for this is unfortunately not really clear). This would not yet explain why it is so slow, though. But that might have a hardware reason, also if the files are e.g. lossless they could be really large.
I had similar issue a while back.
I fixed it by unplugging the dvd-rom drive. Not sure why this helped, maybe there was something wrong with the drive/cable.