Bug 7922 - Display settings don't apply properly
: Display settings don't apply properly
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Display
: 7.0
: All All
: P3 normal (vote)
: 7.x
Assigned To: Michael Herger
:
Depends on:
Blocks: 8237
  Show dependency treegraph
 
Reported: 2008-04-21 11:01 UTC by Dan Evans
Modified: 2009-07-31 10:19 UTC (History)
5 users (show)

See Also:
Category: ---


Attachments
autoset brightness in all modes, including new settings (1.61 KB, patch)
2008-04-28 12:43 UTC, KDF
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Evans 2008-04-21 11:01:47 UTC
A couple different reports where the screensaver or display settings are not behaving properly.

* If you go into either SC or SN and change the display brightness for a player and click Save or Apply, it does not change the player.  If you then press power twice on the remote, the display change is applied.

* If you set the "Screensaver when OFF" setting to be "None", at first the display is blank while the player is OFF.  But at a later time, the Date & Time screensaver re-appears.  The setting remains set to None.  (I just tested this and it only took a matter of minutes.)

Both of these appeared only after fw 86 went out the door.
Comment 1 KDF 2008-04-21 11:34:04 UTC
Are you changing idle brightness or active brightness?  If left for a while, it will be 'idle', but pressing power goes to 'off' setting, then pressing power again gives the 'active' brightness.

log for server.timers should have some info on what's going on with screensaver modes.  

neither of these should be related to firmware.
Comment 2 Dan Evans 2008-04-21 12:11:27 UTC
In all cases I'm adjusting and testing OFF settings.
Comment 3 Chris Owens 2008-04-28 09:34:09 UTC
James to try to reproduce, might have to get targeted for 7.1
Comment 4 KDF 2008-04-28 12:43:27 UTC
Created attachment 3306 [details]
autoset brightness in all modes, including new settings

Previous code only handled brightness on a mode change or at timeout.  This patch will continually check against the current pref and adjust accordingly, but ONLY if the setting for automatic adjustment is checked. When set for manual, only the remote or a mode change (off/on) will cause the brightness to change.
Comment 5 Michael Herger 2008-05-06 03:54:13 UTC
*** Bug 8007 has been marked as a duplicate of this bug. ***
Comment 6 Michael Herger 2008-05-06 04:01:23 UTC
change 19452 - thanks kdf!
Comment 7 James Richardson 2008-05-09 16:14:53 UTC
Verified fixed in 7.0.1 - 19597 r88
Comment 8 James Richardson 2008-05-15 12:30:58 UTC
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Comment 9 Edward Pearson 2008-07-21 11:26:13 UTC
Not sure if this is 'by design' but the fix implemented stomps over brightness requested by showBriefly.
Comment 10 Daryle Tilroe 2008-07-26 06:07:18 UTC
Just to support the last comment, this "fix" has also broken the functionality
of the AutoDisplay plugin, bug 8237.  It seems to render the Client->brightness()
call rather useless unless you are in 'Manual' brightness mode and seemingly
makes the control of brightness by future plugins difficult.  I has also been
mentioned that the workaround of staying in 'Manual' brightness mode will be
going away soon.

Isn't there someway to rethink what 7922 does?  For example only adjust the
brightness when the preference changes rather than constantly poll or check
for changes.  This is arguably wasteful of cycles anyhow.  As an aside I have
found 7.x more sluggish than older slimserver versions.  Now I don't really
blame 7922, but fixes that constantly poll like this could add up.
Comment 11 Chris Owens 2009-07-31 10:19:40 UTC
Reduce number of active targets for SC