Bugzilla – Bug 15020
Add on screen notification when preset button selected on front panel
Last modified: 2011-01-13 14:56:46 UTC
I have several large playlists assigned to the preset buttons on the front of the radio. When these are selected there is a lengthy delay before the radio takes action and begins to play back the selected preset, probably due to the size of the playlists in question (all of them are at least several hundred tracks). As a result it might appear that the preset button was not correctly recognized as having been pushed and the user continues to push the button trying to get some action out of a player. As a result, it further slows down the start up of the selected playlist and also results in the audio changing multiple times as the playlist is seen as having been "reselected" multiple times. There should be an info pop up on the screen of the radio that indicates the radio is aware that the preset button is selected as well as info about the preset contents. This could then be followed by a "waiting" or "loading" info balloon while the playlist is being readied for playback.
I voted for this bug, but I think that for reasonably sized playlists (say under 100 items? under 50?) this behavior may be a little burdensome, as you'd see an unnecessary popup or spinny before moving into Now Playing. If it could be triggered only for larger playlists, it would be better. Also see bug 14222 - bump for undefined presets. I don't think that behavior should change.
Please implement this on the Perl/server side, not SqueezePlay. One of my unexpected plugin successes is KidsPlay, which allows Perl-based remapping of the preset buttons on Boom and Radio. Currently it seems that Radio keeps track of what buttons have presets, and a short press on a button with a preset results in the Radio powering on and sending a "button" CLI command. This means KidsPlay cannot stop Radio from powering on (I've been considering opening a bug to ask that to change, adding something like "if (! $client->power()) { $client->execute(['power','1']); }" to the button handling), but can stop the preset from playing. If this enhancement is implemented inside the server-side handling of the "button" command, there should be no impact on KidsPlay. Something like # indicate we're trying to play the preset if ( $client->model() eq 'baby' ) { $client->showBriefly(...); } # now actually play the preset ... Thanks.
(In reply to comment #2) > Please implement this on the Perl/server side, not SqueezePlay. > > One of my unexpected plugin successes is KidsPlay, which allows Perl-based > remapping of the preset buttons on Boom and Radio. Currently it seems that > Radio keeps track of what buttons have presets, and a short press on a button > with a preset results in the Radio powering on and sending a "button" CLI > command. This means KidsPlay cannot stop Radio from powering on (I've been > considering opening a bug to ask that to change, adding something like "if (! > $client->power()) { $client->execute(['power','1']); }" to the button > handling), but can stop the preset from playing. If this enhancement is > implemented inside the server-side handling of the "button" command, there > should be no impact on KidsPlay. Something like > > # indicate we're trying to play the preset > if ( $client->model() eq 'baby' ) { > $client->showBriefly(...); > } > # now actually play the preset > ... > > Thanks. The only issue I see with server side implementation (which does make sense btw) is how long the delay would potentially be between the button press and info display. If the delay is notable then it would defeat the entire purpose of making this change. Could a compromise be that the button press on the radio side displays a very basic message that the button has been selected and subsequent information and handling comes from the server?
Anandh notes this bug is important from the marketing perspective.
My recommendation: option 1 (preferred). Use a spinny with "loading" text (if we know the name of the item being loaded, even better - put "Loading" at the top and "[itemname]" at the bottom,) then begin playback (get rid of the showbrieflies if this option is implemented). option 2: use showbriefly "Preset #x selected" when number of playlist/album tracks size > y (y is a number of items long enough to present a noticable problem). Not sure if this is feasible, or if the system is smart enough to detect the playlist length before loading. I can also see a risk of competing showbrieflies here (if the load time is quicker than we think). Just curious, canyoncarver... how long is the playlist in this case. What's a "large" playlist to you? How long is the delay?
(In reply to comment #5) > My recommendation: > > option 1 (preferred). Use a spinny with "loading" text (if we know the name of > the item being loaded, even better - put "Loading" at the top and "[itemname]" > at the bottom,) then begin playback (get rid of the showbrieflies if this > option is implemented). > > option 2: use showbriefly "Preset #x selected" when number of playlist/album > tracks size > y (y is a number of items long enough to present a noticable > problem). Not sure if this is feasible, or if the system is smart enough to > detect the playlist length before loading. > > I can also see a risk of competing showbrieflies here (if the load time is > quicker than we think). > > Just curious, canyoncarver... how long is the playlist in this case. What's a > "large" playlist to you? How long is the delay? I think I like option 1 honestly. In true nerd fashion I made a short video to demonstrate. Playlist in this example is 2,000 tracks. I have larger playlists with up to 8,000 tracks that take notably longer to load. If the playlist has never been loaded (server of SB radio has rebooted) it seems to take longer. The first time I tried this I think it took a good solid 7-10 seconds to respond on the playlist with 2,000 tracks. http://www.youtube.com/watch?v=aEyUqp-OteI
Created attachment 6301 [details] Patch to push showBriefly to squeezeplay devices when playable preset is pressed This isn't exactly the solution requested, but if this patch is applied it will push a message to squeezeplay devices that says something like: Preset #1 Flight of the Conchords but the duration of the message is in no way tied to how fast the playlist loads. We aren't getting data from the server that would be easy to see when the preset button command's intent was actually completed to the point of playing that preset.
Leaving bug_meeting tag on this bug, but marking unprioritized until it's discussed.
Sorry, not entirely clear in the patch. The patched file is Slim::Buttons::Common
I would love to test the patch but don't think it will be easy for me to compile for use on my WHS installation of SB Server 7.4.1. Hope we see some feedback on this. What is the default value for ShowBriefly? I would think 3 seconds would be plenty for this.
Discussed this in the bug meeting...the showBriefly is almost certainly going to stay, but I'm also going to investigate if there's a means for squeezeplay to know if it can recognize when the playlist is done loading and playback has begun.
== Auto-comment from SVN commit #29272 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29272 == Bug: 15020 Description: showBriefly message pushed to squeezeplay players when a defined preset key is hit
the patch is checked into 7.5 r29272 this option is the remainder of the bug option 1 (preferred). Use a spinny with "loading" text (if we know the name of the item being loaded, even better - put "Loading" at the top and "[itemname]" at the bottom,) then begin playback (get rid of the showbrieflies if this option is implemented). What I just checked in bumps the priority down a couple pegs though, and I'm even a bit hesitant about a spinny for this because of the potential negative UI impact in the more typical case, a preset that loads quickly.
Moving lower-priority bugs to next target
The remainder of this bug isn't going to make any near-term priority list.