Reimporting singleton files to albums is not easily possible

[JOJ0]

Already imported singleton files can't easily be retagged using the import -L option. A tedious second step via the imported file's path is required to achive that.

Problem

If we look at these outputs:

$ beet ls crossfire firebolt
Crossfire -  - 00 - Firebolt (0000/) []  f:MP3-192k a:04-02/Discogs |Heavy Metal, Rock, Drum And Bass, Speed Metal
Crossfire - Counterforce / Firebolt - 01 - Counterforce (2003/UK) [DSCI4 008]  f:MP3-192kCBR a:04-02/Discogs |Heavy Metal, Rock, Drum And Bass, Speed Metal

$ beet ls crossfire firebolt singleton:true
Crossfire -  - 00 - Firebolt (0000/) []  f:MP3-192k a:04-02/Discogs |Heavy Metal, Rock, Drum And Bass, Speed Metal

$ beet import -L crossfire firebolt singleton:true


$ beet import -L -t crossfire -s firebolt singleton:true
/remote/data/music-library/DrumnbassJungleDrumfunk/0-Album-Missing/Crossfire - Firebolt.mp3
Tagging track: Crossfire - Firebolt
(Similarity: 93.3%) (source) (Discogs)
[A]pply, More candidates, Skip, Use as-is, Enter search, enter Id, aBort,
plaY, eDit, edit Candidates? 

We see the following problems if our goal is to reimport an already imported singleton item in album mode.

• The -L flag ignores the given query when the library items are singletons.
• If we provide the -s flag additionally we do find the items in question, but a reimport jumps to the singleton import prompt right away. There is no way to switch back to album import mode at this point.

A tedious workaround is required to actually get the importer to show the regular album import mode on our singleton library items:

• beet ls <query finding singleton items> -p
• Copy the path to the file
• and issue beet import -t <paste path here>

Of course commandline trickery in bash or zsh could be done to ease that tedious copying and pasting part but that turns out to be unsurprisingly different since we most probably have to deal with whitespace and escaping things in our file paths.

I'm wondering if -L ignoring singleton files is a bug or supposed to be a feature. Could this behaviour be changed or is there any technical reason why it is implemented that way?

Setup

• OS: Manjaro current
• Python version: 3.10.8
• beets version: 1.6.1 git-master
• Turning off plugins made problem go away: no

My configuration (output of beet config) is:

FIXME when required/requested

I reported about this behaviour in a longish thread a year ago already: https://github.com/beetbox/beets/discussions/4211

[sampsyo]

Yeah, this is a super unpleasant issue to be sure! This kind of re-import is obviously useful, but it's tricky to get right in a way that is uniform w/r/t the other "modes" of the importer.

So yes, to summarize:

• beet import -L <query> searches for albums and re-imports as albums.
• beet import -s -L <query> searches for individual tracks and re-imports as singletons.

Neither mode lets you search for individual tracks and re-import them all together as a single album. In a way, this is the intended behavior, because both of the scenarios above are things we want to support. We wouldn't want to break them in the process of supporting the new, third use case. But it is a problem that the third thing is impossible.

Of course, it is always possible to just not use -L and use paths, as you've noted. But that's annoying.

We should maybe consider adding yet another flag specifically for this? I'm not entirely sure what that flag would look like, so ideas would be welcome. Unfortunately, if we were to add support, I predict that it might uncover other issues having to do with "removing" the individual tracks from other albums they're part of (if they weren't singletons to begin with), for example. But we should still do it; this is just an advance warning that it could be a fair amount of work.

[scztt-ni]

There's possibly another issue blocking this as well - tracks imported as singletons have a singleton: True property. I'm dealing with the same problem as @JOJ0 and I thought that I could resolve using beet modify album_name singleton=false. However, no matter what I specify as the new value for the singleton property, beets always reports that it's setting the singleton field to True - it appears to not be possible to set this to false, and afaict there's no way to delete/clear/reset a property using modify.

Maybe I'm misunderstanding the singleton property here, but if this worked it would I think resolve @JOJO's problem also?

[JOJ0]

Thanks @sampsyo and @scztt-ni for your feedback.

@scztt-ni yes I've been there. You can't just change singleton. I'm not sure why but wanted to dig into that once I find time... I think anyhow and also like @sampsyo explainend above, it seems to be not that simple and I'm a little scared now of getting my hands dirty with fiddling with this ;-)

@sampsyo thanks for the summary and insight. Regarding the third option way, the only thing that comes up is a --long-option, something like --singleton-to-albums. The option must be mutally exclusive to the -s option AND must require the -L option. An import statement that should match singletons and launch into this mode would then look like this

beet import --singleton-to-album -L <query>

Regarding your concern:

Unfortunately, if we were to add support, I predict that it might uncover other issues having to do with "removing" the individual tracks from other albums they're part of (if they weren't singletons to begin with), for example. But we should still do it; this is just an advance warning that it could be a fair amount of work.

Wouldn't it easy to prevent matching non-singletons if the new option --singleton-to-album would always automatically add singleton:true to the query. If a user would have enabled duplicate_action: merge, the singleton files being re-imported would then nicely integrate in an existing album if required. But probably I'm missing a piece and it won't work that easily?

Unfortunately nothing wants to come to mind about a short form option for this option..... :-/, the only other thing that I could think of is to invent an entirely new main option of import. Let's call it capital M, because it's the next letter after L. So a re-import like this would then be:

beet import -M <query>

(we dont't have capital M yet, do we??? ;-)

[JOJ0]

And my third and last idea of how a command could look like is to really have 3 options. Option 3 should only be allowed if -L AND -s are given already:

beet import -L -s --to-album <query>

[sampsyo]

For @scztt-ni:

However, no matter what I specify as the new value for the singleton property, beets always reports that it's setting the singleton field to True - it appears to not be possible to set this to false, and afaict there's no way to delete/clear/reset a property using modify.

The singleton property is a computed field; it is not modifyable. It just indicates whether a track is part of an album or not (tracks that are not part of albums are called "singletons"). So to make this field false, you'll need to make the track part of an album (which is what this issue is about).

[sampsyo]

About the question of what to do for the CLI: one option that might make the most sense, architecturally, would be an alternative to -L/--library. It could be called --library-items, for example. It would be an error (or at least a no-op) to combine this option with -s; it would only work in album mode. It would work like -L in album mode, but it would search for individual tracks (like beet ls does by default) and import them all as a single album.

The reason this design would make some sense, architecturally, is that it changes the behavior of the query associated with -L. So in that sense, it makes sense to make users replace the existing -L with the new option to get this new behavior.

[JOJ0]

I just found this post which explains what actually defines a singleton (album_id is empty on item): https://github.com/beetbox/beets/issues/2747#issuecomment-346873023

Also that issue is somehow related. It discusses the other way round: Changing album-items to singletons.

[eternaleye]

I feel like a clean way of handling this might be to use --flat and --group-albums. In particular, if --flat -L searched items (tagging albums), and -s -g -L searched albums (tagging singletons).