I have found many duplicated album entries in slimserver 6.5b3. As it
looks, every single track has its own album.
It seems that slimserver 6.5b3, the separated scanning process differs
from how it was done up to 6.3.1.
There are multiple 'Importers' that can put entries into the database,
one is Slim::Music::MusicFolderScan. This uses Utils::Scanner, which in
turn instantiates objects in Slim::Schema, which makes them persistent.
On from line 1868 in Slim/Schema.pm, we can see:
Code:
--------------------
# Go through some contortions to see if the album we're in
# already exists. Because we keep contributors now, but an
# album can have many contributors, check the disc and
# album name, to see if we're actually the same.
#
# For some reason here we do not apply the same criterias as below:
# Path, compilation, etc are ignored...
#
# Be sure to use get_column() for the title equality check, as
# get() doesn't run the UTF-8 trigger, and ->title() calls
# Slim::Schema::Album->title() which has different behavior.
my ($t, $a); # temp vars to make the conditional sane
if (
($t = $self->lastTrack->{$basename}) &&
$t->get('album') &&
blessed($a = $t->album) eq 'Slim::Schema::Album' &&
$a->get_column('title') eq $album &&
(!$checkDisc || ($disc eq ($a->disc || 0)))
--------------------
This means that contrary to the comment, the path is *NOT* being
ignored. What is done here is that the creation of a new album is
skipped only if the album title is equal to the album title of the last
track that was being inspected (a static object named lastTrack which
enables this ugly side-effect programming). So, if you scan consecutive
tracks of an album, all goes well, *PROVIDED* that the scan delivers the
tracks in the right order.
I have created short links to my music files in the form of
"01/23456.mp3", where the numbers correspond to a CRC of the file's MP3
data (not including ID3 tags). So, even retagging or renaming the
original file does not alter the file's location and an entry in an M3U
playlist shows up O.K. at any time. Since the actual links are thus
ordered into 256 different directories, they appear in random order for
slimserver's scan.
You would get a similar effect if you stored the files into a big
directory or if you organize your files by artist and not by album.
There is no such thing as a guaranteed sort order, so the "last track"
is meaningless for that purpose. You have to put all tracks of an album
into the same directory in order for this to work. And don't you even
think of putting multiple CDs into the same folder and naming them "...
CD-x-".
What had to be done was a comparison into the database, if an album
with that name for this artist does already exist and re-use it if that
is the case.
If the database schema were correct, one could have enforced the
correct behaviour by declaring the table "albums" as being unique to
the combination of album title and artist name. This does not save one
from coding it correctly, however. You only get an error if you don't.
--
meyergru
------------------------------------------------------------------------
meyergru's Profile: http://forums.slimdevices.com/member.php?userid=1980
View this thread: http://forums.slimdevices.com/showthread.php?t=27424
_______________________________________________
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
