Bugzilla – Bug 1723
visualizer doesn't work when you change songs from the web interface
Last modified: 2009-09-08 09:28:17 UTC
using trunk revision 3576. have an sb1 and an sb2 synchronized. if i change songs using the web interface the visualizer doesn't kick on. but if i change it using the remote the visualizer works fine. also when it plays out to the next song the visualizer seems to come back on.
actually... it doesn't come back on until you change your visualizer settings.
I assume you mean the side visualizer? Or the screensaver one?
is this only when synced? I've never noticed this before, but I'm rarely syncing players.
hmmm, i think you're right, i t hink this may only happen when synchronized.
oh also in regards to vidur's question, seeing this with the side visualizer, yes. does not seem to affect the screensavers.
Turns out that it's not specifically related to synchronization either. There are various circumstances (synchronization being one of them) where a client's update() method isn't called when it starts playing. The $client->update() method calls $client->visualizer() for a SB2 and that's what sets up the visualizer. The visualizer display rectifies itself if you start scrolling with the remote or the Now Playing screensaver kicks in i.e. the next time update() is called. You can recreate this problem with a standalone SB2 by just playing an album/artist/track anytime the SB2 is not in Now Playing mode. Playlist modifications ('playlist play' or 'playlist add' in Slim::Control::Command::execute syntax) on their own don't trigger an update(), only the 'play', 'pause' and 'stop' commands do. We may need to do a $client->update() somewhere in Slim::Player::Source::playmode() to catch all cases. I'm tempted to push this to post 6.1 since it's not critical and the display rectifies itself in most cases.
Well, 'playlist play' is effectively a "clear", "add" and "play", which shoudl trigger an update, just like play does, no? 'playlist add' should be silent... I'm good with punting on it, tho' if it's risky at all. I propose this patch: --- server/Slim/Control/Command.pm (revision 3706) +++ server/Slim/Control/Command.pm (working copy) @@ -1733,6 +1733,7 @@ if (defined($index)) { Slim::Player::Source::jumpto($client, $index); + $client->update(); } $callbackf && (&$callbackf(@$callbackargs));
Kevin: can you try this patch and let me know if it works for you? I only have one player here...
The patch doesn't catch many of the ways tracks can be played/added via the web interface. It seems that verbs like "loadalbum" and "loadtracks" don't go through the load_done bottleneck. The right place to add the update() may be Source.pm.
Right, but loadalbum doesn't change the playback, so the update isn't needed, right?
Sho' does change playback - that's what "loadalbum" and "loadtracks" were meant to do.
Punting for 6.1, since the display rights itself easily (when screensaver is activated or IR commands are received).
It could even be an option to place it in Player::Playlist::refreshPlaylist. you can check against $client->currentPlaylistModified or $client->currentPlaylistChangeTime if you want to make sure to only call if the playlist has changed.
Vidur's probably right, if the playmode changes, an appropriate visualizer update should take place...
Is this still an issue for 6.5?
Does this still happen?
Kevin?
Ping!
Ross, could you haev a look at this, too?
SlimServer Version: 6.5b1 - 9491 - Windows XP SB2 and SB3 synced. I played a song, selected a different song from web UI, visualizers don't stop working, they act as they should. In other words, fixed.