Having a big problem with MusicBrainz database and Picard tagger, help please

MusicBrainz Picard
, , ,
1

Good morning,

I am really hoping someone can help me with my problem, I’ve been spending the last few days trying to solve this but I feel stupid and hopeless. I don’t understand. I was so excited when I found Picard because it is a lifesaver for me, and my wife’s classical music collection. I have OCD and it’s a constant battle as a classical music tagger. But once I realized Picard was a thing, my world changed forever. Take all my money Picard. :slight_smile: Here’s the situation.

I am trying to do something for my wife for Valentine’s Day. I bought her a box set, and I’m trying to tag it, so it will look great on our home media server when she plays it on the devices.

However, no matter what I try, the only information that’s being pulled from the database is just the bare minimum: basic composer and title name, that’s pretty much it for usable.

The database has SO much more tag info which I was overjoyed to find but, the tagger just refuses to pull it in. Picard doesn’t import conductor, orchestra, engineer, soloist/performer (if any), et al.

And so I’m crying inside thinking about having to tag all of these manually even though the information is already present in the database?? What am I missing please?

How can I set up Picard to actually import all of the tag information that already exists in the MusicBrainz database? Because no matter what, it’s just not showing up. I’ll attach a screenshot and a GIF showing you the difference between MusicBrainz online database, and the Picard tagger.

FYI I have no special settings for the program, there’s no tag filtering, settings, there’s no special setup that I have here. This is all default installation.

Please help me with this. I really appreciate it. I’m just hitting my head against the wall here. I don’t understand.

The most important information would be the conductor, orchestra name, and soloist performer if any. It already exists, but I keep failing to import it to tagger. I’m stressing out thinking about having to do that all by hand even though it’s already in the database.

Thank you very much for helping me with this. I really do appreciate it. Is there a fee/cost for adding this feature or something I’m missing?

Sincerely,
Hubs

tl;dr

MusicBrainz database tags are not being pulled into Picard no matter what, and I’m going to cry lol can you help me figure out what I’m doing wrong?

============

MusicBrainz Database screenshot showing tags exist:

Picard/Tagger Import completely bare, missing so much tag info (conductor, orchestra, etc):

=============

3 Likes
2

You could have a look at this plugin:

I’m not using it by myself, but it looks it could deliver your wanted data.

5 Likes
3

In general first make sure you have enabled “Use release relationships” and “Use track relationships” in Options > Metadata. This enables Picard to query all these additional relationships like conductor, performers etc.

But you mentioned this is a box set. If it is too large you might not get the relationships anyway. The MusicBrainz server does not return all the relationships for box sets with more than a certain amount of tracks (I think the limit is 500 tracks).

We have a solution for this in Picard, but this is currently only available in the development version.

EDIT: Yes, just saw on the screenshot that it is over 2000 track, so this definitely is one of the releases not getting the advanced relationships in Picard 2.7

If you want you can try out a current development build, which should be able to get all relationships for your box set. I just uploaded the recent builds here:

Just the usual disclaimer applies: This is a development release. We might have added some bugs and some new functionality might not be fully complete yet. Make a backup of your files before you tag them. But having said this I think we have Picard currently in a very good shape and I’d consider the current changes release ready.

I’d be happy about some feedback if this helps you tag your box set or whether you still encountered some issues :slight_smile:

9 Likes
4

I’m so glad you were able to connect the dots for me, wow thank you thank you. Yes, it’s a large box set as you see, so it’s interesting to know that’s a primary reason for the lack of tag imports. I’ll certainly try the dev version on my laptop here and give you detailed feedback if it solved my Beethoven problem. Stay tuned. :slight_smile:

I love this community!! Picard is a masterpiece.

Hello. Thank you, so so much for this resource. I will check it out for sure today. It looks like a staggeringly good plugin!! If it works good on my end, is there a donate/support link somewhere that you know of? The more I look into it, the more my mouth waters lol look at all this OCD goodness!!

Thanks!

6 Likes
5

For the plugin itself you could ask @MetaTunes directly.
For all the metadata (aka “OCD goodness” :sweat_smile:) and Picard: How to Contribute - MusicBrainz

1 Like
6

Hello!

Ok, I am crying happy tears lol this works perfectly. Like, I mean perfect. The entire box set tags was pulled in from MusicBrainz and it was fixed in about 90 seconds. I’m now doing all her classical music now and I’m in heaven. Can you give me a brief, simplified explanation as to what changed in this dev version that allows all the proper tag quantities to be downloaded? Because, whatever you did, it’s fixed. Please make this never go away :slight_smile:

I’ll be back later today with a full update with details/feedback on the process.

Thank you!!! All of you, this place rocks. Have a great day!

5 Likes
7

This is great to hear, I’m happy this worked that well for you.

Picard now does additional requests to gather the information. It means slower loading time, as it can only request the details for 100 recordings at a time and the API is rate limited to one request per second. In your example this means loading the entire release should have taken roughly 20 seconds longer. But I think this is acceptable if the alternative is to miss all these details :slight_smile:

4 Likes
8

100% worth it. Oh I see, so it only will see a slowdown if and only if you retrieve those larger sets, right? Normal operation with say 10 tracks per disc, no slowdown would be expected vs. normal use?

Sweet. So, this dev-build only feature won’t be going away in a future release. Right? :slight_smile:

1 Like
9

Yes, exactly. This only applies to these huge releases. And no, that feature won’t go away. It will get officially released with Picard 2.8

4 Likes
10

this dev version rocks fyi seems stable to me. love it!

4 Likes
11

Hey there,

Just wanted to come back here and let you know that, fwiw, every single time I hit “cluster”, the program crashes silently. Just poof, closes. And that’s it.

