Curious Album duplicity?

[bernd-wechner]

Just trying mopidy out right now I admit. But one thing I notice on a first sally (and I'm using SQLite local library) is the 12 tracks in one album 11 appear in the database in one album and one in another album, of exactly the same name! And I'm bamboozled as to why.

If I look in the database album table the single track album has exactly the same name though the artists field is blank in this single track album.

If I examine the album in puddletag I see easily that the Album and Artist are identical.

BUT, here's what I noticed, the one track in the one track album has Album Artist set the other 11 don't. And it's set to the identical string (yes with whitespace checks) as Artist. But this caused a split.

So I'm wondering by what criteria is an album an album?

Could be a mopidy question if this extension receives it split already (not sure who drives the local scan and categorisation). In which case just point me that way and close this. I can move it to mopidy with some learning under my belt.

[tkem]

I think you already mostly answered your question yourself: if no musicbrainz_id tag is present (as added e.g. by beets, Picard and some other taggers), albums are grouped by all the album-related tags, including "album artist". This is by design, and the usual recommendation is to fix your tags, in this case make sure all tracks share the same album artist, and rescan.

[bernd-wechner]

Thanks for the update on that. It raises a couple of quick questions to which, if I had answers I'd save some time and effort I guess:

1) Where is this documented? And if it isn't I'd see that as an issue, be happy to file it, and even to contribute what I learn to the documentation where appropriate. I guess I find the uniqueness criteria of albums pretty central to managing a media library and come from a background of, if it's in one folder it's probably one album, trumping the notion of tag integrity. Not that it matters so much what the priorities are as that they are clearly documented somewhere.

Best I've achieved is:

http://mopidy.readthedocs.io/en/latest/search/?q=album&check_keywords=yes&area=default

and homed in a little on:

https://docs.mopidy.com/en/latest/modules/local/?highlight=album

But a small pointer from an experienced perspective can save me some fishing around and I guess the observation is I haven't stumbled upon clear documentation.

2) Is this uniqueness criterion made my the local-sqlite extension or before it gets there in the core of mopidy already? In short is it a decision that individual extension writers tackle with I guess and where would I look in the code to see this decision being made? Just curios really for upskilling my end I guess.

Either way, if it's behaviour by design AND documented I this issue is closed/resolved.

[tkem]

1. Documentation is one of the major weak points of M-L-S, as already noted in #29. Please feel free to add any specific documentation requests there (or even better, start filling in "the blanks" yourself, but that's probably too much to ask for now...)

2. It's a mopidy-local-sqlite decision, which has its limitations/issues especially with multi-disc albums. See also #46, which also mentions the possibility of a path-based strategy, i.e. one directory - one album. See https://github.com/mopidy/mopidy-local-sqlite/blob/develop/mopidy_local_sqlite/library.py#L236 for the "URI-generation algorithm" which determines if two album models as passed by the scanner are considered to be identical.

[bernd-wechner]

Thanks, duly noted and as time permits may well do. IMHO, configurable strategies is a desirable future that can support diverse local library management strategies. Which would simply mean that if I or someone implemented path URIs, it might be sensible to support enabling/disabling them via config file. Or? Basically options permit progress without demanding consensus.

[tkem]

There's already use_album_mbid_uri for whether to use a MusicBrainzID tag, so I think a use_album_path_uri config option could (and maybe should) be added pretty much the same way.

[tkem]

@bernd-wechner: Would you mind if we closed this, since it's basically a duplicate/discussion of #29/#46? And for the record: General questions/discussions are of course welcome, but by Mopidy's more-or-less "informal" policies should be delegated to https://discuss.mopidy.com, with GitHub issues being reserved for actual "bugs". This also has the benefit of more people having the opportunity to throw in their "2 cents" - though core devs such as @jodal and @adamcik are known have been notably silent on that channel lately ;-)

[bernd-wechner]

No worries, close away. I think #46 in particular covers it well!