Bugzilla – Bug 15868
While playing songs from the USB if I switch between the songs the old song title re-appears for several seconds.
Last modified: 2011-05-17 16:28:04 UTC
1. Playing music from a folder on USB. I call the title X 2. While the music is playing I go to a new song on another directory 3. Start playing the new song. I call the title Y 4. The new song starts playing with its title, Y. 5. After almost a second the title is switched to X. 6. After almost another second the title is switched back to Y. Do not understand why the title is switched!
Yes, I'm seeing this too. It may be a factor of how much slower TinySC is than SbS running on a more powerful computer. That is, maybe it's always done this, but it could be that the transitions normally happen so quickly that it isn't as noticeable.
There may be another explanation, but this is the most likely: SP (the controller) maintains a cache of the most-recently received playerstatus information. This includes the title/artist/album etc. This information is used to populate the NP screen. When a manual track-change event is triggered, the server code associated with handling that trigger sends what is known as a show-briefly to the controller, with just the title of the new track. This new title is displayed for a short period - in bug 15815 it was raised to 3s. At various points associated with playing a new track, events occur which could trigger the server to send a new playerstatus. The new status is not sent immediately but rather delayed a little so that only the last trigger in a short period will actually cause the new playerstatus. This is because generating a new playerstatus is expensive and we want to avoid generating multiple such messages unnecessarily. The delay for a 'playlist newsong' event, which occurs when the new track starts playing (or, at least, when the server has received the status information that it has started playing) is 0.3s. Usually, therefore, the associated playerstatus should be sent while the show-briefly is still showing. If the server is slow then it is possible that the show-briefly will time out before the new playerstatus is generated, sent and received. It seems that this is particularly likely when all three elements (player, server and controller) are running on the same hardware (fab4). I suspect that this is due to scheduling issues. I do not see this with a single player (fab4 or baby) connected to a remote TinySC (slow USB disk). Nor do I see it with Fab4 playing from its local TinySC (fast SD card). I do see it with three babys synced and connected to a remote TinySC. All the above are MP3s. I also tried with a fab4 connected (both local and remote) to a TinySC (slow USB disk) playing FLAC and could not reproduce the problem. In summary, I have been able to reproduce it only with synced players. I do believe that there may be other occasions which could provoke these symptoms - probably dependent upon things like the NP view in use, the codec and even codec parameters (FLAC at highest compression levels is very CPU-intensive for the decoder). I would classify this as a duplicate of bug 15815 but I will not mark it as such nor reopen the old bug. Instead, I propose to mark this bug with target 7.5.X, because I believe that further improvements for 7.5.0 are not warranted.
I see a couple of options: 1. Remove the show-briefly altogether. The problem with this is that the user gets less timely visual feedback of having initiated a skip. 2. Make display of the show-briefly permanent, only to be replaced by a playerstatus update. I think we would need to identify such show-brieflies specifically so that SP can act appropriately.
I'm able to reproduce this bug, but only with tinySC and only when playing a longish playlist constructed via My Music->Music Folder (aka Browse Music Folder or "BMF"), and then only occasionally. For those reasons I do not think that this is a 7.5.0 issue. Any fix for this would impose some risk to the common case scenario. I tested a 160 track BMF playlist with fatSC and cannot reproduce. I tested a longish playlist on tinySC but not adding tracks through BMF and could not reproduce. Alan reports he can also reproduce if 3 or more Squeezeplay-based players are synced to tinySC. This concludes me to believe this scenario happens when the server is so taxed at producing the playerstatus notification on a track skip that it lags, thus showing the stale information briefly before the playerstatus update. Recommend doing nothing for 7.5.0, and pursuing one of the fixes Alan points out in comment#3 for 7.5.x. (it appears Alan's already shifted it to 7.5.x, so we have some consensus there)
This is a quick attempt at the second option that Alan listed in comment #2. It's flawed though, because there are situations where pushing a showBriefly with a duration of -1 isn't also immediately followed by a playerstatus update (e.g., pushing play on a stopped track). In these cases, the showBriefly takes over the track title area and never leaves. === NowPlayingApplet.lua ================================================================== --- NowPlayingApplet.lua (revision 38997) +++ NowPlayingApplet.lua (local) @@ -220,6 +220,9 @@ function _setTitleStatus(self, text, duration) log:debug("_setTitleStatus", text) + -- bug 15868: a duration <= 0 should send false to Label:setValue() for the duration arg + duration = duration > 0 and duration + local nowPlayingTrackInfoLines = jiveMain:getSkinParam("NOWPLAYING_TRACKINFO_LINES") local msgs = string.split("\n", text) if nowPlayingTrackInfoLines == 2 and self.artistalbumTitle then === Commands.pm ================================================================== --- Commands.pm (revision 39008) +++ Commands.pm (local) @@ -39,7 +39,6 @@ use Slim::Utils::Scanner; use Slim::Utils::Prefs; use Slim::Utils::OSDetect; - my $log = logger('control.command'); my $prefs = preferences('server'); @@ -916,6 +915,9 @@ my $jiveIconStyle = shift || undef; if ($client->isPlayer()) { my $parts = $client->currentSongLines({ suppressDisplay => Slim::Buttons::Common::suppressStatus($client), jiveIconStyle => $jiveIconStyle }); + if ($parts->{jive}) { + $parts->{jive}{duration} = -1; + } $client->showBriefly($parts, { duration => 2 }) if $parts; Slim::Buttons::Common::syncPeriodicUpdates($client, Time::HiRes::time() + 0.1); }
another way to reproduce: FatSC (7.5. trunk) Radio + Fab4 synced Random song mix, playlist size 40+ skip track reproduces the issue on the radio, but not the fab4 the DB improvements to the current playlist queries that Andy made last week are only in embedded, so I wonder if this will still be an issue in this case after that gets folded back. Regardless, this is something to address, but post 7.5.0
I am seeing this on both a Radio as well as a Touch. Server (7.6.0 - r31644 using DBD::SQLite 1.30_06 (sqlite 3.7.2)) is on a QNap T110 (not too slow) with a medium-sized library (~50 GB). I get this behavior on pretty much every single manual song change - it actually takes 2-3 seconds for the proper title to display. Given that the new song starts playing almost instantaneously and the title information should really only be a few bytes, I am really wondering why there is such a massive (and slightly annoying) delay. Would be great if this could be fixed.
== Auto-comment from SVN commit #32234 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=32234 == Fixed bug 15868: While playing songs from the USB if I switch between the songs the old song title re-appears for several seconds. Finally tracked down where to fix this. Make the displaystatus associated with the new track have a 10s duration. This will be replaced with the new track info as soon as it arrives.
== Auto-comment from SVN commit #32236 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=32236 == bug 15868: While playing songs from the USB if I switch between the songs the old song title re-appears for several seconds. Finally tracked down where to fix this. Make the displaystatus associated with the new track have a 10s duration. This will be replaced with the new track info as soon as it arrives.
== Auto-comment from SVN commit #32237 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=32237 == bug 15868: While playing songs from the USB if I switch between the songs the old song title re-appears for several seconds.
Current song title goes away after about 2 seconds when switching to another track (on Touch/TinySC) 7.6.032427