Whats even more:
I have changed the relative Windows M3U file into an absolute file (using a text
editor) and then the playlist gets loaded into SlimServer without any problems...

CHANGED:

#EXTM3U
#EXTINF:0,Tchaikovsky-Martha Argerich, piano-Piano Concerto #1 - Allegro non
troppo.MP3
..\Tchaikovsky\Martha Argerich, piano\Tchaikovsky-Martha Argerich, piano-Piano
Concerto #1 - Allegro non troppo.MP3

#EXTINF:0,Mozart - Rondo Alla Turca.mp3
..\Classical\Mozart - Rondo Alla Turca.mp3

#EXTINF:0,Chopin, Fr�d�ric-The Very Best of Chopin-Waltz in C sharp minor.mp3
..\Chopin, Fr�d�ric\The Very Best of Chopin\Chopin, Fr�d�ric-The Very Best of
Chopin-Waltz in C sharp minor.mp3

INTO:

#EXTM3U
#EXTINF:0,Tchaikovsky-Martha Argerich, piano-Piano Concerto #1 - Allegro non
troppo.MP3
G:\MySounds\Tchaikovsky\Martha Argerich, piano\Tchaikovsky-Martha Argerich,
piano-Piano Concerto #1 - Allegro non troppo.MP3

#EXTINF:0,Mozart - Rondo Alla Turca.mp3
G:\MySounds\Classical\Mozart - Rondo Alla Turca.mp3

#EXTINF:0,Chopin, Fr�d�ric-The Very Best of Chopin-Waltz in C sharp minor.mp3
G:\MySounds\Chopin, Fr�d�ric\The Very Best of Chopin\Chopin, Fr�d�ric-The Very
Best of Chopin-Waltz in C sharp minor.mp3


and then it works....

PS. My playlists are in the directory:

G:\MySounds\MyPlaylists

The severity of this bug should be changed from Enhancement to Normal -- this is
a regression from 5.4.1.  All of my playlists are relative paths*, and they work
with 5.4.1.

* I create them with scripts on my linux box using relative paths, so that they
can be used regardless of the mount-point on both linux and windows boxes on my
network.

ok, I know what is going on with this now (affects bug 1506 too)
given a playlist item of ../../music/artist-song.mp3

this would be converted to /playlistdir/../../music/artist-song.mp3

this messes up the fileURL, thus confusing 6.0+ since it depends on fileURL as a
track identifier. 5.4.1 worked, but STILL causes track count to increment due to
the differing fileUrl

fixPath should probably be changed to translate the path correctly

Created attachment 497 [details]
clean up relative paths

ok, File::Spec::rel2abs is supposed to take relative paths into absolute, but
it appears to be broken for osx and linux.  It might work for windows, but I
haven't tested other than the fact that the output looks right.

the problem was that paths would be like so:
c:\playlists\..\music\file.mp3, which doesn't match c:\music\file.mp3, even
thought they point to the same file.  This causes the db to create a new track,
and it has problems dealing with the \..\ in the path.	In 5.4.1 this problem
didn't happen, but we DID see track counts increase (inexplicably at the time).


what I've done here is let rel2abs do its thing for windows, and for others
simply strip the path back for each /../ in the path.  This now works for the
test files i've set up here, but it definitely needs some testing to be sure
its ok for the rest.  The failure mode is a deep recusion into DBI code (big
memory use and 100% cpu lockup) so we need to make sure this works, even tho
this is the same failure mode we have now.

this should also fix bug 1506

Created attachment 498 [details]
corrected for windows.

I was using the wrong variable for rel2abs.  this has been now tested in linux
and windows, with an m3u and wpl containing relative paths. the wpl was
generated by wmp 10

Fix from kdf commited in subversion change 3280.

This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!