PDA

View Full Version : Duplicate tracks due to paths in playlist?



ModelCitizen
2006-07-14, 06:36
I've noticed that quite a few of my albums include duplicate tracks. I'm pretty sure that it's only been a problem since I started installing 6.3 versions. I'm on XP Pro and run Fishbone Tan.

The reason for at least some of these instances appears to be related to the path to the track used in the playlist. For instance, if I view the song info for a duplicate track the path for one is listed as:

D:\A-M\10CC - Hits [1996]\01 - The Wall Street Shuffle.flac
and the other as:
\\Music\maxtorot3\A-M\10CC - Hits [1996]\01 - The Wall Street Shuffle.flac

\\Music is my dedicated laptop. Drive D (The Maxtor OneTouch 3) is the one with my music folder and playlist folder. Slimserver runs from my C drive on Music.

The playlist references the track as:
..\A-M\10CC - Hits [1996]\01 - The Wall Street Shuffle.flac

i.e. it looks up to the root of D from the playlist directory and then down to my A-M music directory.
Slimserver references my Music and Playlist directories as:

D:\SB_Shortcut (with shortcut to music directories A-M and N-Z)
and
D:\Playlists

I'm uncertain if this is a problem with the way Slimserver handles paths or if I should be configuring paths differently.
I'm quite surprised no one else has reported seeing this though (which always makes me doubt myself). Any help would be most appreciated.

MC

meyergru
2006-07-14, 11:30
Yup, I noticed that one, too, but with Slimserver under Linux.

There is a problem with 6.3.0 IMHO.

If you specify a path for the 'audiodir' setting in the server settings, it is being replaced by the real pathname.

In my setup, I have a symlink from '//music/m' to the real path, say '/bigdisk/m'. Since '/bigdisk/m' is exported as a Samba share '\\music\m', I can switch back and forth with my playlists under iTunes for Windows. The pathnames in my playlist could be '\\music\m\Abba\Gimme.mp3' and since Slimserver changes every '\' to '/', it comes out as '//music/m/Abba/Gimme.mp3' under my Linux Slimserver. This works out just fine.

That is BEFORE 6.3.0. Now, '//music/m' is silently replaced by '/bigdisk/m' and thus, the first observation was that every title is doubled in my library (since the old pathnames are still there). You can see this if you enter the path into the settings and restart Slimserver afterwards. When you enter the settings page again, the pathname has been changed.

This is a really BAD THING(tm). Slimserver should not try to be so smart. I am currently investigating this suspect:



.../Slim/Utils/Misc.pm:

# I hate Windows & HFS+.
# A playlist or the like can have a completely different case than
# what we get from the filesystem. Fix that all up so we don't create
# duplicate entries in the database.
if (!Slim::Music::Info::isFileURL($fixed)) {

$fixed = canonpath(fixPathCase($fixed));

# Bug: 2757
if (-l $fixed) {
$fixed = readlink($fixed);
}
}


The bugfix for bug #2757 seems to follow symbolic links and was not present in 6.2.2.

ModelCitizen
2006-07-15, 00:50
MeyerGuru. I am not alone.
After I had posted it occurred to me to look at my Windows Shortcuts. The shortcuts to my music directories had been written in the UNC form - \\Music\maxtorot3\A-M. The path to Music and Playlists set in SlimServer used local paths (i.e. D:\SB_Shortcuts and D:\Playlists). I've now set SlimServer to use UNC paths and rescanned and all seems to be OK. No duplicates.
I am happy as I can still use my playlists and shortcuts from other machines on the network (i.e. via Slimserver 6.5 and Foobar2000).

The only thing I am not happy about is how long it took me to sort this out and how long I lived with duplicate tracks.

meyergru
2006-07-15, 03:25
Yes. Using UNC paths is almost always the correct choice. I have done this since the times of my Audiotron, which could use Samba shares and M3U playlists but had no notion of drive letters. So, I simply use UNC paths in my playlists from that time.

With 6.3.0, however, Slimserver is broken since it tries to out-smart what I give to it.

I have now commented out the readlink() function quoted above and everything works fine again.

That makes two positions in the code I have to change on every new Slimserver release. The other one being the SQLite pragmas for using RAM instead of temp files.

stinkingpig
2006-07-16, 17:20
....

>
> That makes two positions in the code I have to change on every new
> Slimserver release. The other one being the SQLite pragmas for using
> RAM instead of temp files.
>
>
Seems like that's a UI option in 6.3, are you sure you need to do this? See
Server Settings > Performance > Database Temporary File Tuning (SQLite).

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

meyergru
2006-07-26, 14:32
....

>
> That makes two positions in the code I have to change on every new
> Slimserver release. The other one being the SQLite pragmas for using
> RAM instead of temp files.
>
>
Seems like that's a UI option in 6.3, are you sure you need to do this? See
Server Settings > Performance > Database Temporary File Tuning (SQLite).



Correct, just found it.

The other thing might be ignoreable, too. If every path is being replaced by its "real path", this will apply to entries in playlists, too. So, if one clears out the whole database and just rebuilds it, everything might be fine, PROVIDED THAT one does not want to modify or create M3U playlists with Slimserver, but just import them.

Modifying them does not work that well, anyway, since pathname clearing strips off '//server/share/path/title.mp3' to '/server/share/path/title.mp3'. So, such playlists do not function if they are re-exported to Windows music clients.