`update` command behavior


I’ve noticed some issues with the update command recently. I added a plugin which added a new mediafile tag/field for ITUNESADVISORY, but the update command refused to set it in the database for all the files in my library that have this tag set. I ended up reimporting a bunch of the files to pick it up. More recently, I noticed the musicbrainz info on some of my tracks was wrong, so I used Picard externally to correct the track ids (dup was picking up a duplicate that wasn’t really a duplicate, just a wrong mb_trackid) and ran update, but it didn’t update the database with the new trackid. Anyone else run into anything like this? It doesn’t seem 100% consistent, so I don’t have a reproducer handy at this point. Just throwing it out there in case anyone else has run into anything like this.

Thanks, would love any input.

I’m not sure about this specific problem, but there has been some discussion in the past about removing the MediaFile extension feature from beets’ plugins because it’s a little fragile. I actually just updated a planning page on the wiki about this yesterday using exactly this plugin of yours (found via a GitHub code search for that plugin feature) as a point against removing the feature.

I’ve seen several issues reported on GitHub where people have seen unexpected behaviour with beet update, but it’s really hard to know what’s going on without a specific reproducer. The problems can range from value normalisation, field name spelling/capitalisation, logic bugs in the code, etc.

Ah, fair enough, that does sound a bit messy, and injecting into the module isn’t particularly clean. I wouldn’t object to its removal. I can always submit my particular case as a pull req for consideration for mediafile itself, and if it isn’t accepted, can still make do with a db field, and set it from the tag via an external script, and possibly even automate that for new library additions via an import hook. Thanks.

I’ll let you know if I run into an update issue again in the future and will try to capture a reproducer before I work around the issue.