Bug 12725 - Controller UI only allows receiver "OFF" after sleep - when controller also sleeps
: Controller UI only allows receiver "OFF" after sleep - when controller also s...
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: UI
: unspecified
: Other Debian Linux
: -- normal (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-08 07:40 UTC by Rich Simpson
Modified: 2011-11-06 23:24 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Simpson 2009-07-08 07:40:24 UTC
After a player had Slept on the sleep timer, the controller still shows the option to turn off the player. There is therefore no method to simply turn on the player. (selecting turn off the player does not reset it back to the turn on the player option)

The player can be forced back on by choosing something to play - however in the case the player is synchronised this resets all sychronised players to this one. It also does not allow allow a simple resume of previously playing material.

The expected behaviour would after sleep to be able to turn the player on with a controller and have it sychronise with the content already playing on the players it is sychronised with or resume what it was previously playing.

(This is in SBS 7.4 nightlies but i think it has behaved like this for previous version)
Comment 1 James Richardson 2009-07-08 08:51:41 UTC
Is the same error present when NOT in a sync group?
Comment 2 Rich Simpson 2009-07-08 14:03:16 UTC
The problem occurs whether the player is in a sync group or not but futher testing has shown that it occurs only when the following sequence happens:

1.Receiver is playing (synced or unsynced)
2.Sleep timer is set using controller
3.Unused controller sleeps (or is manually told to sleep)
4.Sleep timer on receiver expires and receiver goes off while controller is sleeping.
5. Awakening controller now displays the problem - has option only to turn off player even though it is already off.
Comment 3 James Richardson 2009-07-08 14:24:14 UTC
Ben: is this one yours to look at or Tom
Comment 4 Blackketter Dean 2009-07-22 10:48:09 UTC
Moving to the product SqueezePlay because this bug appears to apply to any
player based on that application code.  Feel free to move it back if it's
specific to the single original product.
Comment 5 Ben Klaas 2009-08-26 07:52:16 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 6 Chris Owens 2010-03-15 18:05:08 UTC
7.4.x milestone is in the past
Comment 7 Chris Owens 2010-05-06 15:38:00 UTC
Tom is no longer available to us
Comment 8 Alan Young 2011-11-06 23:24:49 UTC
Unassigned bugs cannot have a priority.