Album rating as a flexible attribute in .5 increments?


I would like to rate the albums I listen to in 2021, and I figured I could use a flexible attribute field for this and the types plugin to set said field to int. I want to rate albums from 1 to 5 in .5 increments, so a rating like 0.5, 3.5, etc. Is this possible somehow?

If I try setting a 1.5 rating using beet modify -a album:album albumrating=1.5 beets tells me:

  albumrating: 0
Really modify, move and write tags? (Yes/no/select) 

Thanks! :slight_smile:

Hi! If you want to use non-integer values like 1.5, you’ll probably want to use a type other than int. Maybe try float?

1 Like

I probably should have googled basic programming 101. Sorry for the trouble, and I appreciate your answer, it worked perfectly. :slight_smile:

However, I’m running into an issue with template functions now.

If I try beet ls -a -f '$albumartist - (%if{$original_year,$original_year,$year}) - $album%ifdef{albumdisambig, (%title{$albumdisambig}),}%ifdef{albumrating, ($albumrating),}' year:2021 then beets will return the album rating for the albums that has the field defined. For albums without the rating, $albumrating is returned.


Artist1 - (2021) - Albumname1 (2.0)
Artist2 - (2021) - Albumname2 ($albumrating)

Is there a solution for this as well?
Thank you again!

That’s odd. So is %ifdef not working at all for that field? It might be worth doing some experimentation with beet ls -f to determine how it’s behaving for that and other fields—and whether it’s affected by the type you set for it.

No, %ifdef doesn’t seem to work on int or float flexattr fields as far as I can tell. If I disable the types plugin then %ifdef works again. I’m not quite sure how I should troubleshoot further unfortunately.

Looks like a straight-up bug to me—reading over the implementation of %ifdef, I can see now how it would be confused about types with a default value. That is, int or float fields will produce a '0' string for unset values through the formatter, which gets interpreted as non-missing. We clearly need better logic for this. Would you mind opening an issue on GitHub?


1 Like