Picard crashes when loading specific songs

#1

It appears to be cover art related. When I turn off “Embed cover images into tags” it works fine. I’ve identified two songs that it crashes on out of 271 though I’d bet there are more. I know I’m not running out of memory because I have 16GB which is more than enough and I don’t see my memory use go past 50% on my PC at all up to the crash. Additionally, it will crash even just loading either of those two songs by themselves. I’ve attached log below:

D: 09:02:36,013 tagger.init:202: Starting Picard from ‘D:\Program Files (x86)\MusicBrainz Picard\picard\tagger.pyc’

D: 09:02:36,013 tagger.init:204: Platform: Windows-10-10.0.17134-SP0 CPython 3.7.2

D: 09:02:36,013 tagger.init:205: Versions: Picard 2.1.3, Python 3.7.2, PyQt 5.12, Qt 5.12.1, Mutagen 1.42.0, Discid discid 1.1.1, libdiscid 0.6.2, astrcmp Python, SSL OpenSSL 1.0.2k 26 Jan 2017

D: 09:02:36,013 tagger.init:206: Configuration file path: ‘C:/Users/snapp/AppData/Roaming/MusicBrainz/Picard.ini’

D: 09:02:36,013 tagger.init:208: User directory: ‘C:\Users\snapp\AppData\Local\MusicBrainz\Picard’

D: 09:02:36,027 i18n.setup_gettext:55: unsupported locale setting

D: 09:02:36,028 i18n.setup_gettext:71: Using locale ‘en_US.cp1252’

D: 09:02:36,028 i18n.setup_gettext:73: Loading gettext translation, localedir=‘D:\Program Files (x86)\MusicBrainz Picard\locale’

D: 09:02:36,028 i18n.setup_gettext:84: [Errno 2] No translation file found for domain: ‘picard’

D: 09:02:36,028 i18n.setup_gettext:103: _ = <function setup_gettext.<locals>.<lambda> at 0x0000028D3FBD00D0>

D: 09:02:36,028 i18n.setup_gettext:104: N_ = <function <lambda> at 0x0000028D3F5C0048>

D: 09:02:36,028 i18n.setup_gettext:105: ngettext = <function setup_gettext.<locals>._ngettext at 0x0000028D3FBD0158>

D: 09:02:36,028 i18n.setup_gettext:106: gettext_countries = <function setup_gettext.<locals>._gettext_countries at 0x0000028D3FBD01E0>

D: 09:02:36,028 i18n.setup_gettext:107: gettext_attributes = <function setup_gettext.<locals>._gettext_attributes at 0x0000028D3FBD0268>

D: 09:02:36,058 webservice.set_cache:293: NetworkDiskCache dir: ‘C:/Users/snapp/AppData/Local/MusicBrainz/Picard/cache/picard/’ size: 60182516 / 104857600

I: 09:02:36,058 plugin.load_plugindir:267: Plugin directory ‘D:\Program Files (x86)\MusicBrainz Picard\plugins’ doesn’t exist

D: 09:02:36,059 plugin.load_plugindir:292: Looking for plugins in directory ‘C:\Users\snapp\AppData\Local\MusicBrainz\Picard\plugins’, 0 names found

D: 09:02:36,443 tagger.main:878: Looking for Qt locale en_US in D:/Program Files (x86)/MusicBrainz Picard/PyQt5/Qt/translations

D: 09:02:36,451 browser.browser.start:69: Starting the browser integration (127.0.0.1:8000)

D: 09:02:36,492 ui.mainwindow.auto_update_check:1140: Skipping start-up check for program updates. Today: 2019-04-12, Last check: 2019-04-11 (Check interval: 7 days), Update level: 0 (stable)

D: 09:02:36,493 webservice.ratecontrol.get_delay_to_next_request:109: (‘musicbrainz.org’, 443): First request

D: 09:02:36,493 webservice.ratecontrol.increment_requests:134: (‘musicbrainz.org’, 443): Incrementing requests to: 1

