That totally is the plan but
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?
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.
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.
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.
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.
I found a couple of issues when testing Picard 2.1.0 dev2.
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.
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
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.
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.
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.
Cool. There is some logic in it. 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.
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.
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
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 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” In the UI it was showing as a whitespace and after removing it everything works properly.
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.
Hmm, I can’t start it anymore. Where should I find the logfile (*.exe started with -d)?
Start Picard from a command line window with
"C:\Program Files\MusicBrainz Picard\picard.exe" -d
Debug output will be printed in the command line.
Done. Waiting since more then 3 minutes, no GUI, no error, just nothing after “User directory:…”
C:\Program Files\MusicBrainz Picard>picard.exe -d
C:\Program Files\MusicBrainz Picard>D: 18:57:49,668 tagger.init:196: Starting Picard from ‘C:\Program Files\MusicBrainz Picard\picard\tagger.pyc’
D: 18:57:49,668 tagger.init:198: Platform: Windows-10-10.0.17134 CPython 3.7.0
D: 18:57:49,684 tagger.init:199: Versions: Picard 2.1.0.dev3, Python 3.7.0, 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: 18:57:49,684 tagger.init:200: Configuration file path: ‘C:/Users/Admin/AppData/Roaming/MusicBrainz/Picard.ini’
D: 18:57:49,684 tagger.init:202: User directory: ‘C:\Users\Admin\AppData\Local\MusicBrainz\Picard’
I downloaded the dev3 version and tried it out. I installed it over the top of dev2, after backing up the appropriate folders.
it seems to break the acousticbrainz_tonal-rhythm plugin. All of the other plugins I’m using are fine.
E: 13:03:16,766 album.error_append:222: Traceback (most recent call last): File "picard\album.py", line 351, in _finalize_loading_track File "picard\metadata.py", line 380, in run_track_metadata_processors File "picard\plugin.py", line 543, in run File "C:\Users\<user>\AppData\Local\MusicBrainz\Picard\plugins\acousticbrainz_tonal-rhythm.zip\acousticbrainz_tonal-rhythm.py", line 48, in get_data if not musicbrainz_recordingid in track_metadata: NameError: name 'musicbrainz_recordingid' is not defined
Edited to sanitize the error message.
After a fresh install of my Test-VM-Win10 Picard 2.1.0dev3 starts fine.
The tag «acoustid_id» can now be deleted with:
Both issues are fixed for me in Picard 2.1.0 dev3. The track correctly has a checkmark now after refreshing the release or re-adding the track and I don’t get an exception when saving the cover art with the broken newline character at the end of my script anymore (I will remove the newline from the script anyway).
Nice work there
Yeah, it’s the plugin, it has an embarrassing bug that went unnoticed through review I’ll submit a fix tomorrow.