Bug 9289 - The command "playlist play $pl" does not set name of playlist for client
: The command "playlist play $pl" does not set name of playlist for client
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: CLI
: 7.0
: PC Windows XP
: P3 normal (vote)
: 7.4.0
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-26 03:55 UTC by Timo Krieger
Modified: 2009-10-05 14:25 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 Timo Krieger 2008-08-26 03:55:19 UTC
If i use the command "playlist play $pl", the SqueezeBox starts playing the new playlist and the SqueezeCenter web interface displays all the tracks in this playlist.
The new playlist is not set as currentPlaylist for Slim::Player::Client. The playlist is not displayed as current playlist in the web interface either (bottom right).
This affecs the xPL interface and Slim::Control::Request->executeRequest(... "playlist play <item>"...), too

I think the problem is in the Slim::Control::Commands->playlistXitemCommand. The url of the new playlist is checked if its a local file or db entry. If true, the tracks are loaded from the database and is added to the client. In my oppinion the call "$client->currentPlaylist( Slim::Utils::Misc::fixPath($path) );" is missing in this if statement.
Comment 1 Andy Grundman 2008-11-10 08:13:25 UTC
Can you be more specific as to where the problem is?  Can you provide a patch?  Please try 7.3.
Comment 2 Timo Krieger 2008-12-16 00:12:43 UTC
The bug still exists in 7.3.

The problem is that if you start a playlist via the audio.slimserv "playlist play $plName" command, the squeezebox starts playing and the web-interface displays all the tracks, but it does not display the name of the playlist at the bottom of the client part. If you start the same playlist via the web interface the client part displays the name of the playlist ("Current Playlist: plName").

I've created a workaround for the xPL plugin when starting the playlist:

  Slim::Control::Request::executeRequest($client, ["playlist", "play", $plName]);
  $client->currentPlaylist($plName);
  $client->currentPlaylistModified(0);

But I think the bug is somewhere in Slim::Control::Commands->playlistXitemCommand.
Comment 3 Timo Krieger 2008-12-16 02:21:15 UTC
The above workaround is not correct. But this one is:

  Slim::Control::Request::executeRequest($client, ["playlist", "play",
$pl->name]);
  $client->currentPlaylist($pl);
  $client->currentPlaylistModified(0);

The $client->currentPlaylist() needs the playlist object, not the name of the playlist.

So the command Slim::Control::Request::executeRequest($client, ["playlist", "play",
$pl->name]); does not set the new playlist to the specific $client object.
Comment 4 KDF 2009-02-14 00:01:18 UTC
Try something like this (it sets the playlist title for add/load commands after it finds a remote or file url. To test, you'll need the source code and run using activePerl). More needs to be done, as this line is redundant for cases where $path is not a fileURL or remoteURL.

Index: Slim/Control/Commands.pm
===================================================================
--- Slim/Control/Commands.pm	(revision 25017)
+++ Slim/Control/Commands.pm	(working copy)
@@ -1367,6 +1367,7 @@
 	if ($cmd =~ /^(play|load)$/) { 
 
 		$jumpToIndex = 0;
+		$client->currentPlaylist( Slim::Utils::Misc::fixPath($path) );
 
 	} elsif ($cmd eq "resume" && Slim::Music::Info::isM3U($path)) {
Comment 5 Chris Owens 2009-03-16 09:37:48 UTC
We are now planning to make a 7.3.3 release.  Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future.

Thanks!
Comment 6 Chris Owens 2009-03-30 17:30:06 UTC
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out.  If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it.

Thanks.
Comment 7 Chris Owens 2009-03-31 08:52:26 UTC
For some reason Bugzilla did not change the target when I did this yesterday.  Or maybe it was me.  In either case, I'm trying it again.
Comment 8 Timo Krieger 2009-04-06 06:07:28 UTC
This seems to work in version 7.3.2
Comment 9 James Richardson 2009-10-05 14:25:38 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.