[SOLVED] Redshift transition from day-night extremely slow

Lysander666 · 08-01-2018, 03:31 PM

This is one of the only issues I'm having with the new build - Redshift again. I have it set to 6500 in the day and 4500 at night. Both look great, but the transition period is the issue.

Presently it's 21.26 and dark here. About ten mins ago Redshift started an extremely slow transition from day to night, which will take it about 45 mins, as it did yesterday. Normally I'm used to the transition taking about 2-3 seconds. It's now at 88% of the transition.

I've tried to see what the issue is and why it can't do it quicker. I think the timing is not a problem so much as the speed.

Here is redshift.conf:

Code:

; Global settings for redshift
[redshift]
; Set the day and night screen temperatures
temp-day=6500
temp-night=4500

; Disable the smooth fade between temperatures when Redshift starts and stops.
; 0 will cause an immediate change between screen temperatures.
; 1 will gradually apply the new screen temperature over a couple of seconds.
fade=1

; Solar elevation thresholds.
; By default, Redshift will use the current eand times arelevation of the sun to determine
; whether it is daytime, night or in transition (dawn/dusk). When the sun is
; above the degrees specified with elevation-high it is considered daytime and
; below elevation-low it is considered night.
;elevation-high=3
;elevation-low=-6

; Custom dawn/dusk intervals.
; Instead of using the solar elevation, the time intervals of dawn and dusk
; can be specified manually. The times must be specified as HH:MM in 24-hour
; format.
;dawn-time=6:00-7:45
;dusk-time=18:35-20:15

; Set the screen brightness. Default is 1.0.
;brightness=0.9
; It is also possible to use different settings for day and night
; since version 1.8.
;brightness-day=0.7
;brightness-night=0.4
; Set the screen gamma (for all colors, or each color channel
; individually)
gamma=0.9[Return] [Catalog] [Top] 19 / 13 / 17 / 3 [Upd
;gamma=0.8:0.7:0.8
; This can also be set individually for day and night since
; version 1.10.trhink
;gamma-day=0.8:0.7:0.8
;gamma-night=0.6

; Set the location-provider: 'geoclue2', 'manual'
; type 'redshift -l list' to see possible values.
; The location provider settings are in a different section.
location-provider=manual

; Set the adjustment-method: 'randr', 'vidmode'
; type 'redshift -m list' to see all possible values.
; 'randr' is the preferred method, 'vidmode' is an older API.
; but works in some cases when 'randr' does not.
; The adjustment method settings are in a different section.
adjustment-method=randr

; Configuration of the location-provider:
; type 'redshift -l PROVIDER:help' to see the settings.
; ex: 'redshift -l manual:help'
; Keep in mind that longitudes west of Greenwich (e.g. the Americas)
; are negative numbers.
[manual]
lat=51.5
lon=-0.07

; Configuration of the adjustment-method
; type 'redshift -m METHOD:help' to see the settings.
; ex: 'redshift -m randr:help'
; In this example, randr is configured to adjust only screen 0.
; Note that the numbering starts from 0, so this is actually the first screen.
; If this option is not specified, Redshift will try to adjust _all_ screens.
[randr]
screen=0

I'm also wondering if this is a timing issue. If it started the transition an hour earlier, that would make sense, but I've never seen it do it so slowly before either way.

jostber · 08-01-2018, 03:44 PM

Should this line be changed to "gamma 0.9" instead?

gamma=0.9[Return] [Catalog] [Top] 19 / 13 / 17 / 3 [Upd

Lysander666 · 08-01-2018, 03:48 PM

Quote:

Originally Posted by jostber

Should this line be changed to "gamma 0.9" instead?

gamma=0.9[Return] [Catalog] [Top] 19 / 13 / 17 / 3 [Upd

I don't know how that happened but I've changed it, thanks. It doesn't affect the transition speed though, after restarting Redshift. It's now at 56% of the transition [starting to look a lot nicer now though].

Lysander666 · 08-02-2018, 06:02 AM

I'm starting to think this issue may be related to the hardware clock. This computer used to run Debian but I have trouble setting the timezone correctly in Slackware. I changed OSs only a few days ago.

e.g. Currently I have the timezone as GMT +2 which makes no sense, but it gives me the right time, even though the hw clock time is correct. Really in Slackware the timezone should be Europe/London in timeconfig, but that makes the time two hours behind what it should be.

I'm going to try syncing the hardware clock to the system time as local time or UTC and seeing if that makes any difference.

jostber · 08-02-2018, 08:13 AM

If you use KDE you can set it by right-click the clock in the panel and then select "Adjust date and time". There you can set the timezone by selecting this tab. When applying it you might get a KDE error, but it works anyway for me.

Lysander666 · 08-02-2018, 03:19 PM

This issue was mostly caused by the hardware clock being set to the wrong time. I had to sync it via

Code:

# ntpdate pool.ntp.org

from this page:

https://docs.slackware.com/howtos:ha...tem_local_time

I am guessing this 45 min transition is intentional. Now that the clock is set correctly [and the timezone to Europe/London] Redshift starts to darken the screen at about 8.30pm when it starts to get dark and now, at 9.15, there is 13% of the transition left to go and it looks great.

I notice a minimal change in the old config file from

Code:

; 1 will gradually apply the new screen temperature over a couple of seconds.

https://raw.githubusercontent.com/jo...ft.conf.sample

to

Code:

; 1 will gradually increase or decrease the screen temperature.

http://jonls.dk/redshift/

So I'm guessing this is something to do with a newer version of Redshift.

jostber · 08-05-2018, 10:56 AM

My redshift changes quite fast. Which redshift version do you use?

redshift -V

redshift 1.11

Lysander666 · 08-05-2018, 10:58 AM

Quote:

Originally Posted by jostber

My redshift changes quite fast. Which redshift version do you use?

redshift -V

redshift 1.11

This is version 1.12, so I am thinking they changed the transition time.

jostber · 08-05-2018, 12:36 PM

I have upgraded to v.1.12 now as well and will check if the transition time has changed.