Help testing 2.1.0dev2

MusicBrainz Picard
1

For those who don’t saw it in the blog already a reminder that we have put out a Picard release 2.1.0dev2 for general testing and help in finalizing translations. Our goal is to release a stable Picard 2.1 before end of year, which will provide a great amount of fixes and improvements over the current 2.0.4 release. Thanks for your help! More details in the blog post:

And for the impatient, downloads for macOS and Windows are available at https://github.com/metabrainz/picard/releases/tag/release-2.1.0dev2

4 Likes
3

I have 2.0.5 dev1, but it’s update search function says there is no new version available (I have set it to look for dev versions). Is this intentional or a bug?

4

I’d say neither nor, but it’s expected. We did not yet update any version information on the website due to lack of time, and that’s where Picard checks for updates.

2 Likes
5

The official Website
https://picard.musicbrainz.org/
doesn’t offer the Picard 2.1.0dev2 for download, not even with “Other Downloads”.

To get a better feedback you should maybe update the official website too?

6

Yes, see my post above :wink:

7

Yep I know. Not everyone surfing the internet (using a search machine) and using Picard is reading this forum or MB blog posts :wink::innocent:

8

That totally is the plan but

3 Likes
9

After 1.4.2 could not calculate an AcoustID for a file, I updated to 2.1.0dev2, but problem persists:

D: 14:13:23,823 ui.itemviews.dropMimeData:547: Drop target = None
D: 14:13:23,824 ui.itemviews.drop_urls:510: Dropped the URL: 'file:///D:/01 Nochmal zu taggen/Rock Christmas, Vol. 4/07-dean_martin-winter_wonderland.flac'
D: 14:13:23,825 tagger.add_files:443: Adding files [<File '07-dean_martin-winter_wonderland.flac'>]
D: 14:13:23,825 file._move:473: Moving <File '07-dean_martin-winter_wonderland.flac'> from None to <Cluster 'Unclustered Files'>
D: 14:13:23,826 formats.vorbis._load:67: Loading file 'D:\\01 Nochmal zu taggen\\Rock Christmas, Vol. 4\\07-dean_martin-winter_wonderland.flac'
D: 14:13:23,830 file.update:519: Updating file <File '07-dean_martin-winter_wonderland.flac'>
D: 14:13:23,832 file.update:519: Updating file <File '07-dean_martin-winter_wonderland.flac'>
D: 14:13:23,839 acoustid._run_next_task:210: Starting fingerprint calculator 'C:\\Program Files (x86)\\MusicBrainz Picard\\fpcalc.exe' 'D:\\01 Nochmal zu taggen\\Rock Christmas, Vol. 4\\07-dean_martin-winter_wonderland.flac'
E: 14:13:24,006 acoustid._on_fpcalc_finished:181: Fingerprint calculator failed exit code = 2, exit status = 0, error = Unknown error
D: 14:13:24,006 acoustid._lookup_fingerprint:120: AcoustID: lookup returned no result for file 'D:\01 Nochmal zu taggen\Rock Christmas, Vol. 4\07-dean_martin-winter_wonderland.flac'
D: 14:13:24,007 file.update:519: Updating file <File '07-dean_martin-winter_wonderland.flac'>

fpcalc gives an unknown error. Perhaps because song is only 1m54s?

Bug?

10

According to @lukz

The minimum length should be somewhere around 12 seconds. Songs that
are shorter than 50 seconds are treated differently and it still
attempts to match them.

Source: https://groups.google.com/d/msg/acoustid/ls-IRoUt4DY/UaZI6Pg9Ya0J

This was back in 2011. I’m not absolutely sure if this is still true for fpcalc.exe v1.43
In addition, there was an issue for MacOS (Picard-1283).

1 Like
11

Opened cmd and tried with fpcalc.exe 1.43. I don’t know why, but first attempt opens VLC. Second attempt work. After this, Picard is working again. Seems to be a Windows mystery. Problem solved.

Thanks.

1 Like
12

I’m checking out Version 2.1.0.dev2, and noticed something that seems odd.

I’m dragging album folders into the middle column, then I select all and “Cluster.” Select the clusters and “Lookup.” Some of my albums are showing a changed MusicBrainz Release Id. I was under the impression that the Release Id was like the primary key for a release, and was inviolate.

it seems odd that most of my test cases have done this., but this is the first time I’ve tried to cycle through my library after tagging for the first time, so this may be normal. Corrections to my thoughts on the Release Id are welcome.

13

If you are re-tagging your files you really should keep Options > General > “Ignore MBIDs when loading new files” disabled. If this is unchecked (default) Picard will automatically load added files ino the right pane based on the MusicBrainz Release Id and MusicBrainz Recording Id. Otherwise if you drag files from the right back to the middle column the assumption is that you want to do a fresh identification of those files, as the middle pane always holds untagged files.

2 Likes
14

