Night Clock not Updating


I’ve been enjoying the tidbyt but I noticed an issue the past 2 nights.

When I set the device to Night mode, it switches to a clock and lowers the brightness.
The time stops advancing and the clock stays the current time, or advances 1 minute later and no longer after that.

I then tried having a single scheduled clock on the Apps page, this clock also got stuck at 1 displayed time.

My only solution was 2 scheduled clock apps that will rotate between the two, keeping it refreshed.

Anyone else experience this issue? Seems to be when it is a single app displayed that it stops updating.


Hey James,

Thanks for the bug report. That’s the first I’ve heard of this, I’ll look into it and see how or why that’s happening.

If anyone else has experienced this issue, let me know.

No problem Rohan.

Maybe it was a bug, I tried a restart of my tidbyt and will try the normal night mode again tonight.

Sorry if it was a fluke and not a bug. Will keep you posted.

Thank you

1 Like

Just a heads-up, we’ve been able to reproduce this bug. It seems to happen if you have a large-ish number of apps installed (say, more than 10) and enable night mode. Should have a fix soon.

Yes I have very many apps!! I like seeing the mobile app hasn’t gotten slow with 10+ apps.

Thank you for finding a cause and working on a fix. I am glad to contribute to make the tidbyt best it can.

This should now be fixed.

I noticed it was working. Thanks Rohan

Hey Rohan

This bug has returned. Let me know if I can help troubleshoot it anyhow


Uh oh. I’ll take a look!

Thanks I’ll try to write down the times it stops at.
Last night it stopped at 2:30am

Maybe it’ll help the debugging
Thanks :slight_smile:

1 Like

You should add a streamlined way for you to pull logs for the customers and see what the issue is as sometimes it maybe customer specific would give you a much broader picture I feel to troubleshoot as a whole? Maybe I’m talking nonsense

Hey @BT_Jamiel, welcome to the Tidbyt community! We do have a way to pull logs from specific devices, but it’s not turned on by default. Generally we want to reach out to the customer, find out their device ID, and get their permission before doing that.

For this specific issue, @matslina has been looking into it and I think he’s identified a bug that could be the underlying cause. Hoping to have a fix soon!

1 Like

Thanks for the updates! A technical explanation of the bug will be interesting to hear if they decide to share.

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.

1 Like

Very interesting stuff.
What concerns would I have by enabling the logging? I assume you’d just be able to see all the apps and their configurations?

Yup, that’s pretty much it. We would see debug messages which include application ID’s, amount of device memory free and used, and potentially the name of your Wi-Fi network.

Sounds good guys. I trust you folks :slight_smile: I’ll send my ID, Rohan if you still have it you may enable it - I’ll send it to matslina too

1 Like