Modifying album fields propagate to items?

[JOJ0]

Hi,
I'm wondering if I'm finding a bug or if this is a feature:

When I modify a bunch of albums to have a flexible attribute changed, it does not seem to change the flexible attributes of items. This inconsistency leads to a whole bunch of weird behaviour especially with path formats which I think respect both: item and album fields.

Ist this intendend? If yes, why does it make sense? IMHO it would be much cleaner if for example:

beet mod -a toplevel=NewCategory toplevel:OldCategory

would also change the items toplevel field.

Another example with a built-in flex attr:

beet mod -a data_source=ManuallyTagged the unreleased album I did not find online

The items' data_source field of this album now still are empty or might be wrongly populated with MusicBrainz (or other tagging source) because of unsuccessful autotagging attempts. It would have been better if the "childs" (items) would now get the field changed as well.

Feature request? Bug report? Works as designed an should stay that way? Cheers :-)

Also an important fact is: On a beet import --set=toplevel=NewCategory something new BOTH the album and the items field are set! What I'm trying to say is that changing them afterwards is tedious.

[JOJ0]

Reminder to myself: Possibly related stuff. Read this later:

#2988

#4663

[sampsyo]

Yes—for better or for worse, flexible attributes on albums are distinct from flexible attributes on items. I totally realize that this can lead to strange situations, but the reason it's not currently a total disaster is that items get to "use" the flexible attributes from their albums in several contexts.

Namely, #2988 points at a situation where you use use beet ls foo:x bar:y and $bar (but not $foo) is only defined on the album. We now automatically "fall back" so items get to act as if they have the same metadata as their albums. This means that, most of the time, you can ignore the fact that the actual database associates the data differently with the two structures.

[JOJ0]

Thanks. Ok, if I get around to it, and I will, at some point, I'll look into submitting a PR. I would even go that far and change -a to affecting items too as the default but leave it configurable to get back the current behaviour (-a affecting album only). After reflecting your last message, I think that sounds like the most "correct" way and would let users that really require it, get back their usual workflows. Good?

[JOJ0]

Something I just noticed and want to share and document here. It seems mod -a does also change items when the added field is modified (a:yy-mm in my album/item formats):

$ beet ls -a the prototype years
1997 - Grooverider - [487219 9] The Prototype Years  a:23-04/MusicBrainz b:844k [24/24]

$ beet ls the prototype years track:1
Grooverider - The Prototype Years - 01 - Dreams of Heaven feat. Codename John (1997/GB)  [487219 9] f:FLAC a:23-04/MusicBrainz |Drum And Bass, Jungle

$ beet mod -a added="2002-11-17 0:0:0" the prototype years 
Modifying 1 albums.
1997 - Grooverider - [487219 9] The Prototype Years  a:23-04/MusicBrainz b:844k [24/24]
  added: 2023-04-05 08:30:38 -> 2002-11-17 00:00:00
Really modify, move and write tags? (Yes/no/select) y

$ beet ls -a the prototype years                          
1997 - Grooverider - [487219 9] The Prototype Years  a:02-11/MusicBrainz b:844k [24/24]

$ beet ls the prototype years track:1                     
Grooverider - The Prototype Years - 01 - Dreams of Heaven feat. Codename John (1997/GB)  [487219 9] f:FLAC a:02-11/MusicBrainz |Drum And Bass, Jungle

In the database now:

album
1037487600.0

item
1037487600.0

[JOJ0]

I hope I don't confuse anything here: I have the importadded plugin enabled. I think it doesn't have to do with above behaviour but just mentioning it to make sure.

importadded:
    preserve_mtimes: yes
    preserve_write_mtimes: yes

[sampsyo]

I could be wrong, but I think this behavior (beet modify -a affects both albums and their items) is true for all fixed fields? For example, beet modify albumartist=foo would have the same behavior as modifying added.

[sampsyo]

(And I meant to say: yes! That plan sounds great!!!)

[JOJ0]

More stuff to read:

#3927

#3925

#2800

[JOJ0]

Skimming thru old unanswered discussions... I think most of this is implemented in #4823