I found a couple of issues when testing Picard 2.1.0 dev2.

  1. After saving any track and refreshing its release in Picard, it indicates it has to be re-saved again (no green checkmark) despite there being no tag differences. Cover art is disabled (I also tried after enabling and downloading the cover art, same result). All scripts and plugins disabled. Screenshots here: https://imgur.com/a/bwBFALG.

  2. There seems to be an issue with a multi-value TXXX:ARTISTS tag. After loading a file that has been tagged in Mp3Tag/Foobar into Picard, it shows the tag as empty. After saving it in Picard and loading it in Mp3Tag/Foobar again, the tag shows twice (e.g. tag with 2 values is showing as tag with 4 values now). Screenshots here: https://imgur.com/a/urlYauL

  3. My custom file name for cover art doesn’t seem to work anymore. The string is “Cover\\$replace(%albumartist% - %album%$if(%date%, [%date%],),\\,_)” (minus the quotes). Debug logging shows the following error: https://pastebin.com/raw/g4XQT7mZ which I guess is just an invalid syntax in my script. As far as I remember the script worked in 1.4.2, so my guess is that something changed with the new python version and it should be modified now?

I can provide more information if needed. Also I will be frequenting IRC for a bit so you can message me there as well.

3 Likes
15

Check the Edit History for some of those releases and you will probably find they have been merged when someone has been cleaning up duplicates.

16

That’s exactly what happened. Thank you.

Thank you. As soon as I read that, A light went on in the dim recesses of my brain indicating that I knew this. It’s been a few months since I worked with Picard. I should have done a better job of documenting my process. (I was dragging from the left column.)

I see the same behavior.

1 Like
17

Cool. There is some logic in it. :slight_smile: I am also pretty sure that the “merge” means any program that attempts to lookup that older MBID will still be directed to the correct record. One of the nice design features of the merge process.

1 Like
18

I can reproduce this, I added a ticket and submitted a fix, see PICARD-1437

I cannot reproduce the behavior you described, but it must be related to the changes how we store artists in ID3. We used to store it as TXXX:Artists, but changed this to TXXX:ARTISTS for better compatibility across tools (including MP3Tag). Picard also updates tags, so this duplication should not happen. Do you have any scripts setting ID3 tags directly like e.g. $set(_id3:TXXX:artists,something)?

I can’t directly reproduce this, but I can see what happens: Somehow the file name ends up with a newline after the filename, which is not valid for a filename. We definitely need to clean this up. I’m still curious how you managed to get this in, I tried copy and pasting a line break explicitly in the cover art naming, but this did not carry over (it showed as whitespace in the options, though). Do you have any idea how this came to be? What Windows version do you use?

Update: Patch for the cover art issue is also coming, see PICARD-1439

3 Likes
19

Interestingly enough, after I checked “Clear existing tags” setting in Options/Tags and saved the file, Picard will show the checkmark for this file from now on even if I uncheck the setting afterwards. With more testing, I found out that if I removed “genre” and “albumartists” tags from my files, I got the checkmark again. I don’t populate the genre tag with mb data yet and albumartists tag is currently written as “TXXX:albumartists” instead of “TXXX:ALBUMARTISTS” and currently is not an official tag (shameless plug for https://tickets.metabrainz.org/browse/PICARD-700). So in conclusion, if there were any tags in your files that didn’t match their equivalent to mb data, the files didn’t receive the checkmark and would be re-saved again (we also have an issue for this here: https://tickets.metabrainz.org/browse/PICARD-300). Your fix might already make the checkmark to be be displayed again, I am mentioning this just in case.

I tested this a bit further and I found out that Mp3Tag indeed saved the tag as “artists” instead of “ARTISTS” but ONLY if I changed the tag in the main UI. If I changed them via the “Extended Tags…” function, they were correctly saved as “ARTISTS”. My guess is that I when I tagged my files in the past, I saved multi-value tags this way because the single-value tags in my files have the correct “ARTISTS” tag. So there is no bug with Picard :slight_smile: I will report this bug to Mp3Tag forums momentarily.

It looks like my script got corrupted somehow and Picard.ini showed the following setting: cover_image_filename=“Cover\\$replace(%albumartist% - %album%$if(%date%, [%date%],),\\,_)\n” :sweat_smile: In the UI it was showing as a whitespace and after removing it everything works properly.

2 Likes
20

We have an updated build Picard 2.1.0dev3 available for download at https://github.com/metabrainz/picard/releases/tag/release-2.1.0dev3

This addresses the issues reported here, so some feedback if everything is resolved is very welcomed. @culinko: I’m especially interested if the reload issue is fully fixed by this.

While the focus was on bugfixing and improving the build process, two new features also sneaked in. I expect this to be the last dev built before we release the final Picard 2.1.0.

Unfortunately we still have some trouble quickly updating the website, so no update notification as of now. But we’ll make sure to get everything in place for the final release. Thanks a lot for all your testing and feedback, it has been a big help so far.

2 Likes