#246 multi-artist albums sometimes treated as separate albums

[Florian Will]

Possibly related to bug 140: http://sourceforge.net/p/minidlna/bugs/140/

When adding a new multi-artist album (i.e. sound track collection) and the new files are picked up by minidlna through the inotify feature, the "Albums" directory served through DLNA has multiple entries for that album. There is one sub-directory per artist who has a song on the album, containing only the songs by that artist. All those album directories have the same name (album title).

After deleting the files.db and restarting minidlna to force a complete re-scan, the "Albums" directory looks as expected: Only one single sub-directory for the compilation album, containing all the songs from various artists.

Reproduced on minidlna 1.1.2 (on Debian with Debian patches) and 1.1.3 (from Arch Linux, so probably pretty much vanilla).
Downstream bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734383

[Florian Will]

I think I know why this is happening, or at least I have an idea that is backed up by some experiments with the code.

It only happens when actually moving the files into the minidlna media directory from a different place on the filesystem. This causes inotify to send "IN_MOVED_FROM" events (for the location where the files were stored previously). inotify.c thus calls "inotify_remove_file" for the old location that was outside of the minidlna media directory. One of the first things that function does is invalidate the scanner cache.

Now IN_MOVED_TO is reported with the new location inside the media directory, inotify_insert_file is called, and the file is added to the db successfully. Because there is no album with the track's album name by the track's artist in the minidlna DB, a new album container is created for the track. This goes on with alternating IN_MOVED_FROM and IN_MOVED_TO signals, so the scanner cache can't be used. A new album container is created for every track created by a yet-unknown artist.

OTOH, when doing a full scan, the scanner cache is not invalidated between insertions and because the album name of the last track is exactly the same as the album name for the current track, the same album container is reused, even though the tracks don't share the same artist. This is because the scanner cache doesn't take artist names into account.

I realize this is a pretty difficult situation because it's unclear what is the right thing to do. Are there really separate albums by different artists using the same album name? In that case, the scanner cache should be fixed so it doesn't ignore the artist name. If album names are universally unique (to some extent, which I do hope), the "lookup existing containers to see if a container for this track already exists if the cache can't be used" should be changed to match the scanner behaviour and ignore artist name etc. (so it only matches based on the album name.)

Maybe this should be a configuration option, as I strongly prefer the "group by album name only, ignore artist name" option. Users without compilation albums who have loads of "Love Songs" albums might prefer the "group by artists AND album name" solution. Or maybe some heuristic based on file system location of tracks (group tracks from the same directory together, even though they have different artists – as proposed by the Debian downstream bug reporter).

[Florian Will]

This simple patch seems to get rid of the difference in behaviour between inotify-added files and full rescans regarding compilation albums. The artist name is ignored when looking up existing containers and new songs are added to an existing album container that shares its album name with the new song.

See commit msg for drawback. Citing it here:
Subject: [PATCH] Ignore artist when looking up existing container

This prevents creation of multiple album containers for compilation
albums (i.e. one separate album for each artist) when adding files via
inotify, which causes the scanner cache to be invalidated all the time.

OTOH, different albums with identical names ("Greatest Hits", "Love
Songs") are now listed as just a single album in the "Album" container.
This might be solved using some heuristic based on music file location
(same directory / different directories).

The new behaviour is usually the same as encountered when doing a full
rescan, because there's a scanner cache that is used during full rescans
and that cache ignores artist names as well.