Hi all.
Great resource. Thanks for everyone’s contributions to date.
I’m just getting familiar with the program and have a question as to exactly what Picard is doing. I’ve tagged and saved a great heap of albums and am working through various issues but noticed something that makes no sense to me.
If I drag a few of the album files that have previously been tagged back into the left hand pane (does it have a name?) and press lookup or scan on the group, Picard always updates some of the albums & always the same albums. The remaining albums always remain unchanged.
When I look deeper, it is always (and only) the WMA files that get updated, not the album art. If I repeat the process a minute later, I get the same thing and I’ve noticed that nothing in the Original Value column has been altered from the data displayed in the New Value column.
So what info is being updated and why?
The first question that will be asked is - which version of Picard are you running? Picard v2.x is getting updates and fixes at the moment. Pretty sure something like this was mentioned re: filetypes
Next question. When you load an album up for the second time can you see what is coloured different among the tags? That should point to what Picard thinks is different. A classic I get is sometimes the track length is different to what Picard has and that can flag a difference even though Picard isn’t going to change any tags.
Thanks for responding Ivan.
Q1/
I’m on Picard V 2.0.4.
Q2/
This is the mystery. Nothing has been changed & nothing has been highlighted in a different colour (color!). Each and every tag is character for character identical. This applies to both the album tags and the tags for each individual track.
Try the latest v2.1.0dev2 release
If you have a look at the release log there is a lot still being patched. Few mentions of WMA in there, not sure if relevant to your issue. Certainly worth a try over the top of v2.0.4
That is the thread to then point any issues into.
Thanks again Ivan.
I’ll give that a go.
I am not sure I understand the issue correctly, so I try to summarize what I think is happening:
If you tag and save WMA files and then move them back to the left pane and lookup again, they are moved correctly to the right but show up as being changed even though there are no visible changes displayed in the metadata. If you do this with other file types it works as expected. Is this correct summary?
If so please do first try the 2.1 dev3 release from https://github.com/metabrainz/picard/releases/tag/release-2.1.0dev3, it could be this has been fixed. If this does not solve the issue please let us know. I will also try to reproduce this issue with some WMA files of my own.
Thanks Ivan & outsidecontext…
I’ve just installed Version 2.1.0.dev2 and the behavior is identical to that reported above.
@outsidecontext…
I have only tried WMA files as they are all that I have at the moment, but I can try saving an album in MP3 format and report back.
Here’s my exact steps to produce the problem:
- Drag 2x of the previously tagged offending WMA ripped albums into the left pane.
- Picard does its stuff and they appear as updated in the right hand pane, but no tags at all have been altered anywhere and nothing is highlighted in any way.
- I save both albums, and the asterix indicating the updated info disappears.
- I drag both albums individually back into the left pane & hit Cluster.
- I then highlight Clusters (2) and press Lookup.
- After a few seconds the albums show as again being updated in the right hand pane.
I’ll detail all of this as an issue for Version 2.1.0.dev2 and I’ll re-rip these albums as MP3s and see if that alters the behavior.
Please install Version 2.1.0 dev3 from the link @outsidecontext posted, a similar bug has just been fixed in that version which might solve your issue.
@Wayne_Kiely sorry to send you the link to the older one. I hadn’t seen that there as a dev3.0 release. It didn’t come up in the search.
Follow what @culinko and @outsidecontext suggest as they know more about the exact active current state of bug fixing.