Bug 9268 - display clock when Squeezebox is not connected to a server
: display clock when Squeezebox is not connected to a server
Status: RESOLVED WONTFIX
Product: SB 2/3
Classification: Unclassified
Component: Misc
: 112
: All All
: -- enhancement with 5 votes (vote)
: Future
Assigned To: Felix Mueller
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-22 16:32 UTC by Peter Watkins
Modified: 2010-05-07 10:20 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Watkins 2008-08-22 16:32:17 UTC
A frequent question on the user forums is how to display the time after shutting down the SqueezeCenter host. The common suggestion is to switch to SqueezeNetwork. This is awkward -- even with some 3rd-party code that's been developed to facilitate this workaround.

I understand that the Squeezebox Classic and Transporter hardware has an internal clock, and that, while there's no RTC that would allow keeping time through power failures, it should be feasible for SB3 and Transporter units to display the local time after losing their connection to SqueezeCenter or SqueezeNetwork.

Please enable such a display. 

I suggest using a 12-hour display, in the large font (so there are no day/month language localization issues), with the ":" flashing (so it's possible to tell at a glance that the player is not connected to a server). The device should use the "off" brightness selected by the user. A 24-hour clock would be good if it were easy to show 12- or 24-hour depending on the user's preference.

Naturally, the SB3/Tp display should simply go dark if it loses power and no longer has any idea what the server's local time is.
Comment 1 Blackketter Dean 2008-08-22 17:01:18 UTC
Felix:  How hard would this be to enable, given the clock support you've already added?    

Adding the current time via timer_set_clock_ticks()  (see ipNetRTC a good example), the trick would be getting the time back out formatted correctly, instead of using the hard RTC.)

Comment 2 Peter Watkins 2008-08-29 08:30:56 UTC
Please also see bug 9331
Comment 3 Andy Grundman 2008-10-14 06:29:25 UTC
James: why was this marked fixed?
Comment 4 James Richardson 2008-10-14 08:35:51 UTC
(In reply to comment #3)
> James: why was this marked fixed?
> 

Because I miss read this bug as a Boom bug, not as an SB2/3 - Transporter bug.
Comment 5 Felix Mueller 2008-11-04 03:44:42 UTC
Moving out bug that won't make it for 7.3
Comment 6 Felix Mueller 2008-11-06 09:41:07 UTC
Doh, there will be no 7.4 - moving it to 8.0
Comment 7 Andrea 2009-01-14 13:23:01 UTC
This would make my life so easier you wouldn't believe it. It would great, super, perfect! It's something I'd like. Thank you. ;)
Comment 8 Gordon Harris 2009-02-26 13:23:22 UTC
As a half step:  before implementing a "virtual" RTC, how about adding a feature to the SB2/3/Transporter's firmware to optionally "Auto connect to SqueezeNetwork" when the local server is unavailable?  That way, the SB2/3 gets a clock and alarms won't be missed if the local server is down.
Comment 9 Michael Herger 2009-09-22 20:57:49 UTC
implemented in Boom & later.
Comment 10 Andrea 2009-09-23 03:49:38 UTC
How is this fixed? This refers to Squeezebox 2/3/Classic and you fix it by saying the function it's implemented in Boom and later?

Have you EOLed the products? Transporter too?
Comment 11 Peter Watkins 2009-09-23 10:05:34 UTC
Andrea's understanding is correct; I meant for this to apply to SB3(/SB2/Classic) and Transporter. The basic idea was to try to give them something like the same capability that Boom has.

Gordon's suggestion in comment 8 sounds pretty good, too.
Comment 12 James Richardson 2009-09-23 12:36:07 UTC
To Quote Dean -- Patches Welcome :)
Comment 13 Gordon Harris 2009-09-23 13:00:45 UTC
Ummm...so you're planning on opening the source code to the SB3 & Transporter's firmware?  Otherwise, contributing patches, in this context, is going to be a little tricky, isn't it?
Comment 14 Andrea 2009-11-04 01:25:12 UTC
(In reply to comment #12)
> To Quote Dean -- Patches Welcome :)

Is SB Classic's and Transporter's firmware open source? Are patches for those firmware possible somehow? Honest question.
Comment 15 KDF 2009-11-04 10:59:18 UTC
firmware is not open. patches are welcome, but improbable :)
Comment 16 Alan Young 2010-05-07 10:20:08 UTC
All new Squeezebox products are likely to be based on the SqueezePlay platform.
We do not plan to implement any further enhancements to the ip3k firmware or
which are targeted specifically at ip3k-based products.