We’ve found a bug in the device’s firmware that we believe is causing this problem. Unfortunately I’ve been unable to reproduce this exact failure mode, where the nightmode clock freezes. But this particular issue is still our best bet. We have a fix in place, and as soon as we’ve tested out the new firmware we’ll be rolling it out to all devices.
@James Could you DM me your device ID, and let me know if you’re ok with us enabling remote logging? In case this new firmware doesn’t solve the problem, it’d be helpful to have those logs.
As for technical explanation, I got one here for you:
When Tidbyt’s backend determines that an installed app should not be displayed, it communicates that to the device by sending blank data. Blank as in 0 bytes of image data. The device will simply skip that app in the rotation and move on to the next one that has data.
This mechanism is used when an app’s schedule is set to disable the app, when nightmode is active, and also when something like the Spotify app notices that no music is playing, so no information should be displayed.
Unfortunately, there was a memory leak in this piece of code. Whenever blank image data is found, a few bytes of memory is leaked. Most of the time, this has no impact on the device, but if nightmode is running for several hours (as it usually is) and there are a lot of installed apps, then those small repeated memory leaks start building up until there’s little free memory left.
At that point, the device will usually restart and reset itself, but if all the moving pieces are aligned just right (or “just wrong”, I guess) then it could end up in a loop of sorts where it fails to get the next clock screen, but manages to “survive” without crashing.
The bug fix consists of adding a single free()in the right spot. On top of that, we’ll also be reworking some of the memory allocations to make sure that a failure to allocate memory results in a reboot, instead of a brave but foolish attempt to make progress.
