Bugzilla – Bug 1582
CURTRACK written but not used for saved playlists
Last modified: 2011-03-16 04:39:16 UTC
When you save a playlist a line is added at the top of the m3u file specifying the current track: #CURTRACK 12 However, when loading the playlist later, it appears to ignore this line and always begins playing track 1. Related to this, it would be great if the writeM3U() method could be called on every track change when playing from a saved playlist (i.e. non-MAC-address playlist). That way it will always remember your location in the playlist the next time you load it. I'll probably take a crack at fixing this myself, but I'm not familiar enough with the code yet. :) I also noticed the writeM3U method call in Slim::Player::Playlist line 571 isn't called in such a way as to write the extra EXTINF and CURTRACK lines to the file. Is that a bug? Slim::Player::Playlist: Slim::Formats::Parse::writeM3U($playlistref,$playlistname,$playlistname); Slim::Control::Command: Slim::Formats::Parse::writeM3U( $annotatedlistRef, undef, catfile(Slim::Utils::Prefs::get('playlistdir'), $savename . ".m3u"), 1, Slim::Player::Source::playingSongIndex($client), );
in the case of saving the current playlist for a given player, it is intentional not to write EXTINF in order to speed up reloading (which is still slow) if you decide to take this stuff on, try looking at bug479 for some other requested status info to be stored in the m3u (must be in such a way that it doesn't break using the m3u with other systems)
reviewing the code, i believe that writing the CURTRACK for saving playlists is incorrect. The CURTRACK seems to be there, really for current playlists only (the __<MAC ADDRRESS>.m3u playlists. On startup, if you had a previous playlist and you have your server set to remember client playlists, then it should startup where it left off via Control::Command::execute, playlist->resume. However, it would seem a reasonable enahancement to have a saved playlist resume on load if CURTRACK is found. Unsure how much of a performance hit may be taken if the server has to write out a playlist at every track change. For large playlists, this will very definitely cause dropouts on anything prior to SB2. Possibly not so painful when playlists become stored in the db. I'm going to mark this as an enhancement (unless you find that remembered, not saved, playlists arent resuming).
MAC address playlists do resume properly. I didn't think about the performance hit from saving large playlists frequently, so yeah it'll have to wait until they're in the DB.
I'll try and work this in with the playlists-in-db code.
This isn't going to make the 6.1 bandwagon...but we'll get to it.
Fixed in subversion change 4073