Bugzilla – Bug 1220
Now Playing list in web interface doesn't always update correctly
Last modified: 2008-08-18 10:54:04 UTC
There seem to be two cases of this: 1) The currently playing song isn't updated for skins that highlight this song. 2) If you change skins in Server Settings (not by overriding using a skin-specific URL), the playlist uses the old skin's HTML.
Created attachment 384 [details] update after skin change updates playlist mod time on a skin change so that the playlist render will happen. not many places were we are NOT updating playlist time now. only case where we really get any benefit is the META refresh, and only when it doesn't happen near a song change.
as for the other part of this bug, fishbone playlist seems to update ok, default doesn't. this is odd, since teh code to control the update should be happening in the server.
aha...seems intermittent. I guess the skip to the next song isn't always happening in just one part of the code.
*** Bug 1253 has been marked as a duplicate of this bug. ***
*** Bug 1273 has been marked as a duplicate of this bug. ***
Created attachment 390 [details] update on track start trigger playlist modified time on a trackStartEvent to catch all song changes. should allow all skins to update the highlighted track to 'currentsong'.
I just updated SVN to get this fix, and it seemed to work for a few tracks (in Fishbone), but since then it's been back to the old not-updating. Like, I listened to a four song EP, and it looked to be refreshing properly until it just stuck on highlighting track 3, even after it was completely finished playing. I'm listening to a completely different album, and the web interface is still highlighting track 1 even though I'm listening to track 10. The only funny business I can think of during that is I did pause and then resume track 3 of that first EP.
*** Bug 1260 has been marked as a duplicate of this bug. ***
how about d_source and d_playlist log output for a case where this is happening. d_playlist will show the playlist caching status, and d_source will hopefully give a clue as to which playback command path is still being missed. I would have thought trackStartEvent covered all new track starts. This is a bit worrying if it isn't. I wonder what else this will cause us to trip over.
I'll get some logs of this tomorrow, but let me give you the exact circumstances of what I'm doing right now as it misbehaves. I've got a SqueezeBoxG at home, and I've got an SSH tunnel from work to the home server where I listen with Softsqueeze. When I have both connected, so that the SlimServer web interface gives me a choice between which player to control, I find that the work Softsqueeze has its track highlighting update properly, but the indicators for the SqueezeBox at home don't change. This is even the case if only one player is playing music at the time. It's never transpired since it's been acting up this way that the work one has not updated while the home one has, but I don't know if that's really significant. When I'm at work tomorrow, I'll play some tracks there and at control the home player and try to get some debugging logs.
Created attachment 401 [details] --d_source and --d_playlist log Okay, I've attached a log of my SlimServer as I played tracks from work just as I described in my comment last night. To reiterate: I have two players connected to the server: Stereo (my home stereo) and Work (SoftSqueeze). I had both players on and running and was using SlimServer's web interface from work. I started playing an album on Stereo and I let it play for four songs, stopping the player in the middle of the fourth. That should be enough data to see what happens at track change time. Throughout the whole time, the first track remained highlighted in the web interface in Fishbone. The browser I'm using at work is Firefox 1.02 on WinXP. The home server is Ubuntu Linux 4. The SlimServer version was the newest trunk version in SVN at the moment.
Vidur believes that this is fixed in the latest nightly. Please confirm and reopen if it's not. Thanks.
I don't seem to have an option to reopen this bug, but I'm not seeing difference in behavior as of right now. The only player active in the interface is my SBG player attached to my stereo. I'm playing an album right now, and it's playing track 4, but track 1 is still highlighted. I'd reopen it if I could but the only option by the Commit button is "Leave as RESOLVED FIXED" and there's no place I see to change it anywhere else.
Kevin, seems like the Source.pm patch sets the playlistChangeTime in response to a trackStart event (reported by SB2), but not in openSong (for SB1 and older). Seems like the right thing to do would be to add: $client->currentPlaylistChangeTime(time()); inside the if (!$client->reportsTrackStart()) clause in openSong (before line 1399 of r3007). I'd post a patch, but my tree has several changes in it. What do you think?
That would make sense as to why my SoftSqueeze is fine (it emulates SB2 in its newest versions, if I'm not mistaken) but my SBG doesn't update.
That does look suspiciously like the hole I was looking for. I can merge that in tonight.
Beat you to the punch. Fixed in trunk. Will move to the 6.0.x branch shortly.
And in the branch (change 3032). The trunk revision is change 3031.
Woot, that's the stuff. Thanks, guys.