Beet not overwriting certain tags

[CrossR]

Hey, I've recently started using beets again and it is doing 99% what I want....but certain tags are seemingly not being applied to a tiny subset of my files.

My process is as follows:

beet update # No changes listed
beet write # Changes listed
beet write # ... same changes listed
beet write -f # ... still the same changes listed

I basically just get a subset of my files reporting:

  artist_sort:  -> Some Artist
  original_month: 00 -> 05
  original_day: 00 -> 19

or similar and nothing I do seems to fix it. I've tried scrub, zero, import -L and rm -> import so far, and every other tag is fine, these ones just refuse to change.

From #5382 (and the linked #4715) it seems like it is somewhat fixed, though the actual issue focuses on other tags that aren't an issue for me, and the discussion mentions disabling id3v23 which isn't an option for me (I do have it enabled though).

I should also note that if I do beet list -f '$artist_sort - $original_month - $original_day' I get a whole lot of " - 00 - 00" (i.e. nothing) for basically everything, except the troubled files where the values are set.

Is there an easy way for me to fix this? Or if not, is it something I can fix externally to beet for now?

Version info:

beet version
beets version 2.3.1
Python version 3.11.2
plugins: convert, embedart, fetchart, info, inline, lastgenre, mbgenres, musicbrainz, replaygain, scrub

I'm using commit dd2f203090af6f570b0c5158661d718607758c96 with a local poetry venv, config linked here: https://gist.github.com/CrossR/9a8df17567b8d6d570aa9294525365e9.

[CrossR]

Not 100% a fix, as I don't really know what caused my library to end in that state...but I wrote a quick plugin that just sets the problem tags to "" and ran that over the problem albums, and now both beet write and beet update have gone to no updates.

For completeness, this is what I used (overkill, but it was just easier to fit into the structure of some of my other custom plugins): https://gist.github.com/CrossR/cd25a3f6591cb14d2b8ffc6f061a4f8c. Stick both files in a folder that is in your pluginpath and add removetags to your plugins, run beet removetags --dry-run 2025\ -\ Some\ Album or on an individual song, verify the output, remove the --dry-run flag. (I'd also be very surprised if this just didn't exist in another plugin, but my searching was failing to find anything except scrub and zero which seemingly didn't work for me).

I'm still slightly confused as to why the tags were wrong though...maybe they were set before I turned the id3v23 option on, and then never updated?

[CrossR]

Okay, final update from me, though I can raise an issue if I'm correct in my understanding here...

• When id3v23 is set, we pass that to MediaFile here.

• MediaFile in turn, when we call save a few lines later, calls a function called update_to_v23(), since id3v23 is set, here.

• That function is defined in mutagen over here, and crucially....seems to drop the three problem tags as they aren't supported in id3v23.

  • The month and day (original defined here), are dropped to just the year, as that is the only supported format in the older tags here.
  • Similarly the artist_sort (defined here), is dropped as its TSOP frame is listed for removal here.

• This means, essentially, those 3 tags are ignored because they aren't id3v23 compatible....but because they are dropped in memory, they aren't written out and deleted from the file. There is a missing "This field was ignored because its not valid, but it is there so we should delete it" check I guess?

I guess I must have had the files in question in my library before setting id3v23 to true, such that they were written then, but when you set the flag they aren't able to be fixed. That may also explain why my clumsy plugin fixed it, as it acts on those tags directly.