Bugzilla – Bug 13079
Rebuffering is too chatty to use a showBriefly
Last modified: 2009-10-05 14:37:04 UTC
Here's a summary of an email chat on this topic. Next step is that Noah will attach a SS of the chosen solution. Tom Wadzinski wrote: - Hide quoted text - It sounds like a conclusion has been reached. Can someone up the bug for this if there is one with the proposed solution? Tom On Mon, Jul 27, 2009 at 11:25 AM, Matt Weldon <mattweldondesign@gmail.com>wrote: - Hide quoted text - Yeah, the thing is, we can't override the standard title bar (at least not completely) since it will kill your ability to navigate well. Also, the titlebar is smaller on non-NP screens, right? Let's go with the first treatment you have for now (the one-liner) and see how it works. I had forgotten about the decision to keep rebuffering on NP-only. On Mon, Jul 27, 2009 at 8:45 AM, noah <noah@bould.com> wrote: - Hide quoted text - Matt, It was my understanding we were limiting the rebuffering feedback to only display on NP? Keep in mind the same method in the previous screen comps could be used through out the UI. We have a titlebar on every screen... Best, noah dijulio bould design 1931 old middlefield way, suite 204 mountain view, ca 94043 T ) 650.965.4509 E ) noah@bould.com W) www.bould.com Matt Weldon wrote: Maybe we can improve the look of the showbriefly? It's kinda gnarly looking at the moment... On Sat, Jul 25, 2009 at 8:56 PM, Matt Weldon <mattweldondesign@gmail.com> <mattweldondesign@gmail.com>wrote: Currently I believe we show the rebuffering message in a showbriefly (with a percentage indicator). And while I hate showbrieflies (or at least am trying to avoid using ones unless totally necessary), I think we should keep using this strategy. Rebuffering can happen any time music is playing IIRC, no matter what screen you're looking at, so the showbriefly works well for now (problems might arise if rebuffering is endless, of course :-). Maybe the back button can kill the showbriefly if it stays up too long. Or maybe rebuffering should time-out after a certain point and display an error message.) In any case, though these look great, at most these would have to be a special version On Fri, Jul 24, 2009 at 7:06 PM, noah <noah@bould.com> <noah@bould.com> wrote: Hi All, What is a usual time limit for rebuffering? I realize that it depends on connection type, etc., etc., however, it seems like rebuffering should be between 3-10secs? Or fairly quick. My instinct is to display some support info for this, but not get too crazy. With this in mind please see attached screen comps of integrating this into the titlebar. Kind Regards, noah dijulio bould design 1931 old middlefield way, suite 204 mountain view, ca 94043 T ) 650.965.4509 E ) noah@bould.com W) www.bould.com Tom Wadzinski wrote: Just to clarify, the suggestion is to have an indicator of some sort on just the NP screen in the titlebar area? Sounds very nice to me (bonus if it shows a animation or percentage to show how far along the buffering is)... The actual rebuffering can happen anytime. Tom On Fri, Jul 17, 2009 at 3:18 PM, noah <noah@bould.com> <noah@bould.com> <noah@bould.com> <noah@bould.com> wrote: Hi Tom, The plan as I understood it was to have the "waiting" indicator (or spinny as it is commonly referred) in the titlebar. Alternatively, we could have the text in the titlebar/status bar change while it is rebuffering to include a numeric value. Basically we need to integrate the information so that it is not jarring to the user. Does the rebuffering happen on menu's other than Now Playing? Matt, Thoughts? Kind Regards, noah dijulio bould design 1931 old middlefield way, suite 204 mountain view, ca 94043 T ) 650.965.4509 E ) noah@bould.com - Hide quoted text - W) www.bould.com Tom Wadzinski wrote: The rebuffering showBriefly is currently pretty annoying, really "in your face". Is there a plan for communicating rebuffering in a different way? Also, for whatever solution we go to, I think that the notion of showing progress towards completion (currently a numeric value) is valuable, compared to just a "waiting" indicator. Tom
Created attachment 5527 [details] Ref artwork - Rebuffering Track
Fixed in r6885. I found that just moving only the buffering messages into the title bar still left two other showBrieflies that SC sends appear when starting up a stream, so I moved those two into the title area as well. Those are: 1) "Fetching track details" 2) a "now playing" indication. Also, any stream error information will appear in the NP title instead of a showBriefly.
(In reply to comment #2) > Fixed in r6885. > > I found that just moving only the buffering messages into the title bar still > left two other showBrieflies that SC sends appear when starting up a stream, so > I moved those two into the title area as well. Those are: > 1) "Fetching track details" > 2) a "now playing" indication. > Excellent, yeah I was wanting to kill both of those showbrieflies. > Also, any stream error information will appear in the NP title instead of a > showBriefly. Hmm will have to see it, I trust you though :)
Here are some sample stations (assuming they stay broken) to see error messages: IR->Staff Picks->By City->Berlin, DE->Kauf Radio Also, under Berlin, DE->Radio Paradiso
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.