Windows-Auto-Night-Mode
Windows-Auto-Night-Mode copied to clipboard
Wallpaper switching back after a second
Description
I set up two wallpapers, one for light mode and another one for dark mode. When the theme switches from light to dark mode, the wallpaper switches also. But after a second the wallpaper switches back. This occurs on the automatic theme switch at sundown and on forcing dark mode.
Expected Behavior
No response
Log Data
2024-12-18 16:10:18 | Info | SystemEventHandler.HandleTimeChangedEvent: system time changed from 18.12.2024 16:10:18
2024-12-18 16:10:22 | Info | PostponeManager.Remove: postpone queue cleared
2024-12-18 16:10:22 | Info | SystemEventHandler.SystemEvents_Windows11_SessionSwitch: system unlocked, refreshing theme
2024-12-18 16:10:22 | Info | ComponentManager.GetComponentsToUpdate: components queued for update: [AppsSwitchThemeFile, SystemSwitchThemeFile, WallpaperSwitchThemeFile]
2024-12-18 16:10:22 | Info | WallpaperSwitch.LogHandleSwitch: update info - previous: Light/Fill, now: Dark/Fill, mode: Fill, type: Individual
2024-12-18 16:10:23 | Info | ThemeFile.SyncWithActiveTheme: theme used for syncing is ADMTheme, path: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme
2024-12-18 16:10:23 | Info | AppsSwitchThemeFile.HandleSwitch: update info - previous: Light, pending: Dark, mode: Switch
2024-12-18 16:10:23 | Info | SystemSwitchThemeFile.SwitchSystemTheme: update info - previous: Light/NoAccent, pending: Dark/NoAccent, mode: Switch, accent: no
2024-12-18 16:10:23 | Info | ThemeManager.UpdateTheme: dwm management: full refresh requested by user
2024-12-18 16:10:23 | Info | ThemeHandler.RefreshDwmFull: dwm management: refresh performed by theme handler
2024-12-18 16:10:24 | Info | Tm2Handler.SetTheme: applied theme ADMTheme, from origin: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme directly via IThemeManager2
2024-12-18 16:10:24 | Info | ThemeManager.UpdateTheme: refreshed dark theme, source: SystemUnlock
2024-12-18 16:10:49 | Info | MessageParser.Parse: signal received: request for running status
2024-12-18 16:10:49 | Info | MessageParser.Parse: signal received: validate autostart entries
2024-12-18 16:10:49 | Info | TaskSchdHandler.GetLogonTask: logon task folder does not exist
2024-12-18 16:13:28 | Info | MessageParser.Parse: signal received: get requested theme
2024-12-18 16:25:05 | Info | Service.ForceMode: ui signal received: forcing dark theme
2024-12-18 16:25:05 | Info | ComponentManager.GetComponentsToUpdate: components queued for update: [AppsSwitchThemeFile, SystemSwitchThemeFile, WallpaperSwitchThemeFile]
2024-12-18 16:25:05 | Info | WallpaperSwitch.LogHandleSwitch: update info - previous: Light/Fill, now: Dark/Fill, mode: Fill, type: Individual
2024-12-18 16:25:05 | Info | ThemeFile.SyncWithActiveTheme: theme used for syncing is ADMTheme, path: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme
2024-12-18 16:25:05 | Info | AppsSwitchThemeFile.HandleSwitch: update info - previous: Light, pending: Dark, mode: Switch
2024-12-18 16:25:05 | Info | SystemSwitchThemeFile.SwitchSystemTheme: update info - previous: Light/NoAccent, pending: Dark/NoAccent, mode: Switch, accent: no
2024-12-18 16:25:05 | Info | ThemeManager.UpdateTheme: dwm management: full refresh requested by user
2024-12-18 16:25:05 | Info | ThemeHandler.RefreshDwmFull: dwm management: refresh performed by theme handler
2024-12-18 16:25:06 | Info | Tm2Handler.SetTheme: applied theme ADMTheme, from origin: C:\Users\night\AppData\Local\Microsoft\Windows\Themes\ADMTheme.theme directly via IThemeManager2
2024-12-18 16:25:06 | Info | ThemeManager.UpdateTheme: dark theme switch performed, source: Manual
Commit Hash, Version and Windows Build
- Commit:
cf7a0fe - Service/App:
10.4.1.1 - Updater:
3.1.4 - Shell:
1.3.3.0 - .Net:
7.0.5 - Windows:
22631.4602
Screenshots / Videos
No response
I've done a fresh install of Windows 11 last week, with every possible system update installed. I decided to try the wallpaper switch feature for the first time as well (I've never used it before on Windows 10), but I'm experiencing the same issue.
@nightfever77 @Spiritreader @Armin2208 After fiddling around with settings and config files for a while, I may have found a workaround and a possible cause for the behavior in question.
Basically, the .theme file created by AutoDarkMode contains two different wallpaper keys under the [Control Panel\Desktop] section, named Wallpaper and Wallpaper1, and they point to the images I've set up to be applied when switching to light and dark mode respectively. Is this the correct behavior? I haven't gone too deep into this, but there might be something that reads the Wallpaper key again after Wallpaper1 is used to set its own image.
Anyway, since then I've decided to let ADM handle the themes through Windows by defining two new custom themes, and for whatever reason the second one didn't save the correct image. After changing it manually inside the .theme file it appears to work, so I would advise to give it a try.
There was only one line Wallpaper1 pointing to the light theme image.
I added a line with Wallpaper pointing to the dark mode image.
But behavior is the same: wallpaper switching back after a second.
This is my .theme:
[Control Panel\Desktop] Wallpaper=F:\Wallpapers\enterprise_A.png Pattern= MultimonBackgrounds=1 WindowsSpotlight=0 PicturePosition=4 Wallpaper1=F:\Wallpapers\Enterprise_E.png
Additional notice: If I change MultimonBackgrounds to 0, the images will be cross-changed but the behavior persists.
If I setup two different colors (black and white) instead of two wallpapers nothing changes, background remains grey.
The wallpaper with a number at the end is the wallpaper for each monitor when MultiMon background is enabled.
A theme file should never contain both light and dark wallpapers. If that happens, it effectively means that something went wrong. The only way to fix that would be to find out why this fail occurs, which is very hard to do because the API we are using is an undocumented black box that came from reverse engineering with a kernel debugger. (see SecureUXTheme).
What I've discovered is that there are multiple instances where windows modifies the theme file that was supposed to be applied, - often wrong - which is usually related to special Unicode characters though. So most likely not what is happening here.
@rdxdkr Getting multi monitor wallpapers to work In a way where the images show up on the correct monitor is quite the challenge by itself when simultaneously attempting to modify the light/dark UI flavor while maintaining a synchronized theme state between ADM and Windows. When a user configures wallpapers via ADM, on a theme switch we first apply the wallpapers via a different API (IDesktopWallpaper) that supports setting wallpapers per monitor using the display identifier.
That change then gets propagated to the active theme file that windows uses, which serves as our base theme that we then modify with the remaining preferences configured in ADM.
This by itself is also a challenge, because we can't read the active theme file directly as it only persists in memory until an update is triggered by an unknown component that flushes it to disk. We use a best effort method to effect this flush, but sometimes it doesn't work (or doesn't do it quickly enough, causing sync issues) This new interim theme file is then patched, as mentioned above.
Since there is no explicit synchronization between those events (as it's all async without the ability to subscribe to callback events), what you're experiencing is mostly likely a desync event. My guess is a state where the wallpapers are not yet fully propagated to the in-memory copy of the theme file, or where the flush-to-disk mechanism failed. So before the change from the IDeskropWallpaper API is reflected.
A way to solve it would be to monitor the interim theme file and check if all of the users requested wallpapers are found, and then perform in the following order:
- retrigger the flush event for a couple of seconds and listen for changes to the interim file
- retrigger setting the wallpapers if no update is detected
As you can see, quite a bit of complexity that goes into getting this to work cleanly.
When you use the windows theme mode, all of this synchronization mess goes out the Window because we never land in a scenario where we had to synchronize two or more async api calls. The windows theme mode should work better in theory. It does for some, and almost never works for others.
So it's a YMMV situation on top of that.
@Spiritreader yikes, that sounds incredibly bad but I guess I shouldn't be really surprised, given how this appears to be quite standard for Windows. Creating and editing themes via the Windows 11 settings UI is inexplicably confusing, after all.
Just wanted to add that I'm only using a single monitor and I haven't really touched any related settings. If you want I can share my .theme files, especially the ones automatically generated by ADM.
sounds incredibly bad
Believe me, incredibly bad is still an understatement. The workarounds I had to do to get it to work as is range from inconvenient to straight up unhinged.
Even if you're only using a single monitor mode, if you use the multi monitor wallpaper API (which also supports single monitor scenarios) the whole fiasco will still happen.
At some point in the future when I have more time again, I'll hopefully get around to building some sync logic on top of what we currently have to hopefully mitigate this some more.
I suddenly started having this issue too. Single monitor here as well, though looking in the config.yaml, there are 3 monitors that show up. Only the middle one is associated with my actual monitor. Would deleting the other 2 entries help in this case, or are they necessary for something? I'm also not using a .theme file as far as I can tell (at least that's what ADM is telling me in the settings).
Monitors:
- Id: '\\?\DISPLAY#HEC002F#5&1f0a4afa&0&UID4352#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}'
LightThemeWallpaper: C:\Users\lilgrassin\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets\8c2c59ad57aab9b3ab707144a09a1a27a21dcf1f49ad89a5c9c5f015e1488990
DarkThemeWallpaper: C:\Users\lilgrassin\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets\8c2c59ad57aab9b3ab707144a09a1a27a21dcf1f49ad89a5c9c5f015e1488990
- Id: '\\?\DISPLAY#GSM5B08#5&1f0a4afa&0&UID4352#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}'
LightThemeWallpaper: C:\Users\lilgrassin\Downloads\wallpaper\aenami quiet mind.jpg
DarkThemeWallpaper: C:\Users\lilgrassin\Downloads\wallpaper\aenami wave.png
- Id: '\\?\DISPLAY#HEC0030#3&37afff4c&0&UID256#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}'
LightThemeWallpaper: C:\Users\lilgrassin\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets\8c2c59ad57aab9b3ab707144a09a1a27a21dcf1f49ad89a5c9c5f015e1488990
DarkThemeWallpaper: C:\Users\lilgrassin\AppData\Local\Packages\Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy\LocalState\Assets\8c2c59ad57aab9b3ab707144a09a1a27a21dcf1f49ad89a5c9c5f015e1488990
I can reproduce the issue on Windows 11
One idea to be explored is that when ADM switches to light/dark mode, it could grab an array of all of the desktops and override the wallpapers IDK how this functionality is achieved on Windows 10 but I'd imagine that on Windows 11, since it introduces a separation of wallpapers for each virtual desktop, the OS probably stores them in an array
Multi monitor wallpapers are now attempted to be synchronized if the API is slow.
It only works if you select the Wallpaper (Multiple) type for both Light and Dark wallpapers for now, because I need to test if this actually mitigates the issue before implementing other types.
You need at least beta 11.0.0.7 to try this out, which is available on the beta branch
@Armin2208 confirmed the sync logic to be working. The wallpaper no longer switches back for the currently implemented modes. Will implement this for the remaining wallpaper options.