As a result, I have to manually drag and drop mp3s by hand into the program, search the MusicBrainz database, manually import tagger albums, so I can then drag and drop the mp3s manually into that album for tagging. Yikes lol. I know, this is not correct behavior but I cannot figure out why suddenly my cluster button just silently crashes Picard. No way around it. Every time. Scan and lookup work normally, and that’s good it seems!

I haven’t changed any settings or done any Windows 10 major updates.

Any ideas what it could be? Graphics card? Internet? Bad luck? :frowning:
Thanks!

12

Which plugins do you have selected? Turn them all off and test. Then turn them back on one by one until it crashes.

13

Most likely a bug, but I can’t reproduce it here. Could you try running Picard via a Windows command prompt? Just open a command prompt window and launch Picard with:

"C:\Program Files\MusicBrainz Picard\picard.exe" -d

This assumes you have installed Picard to the default folder. Please note the quotation marks, those are mandatory. Picard will start and output a bunch of information on the command prompt. Leave the command prompt window open, and inside Picard make it crash with the clustering. Now I need the output of the command prompt window. A screenshot is usually enough, just make sure you capture the very end of the output.

Hopefully this gives some details about the cause for the crash.

1 Like
14

Hello!

Thank you for this suggestion. I did launch Picard with the -d flag and saved the output for you from my cmder window. I don’t see much info there but, I hope this helps you. I’m using the dev version of Picard, not the stable older release, fyi. :slight_smile:

Pasting debug output now.

PS. It crashed easily and every time so I have lots of debug info for you!

I deleted 100s of lines of just tagging and metadata stuff you most likely didn’t need. Let me know if you really want it I can add it back :slight_smile:

I don’t have many plugins running but I can disable those if you think that could help but, I wonder if there is something else at play here. Thank you for any help.

I didn’t see any obvious crash info from the terminal output but this is all I have currently. Maybe cover art or something weird. All defaults.

https://pastebin.com/raw/2NDRZpPa

(I disabled all cover art plugins, still crashes.)

Update:

I tried a long shot and ran this for you:
picard.exe -d 2> debugging.txt

and the output was:

Warning: QT_DEVICE_PIXEL_RATIO is deprecated. Instead use:
QT_AUTO_SCREEN_SCALE_FACTOR to enable platform plugin controlled per-screen factors.
QT_SCREEN_SCALE_FACTORS to set per-screen DPI.
QT_SCALE_FACTOR to set the application global scale factor.
qt.qpa.fonts: Unable to enumerate family ’ “alphabetized cassette tapes classic” ’
qt.qpa.fonts: Unable to enumerate family ’ “Alphabetized Cassette Tapes Thin” ’
Traceback (most recent call last):
File “webservice_init_.py”, line 572, in process_reply
File "webservice_init.py", line 559, in _handle_reply
File “album.py”, line 346, in _recordings_request_finished
File “album.py”, line 543, in _finalize_loading
File “album.py”, line 472, in _finalize_loading_album
AttributeError: ‘Album’ object has no attribute ‘_new_tracks’

No clue what those fonts are or what anything means from this, sorry.

All I know, as of now, I cannot scan anything in Picard without a crashing.

Note: Picard portable (portableapps) works fine. Instantly scanned, tagged, perfect without any bugs or errors.

Is something wrong with my dev version suddenly? Or is it maybe some setting? I really haven’t changed anything in weeks.

2 Likes
15

Thanks a lot for this. Not sure why there was no actual error output in your first attempts. If it just crashes without any further output it usually indicates some memory access issue, often caused by threading issues. Then it gets hard to debug, especially if I can’t reproduce it on my system.

But the second output with the _new_tracks error gives some clue, I will investigate and fix. And yes, that’s likely something happening only in the development version and probably related to the changes done to load huge releases.

1 Like
16

@newclassical I kind of see how this issue happens, at least I can ensure it doesn’t happen.

What I’m currently unsure is if this can happen in Picard itsflf when loading a release with large amount of recordings, or whether this also involves a plugin which loads additional data.

Do you have any plugins enabled, and if yes which ones?

1 Like
17

Hello!

If this helps, I disabled every plugin I was using, and disable all startup scripts, all that stuff. And the crashing still occurred each time. But I’ll happily share my plugins that are active sure!

  • Amazon cover art
  • Deezer cover art
  • Disc Number
  • Album Artist Website

(And occasionally a while back I was using $rperformer function for some classical music taggings)

And while I do have many large box sets (with 100s of mp3s), please note that this crash occurs regardless of if I use a small CD of 10 mp3s, or 500 mp3s. Just fwiw.

Every so often, seemingly randomly, Picard does work and I am able to tag/scan/lookup/normally. However, in those cases, it is always a small CD, like 10 mp3s or so. Never a box set. They always crash.

Does that help?

PS. If this is important at all, I will tell you that the crash always occurs a few seconds after the tags begin to appear. i.e.

[loading album information]
[loading album information]
[loading album information]
[loading album information]

The moment this begins to appear, it’s crashed closed within 3 seconds or so.

Maybe that helps narrow it down?

1 Like
18

I still can’t fully reproduce the crash happening in this log output, that’s of the category “this situation should not be possible”, but as I said I can prevent this from happening. Just looking a bit still how to best change the code.

But while testing with actually clustering and loading files for releases with over 2k tracks I noticed also that performance in some situations is horrible. Just loading the release is fine (just takes a bit longer due to the extra request for the recording relationships, but can’t avoid that). But when also assigning files Picard freezes for quite a long time after loading has finished and the files get assigned to tracks. Also trying to save a larger amount of the files on a single release makes Picard freeze completely when performing the UI updates after the actual saving.

So I’m currently working on improving this situation in general for a smoother handling of these huge box sets.

3 Likes