I experienced a similar problem here with f.lux 4.111 in Windows 7:

I have my earliest wake time set for 10:30 am. Sometime around 1 am PDT f.lux started gradually turning the screen from the sunset tint to the bedtime tint like it normally does. Then a second after 1:59:59 am PDT my computer's clock jumped to 1:00 am PST because daylight saving time had ended. When that happened, f.lux quickly turned my screen from the bedtime tint to a transition color between the sunset tint and the bedtime tint, and then resumed slowly turning it to the bedtime tint. I can reproduce the bug by changing my clock backwards. I also tested for the same bug when daylight saving time starts in the spring, and the bug is there too: f.lux jumps forward suddenly from the transition tint to the bedtime tint when the clock skips 2 am PST and jumps to 3 am PDT. I had to set my earliest wake time to 11:30 to trigger the bug in that test. I restarted f.lux each time I changed my clock for these tests.

The bug is that f.lux is subtracting from the next earliest wake time in the current local time zone instead of in the local time zone that the next earliest wake time will be in. 10:30 am local time on Nov. 3 (local) where I live is PST, not PDT, even if it's PDT and Nov. 3 at this moment. There are several ways of fixing this, but the bottom line is that the earliest wake time should be taken as a local time, and since the time zone isn't attached to the earliest wake time setting, you need to figure out which time zone that local time is in, with consideration for the fact that a local day can have two different time zones on the days that daylight saving time starts or ends. There's also an ambiguous case when the earliest wake time is between 1 am and 2 am on the days that daylight saving time ends, since there are two different 1 am hours on that day, one in daylight saving time and one in standard time.

Honestly this bug is not a huge deal to me. I can live with it. The current behavior at least is easy to understand.

Yes it is our 'fallback' mode and it happens when your monitor can't use gamma tables. Post f.lux options > driver info and we'll try to help figure it out.

@herf My husbands just did the same thing. Finally after removing the battery it returned to normal.

SOLVED after reinstalling my device driver. Again, if I had to guess it had something to do with certain settings, not easily reversible and involving Flux, going haywire. Please be aware that such edge cases may be a possibility. Thanks for your time.

@herf said in I can't understand what the graph is showing when I change the Eearliest Wake Time:

@peeteru yes we should make a post about this.

The main graph there is a representation of your daily sensitivity to light. Light in the morning makes your clock earlier, and light at night makes it later.

The "classic f.lux" preset is too obscure, I agree, it tries to revert the UI back to the way it was in 2013 (and then you have to turn it off via a menu). We probably rushed this during the upgrade, and it could explain what it's doing a bit better.

Hi buddy, does this do happens, because during sunrise I never face such things as of now!

Regards,
G.Smith

So, ther is any news about that issue?
Anywy, hanks to the developer(s)
Keep up with the good work!

@jessejm said in F.lux shows that it's on but the color isn't actually changed.:

turn my monitor on BEFORE turning on my PC

Then turn your monitor on AFTER turning on your PC ;-)

To change the colors for your device, open the “Settings” window and click the “Personalization” button in the middle of the screen.
Click the “Colors” category at the left side of this window to view Windows 10 accent color settings in the area to the right.

It honestly doesn’t matter one bit. It’s just a number for your reference. It doesn’t have to be accurate. The only thing that’s important is, you know the number of the setting that you like so that you can repeat it whenever you want.

Hmm - mainly, we trust what's here for discovery: https://www.meethue.com/api/nupnp

If you unplug a bridge it should not show up there.

The credential (pairing) list is kept in HKCU\f.lux Software LLC\hue so you could delete that if you want to be sure f.lux doesn't talk to an old bridge.

What's confusing to me is: if something doesn't appear on "nupnp" we should not talk to it, regardless of how many things are in the registry. If you notice something different, please let us know, since it would be a bug.

My bad, just used the monitor replication for my ambilight system.

So I gess it isn’t possible to disable it when in replication mode.

Thx, anyway

Is this feature windows-10 only?
I’m on win7 with 4.111 and it doesn’t show up.

Can you tell me exactly what you're seeing?

Here is what we do and why:

always adds itself to autorun on install for the current user, and removes it on uninstall users can disable autorun using "task manager > startup" should never start twice - we prevent this from happening

Also since the f.lux corporate build installs for all users on the machine, it does add a toggle to options. Any user can opt out of autorun, and f.lux will remember the setting. But we do not do this for single users because they have two ways to do it already: uninstall, or use task manager.

@herf Hi! Thank you for answering here to customers and provide with solutions. Do you have also a software like this one but for mac to fix the location problem? Thank you in advance!

Options menu has a toggle "Use these hotkeys..."