Bug 17933 - Slim::Formats::Playlists::M3U::read fails with relative paths
: Slim::Formats::Playlists::M3U::read fails with relative paths
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Formats
: 7.7.1
: PC Ubuntu Linux
: P3 major with 2 votes (vote)
: 7.8.0
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-24 10:05 UTC by Keith Mickunas
Modified: 2014-01-28 08:37 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Mickunas 2012-03-24 10:05:08 UTC
When scanning a simple m3u file only the odd entries are placed in the playlist within sbs, and they are listed twice, the even entries in the file are ignored.  This appears to be an issue when relative file paths are used within the playlist. 

During the first pass through the loop a relative path stored in $trackurl will be invalid, so the if at 139 will fail, sending it into the else where different combinations of paths are tried.  When a valid path is created it is added to the playlist and the loop for @mediadirs is exited with a last statement at 171, this bypasses the resetting of the local variables at line 175.

On the next run through the main loop $trackurl will still contain the valid path just found, it will not be reassigned from $entry and will pass the if statement at line 139, then it is placed in the playlist again, an then the local variables are reset.  

Placing the line 
($secs, $artist, $album, $title, $trackurl) = ();

at the top of the while loop, around line 55, should fix this problem.
Comment 1 Ralph Irving 2012-03-25 04:13:37 UTC
*** This bug has been confirmed by popular vote. ***
Comment 2 SVN Bot 2012-03-25 21:23:15 UTC
 == Auto-comment from SVN commit #33903 to the slim repo by mherger ==
 == http://svn.slimdevices.com/slim?view=revision&revision=33903 ==

Fixed Bug: 17933
Description: fix variable initialization
Comment 3 hagan 2014-01-28 08:37:33 UTC
I don't think the fix is correct.
Please see bug 18066 for more information.