D: 09:02:37,319 webservice.ratecontrol.decrement_requests:142: (‘musicbrainz.org’, 443): Decrementing requests to: 0

D: 09:02:37,322 webservice._handle_reply:411: Received reply for https://musicbrainz.org:443/ws/2/collection: HTTP 200 (OK)

D: 09:02:37,325 webservice.ratecontrol._out_of_backoff:225: (‘musicbrainz.org’, 443): oobackoff; delay: 1000ms -> 1000ms; slow start; window size 1.000 -> 2.000

0 Likes

#2

When does this crash happen exactly? E.g. does it happen when loading the files, or when saving?

Also want the log above taken when an actual crash had happened?

1 Like

#3

The crash happens during file loading. The log above is from after opening Picard again after the crash. During the crash, Picard freezes and I’m not able to copy the log. Is there a way to get it during the crash?

0 Likes

#4

Which exact release are you working on when it crashes?

There are many types of art at MusicBrainz: from tiny 600x600 JPGs of a few KB up to huge 20MB PNGs of 3000x3000 and larger.

0 Likes

#5

v2.1.3

I am able to select several individual songs, meaning I select ONLY that song and it will crash Picard so I don’t think the size of the album art even if it is 100MB is causing me to not have enough memory.

I took this screenshot since I am not able to copy the text while it is frozen prior to crashing.

Picard%20Log

0 Likes

#6

I didn’t say anything about memory. I was aiming to assist by looking at the artwork angle.

You are stating yourself that this only crashes when Embedded Artwork is selected. When that option is not selected then you said you are not getting an issue.

0 Likes

#7

I understand now. I thought you were referring to memory because all the forum posts I’ve found say that it is memory.

And that’s right, it is ONLY when embedding cover art. Additionally, I have selected to ‘Only use images of the following size: 500px.’ Not sure if that’d be relevant.

1 Like

#8

Well, this is a nice fresh forum post for you and your specific issue. So we’ll help out by narrowing down what is special on your setup. (And it isn’t memory :wink: So that is one less item to check)

Ideally would help if those files causing trouble could be uploaded to a file share or wetransfer.com so we can try to reproduce this.

Very relevant if you changing this on \ off is the difference between crash or not.

-=-=-

Also note - only test with a small number of files. Ideally just the one. Does it still freeze?

When it freezes, how long do you leave it? Walk away for ten minutes and then return later. Has it unfrozen when you return?

The idea is the more you narrow it down, the more likely it can be reproduced by someone else, and then the bug found and fixed.

0 Likes

#9

I select just one file. It freezes for 4-7 seconds then crashes.

0 Likes

#10

I just tested with the file you provide, Picard 2.1.3 under linux, no issue

I could load it, and look up for matching release

0 Likes

#11

I’ve tried kicking this around on a couple of Windows PCs and there is no problem appearing yet. Tried various combinations of embedding the image. Different sizes. Different options. Can’t get any freeze from this file.

I notice that the actual release doesn’t have any images attached, but the Release Group does. Nothing that special there though as they are just normal JPGs. Multiple front images, a bit slow to download, but nothing odd.

It is also interesting to see it was already tagged with MBIDs inside. Which would usually imply the tags had been done by Picard in the past.

0 Likes

#12

Hi all,
Isn’t 7mb a little heavy for a 2 1/2 minute mp3? Is there something else in the file?

0 Likes

#13

I was hoping others would have issues as well. I’ve attached a screenshot of the debug log from this one song being added. Previous screenshot was of adding my whole collection.

mahna

As far as the current tagging, I have tagged my collection in the past.

0 Likes

#14

Not that big. I tend to avoid MP3, but sitting in my same test folder is another 320kbps track that is 5mins 31secs and 12.7MB. So seems 7MB is not too weird for 3mins.

This should mean the file is even more compliant. If the last tagger to write tags to this file was Picard then the tags should all be clean.

0 Likes

#15

I have two additional songs I’ve identified as causing me issues. Again, I’m fairly certain I’ve tagged these before. Interesting to note, they are both from the same album.

0 Likes