We'll have to make the loading a synchronous process. Today it's imho async, returning the page before the stream has started playing. Thus when the page is created, the result isn't known yet. 

I assume that's with SS6, or a different skin than Default. In the new Default skin there's no feedback at all, unless a previous playback being stopped.

(In reply to comment #1)
> I assume that's with SS6, or a different skin than Default. In the new Default
> skin there's no feedback at all, unless a previous playback being stopped.
> 
This is with SC7 Default skin.  AFAICT, there is no feedback at all if you enter the URL from the home page but there is always the "Tuned into URL ..." message if you enter it from the Tune In URL page.

This will be handled by the event log, see bug 6369.

(In reply to comment #3)
> This will be handled by the event log, see bug 6369.
> 

Well, I can't view that bug so I guess I'll take your word for it...

Yeah, sorry, the basic idea is a table in the database where any error can be logged: scan errors, network errors, etc, and a red icon would appear in the bottom of the web UI where you could click and view them.  This way we can log errors easily from anywhere in the code without having to worry about how to propagate it back up to the user on whatever interface they are using (web, Jive, etc)

I'm not sure that only using log is the best solution for this kind of message to the user.  It seems to me that on Jive and the web interface we are lacking in immediate feedback on radio station errors.  The SB is better in this regard.  There are other bugs related to Jive popups, so this bug can focus on the Web feedback.

Some kind of pop-up overlay  on the web view would be great, but even a notice with a descriptive error message at the bottom "info" area would be an improvement.

Michael: can you look at this for 7.0?

This bug depends on 6369 which you targetted for 7.1. Thus this won't make it into 7.0 unless you want some isolated solution which would soon be obsolete.

I'm not 100% sure that this is dependent on 6369.  We could consider hooking the showbriefly mechanism into the web UI for this kind of feedback.  I want to talk about this for 7.0.1...

change 17831 - return the showBriefly with the CLI's status query. To be used in cases (web UI) where we can't keep a connection open to subscribe to events.

change 17832 - display the showBriefly animation in the web interface's status bar

Not the right way to solve this issue: we're now getting all showBrieflies in the web interface, including player state changes. Argh...

I tend to think a showBriefly type mechanism is the right way for flagging information to the user.

As it sounds like it is not possible to subscribe to displaystatus messages via the web, do we want to do something which categorises showbriefly messages and only sent the relavent ones to the web interface.  What about adding a 'web' key to the display hash to be used in a similar fashion to the jive one - and sending the text in the web key, but suppressing if that is not present?

> As it sounds like it is not possible to subscribe to displaystatus messages via
> the web, do we want to do something which categorises showbriefly messages and
> only sent the relavent ones to the web interface.  What about adding a 'web'
> key to the display hash to be used in a similar fashion to the jive one - and
> sending the text in the web key, but suppressing if that is not present?

I thought about this. But then I wondered whether the current implementation actually is: there aren't all that many showBrieflies after all. And the web UI should only be displaying the current player's events of the past 15 seconds.

But the web key would be the best approach (besides the need to add one more parameter to some of the calls). It would also allow for better wording in some cases.

let's consider this good enough for 7.0.1 and review for 7.1

change 19023 - adding instant feedback about the action taken, plus showBriefly if anything went wrong

So is there supposed to be a showbriefly error message in the webui? I see 404 messages on the player display but didn't see anything on the webui. 22114

Created attachment 3693 [details]
trying to tune in to bugs.slimdevices.com (fehler=error)

Hm, that's not really enough for an error message.   It would need to be either a pop-up window/overlay or be right next to the dialog box in red.

The problem is that I don't know what showBriefly is an error message and what not. showBriefly just displays a text, whether informational or error message - you can't say. The validation is done asynchronously, thus there's not even a return code or something I could wait for.

Re-opening this bug per comment #18. The showBriefly may not be the ideal location for this message. 

Now if somebody could come up with a good design. The whole showBriefly code was added for this exact issue. 

I think the suggestion I had for jive still holds - we add a "type" key to the hash passed to showbriefly.   This indicates the type of message: information, warning, error etc.  I originally wanted to reflect this as an icon on jive in the popup but this didn't happen - but it would mean you could selectively make some messages more prominant than others.

No idea if this is still a bug.  This whole bug predates my tenure at Logitech...

It's still as much an issue as it ever was (not a biggie for me, but others). Type some nonsense URL in the Tune In field and see what happens - or not.

Targeting for 8.1 sounds like "FUTURE" or "WONTFIX" to me... I doubt we should already be targeting to this release.

Matt Weldon doesn't work for us any more.

Unassigned bugs cannot have a priority.