Recording times no longer correct

[O19GP 7]

Hi there, I've been recording live TV for years without issue. However recently (I believe at the time of the change from BST to GMT), Emby started getting the recordings wrong. Typically starting 30 to 45 minutes before the scheduled time. The TV guide is correct, system time too, timezone is set correctly in Docker etc. I don't have settings triggering an early start or late finish of recordings.

In the attached logs there's an example:
The recording started at 18:13 (6:13pm) instead of 19:00 (7pm) - 47 minutes early. And it ended at 19:29 instead of 19:25 - 4 minutes late.

Any ideas?

embyserver-63900432975.txt

[Luke 42453]

Hi, I would check your options for both the recording as well as default recording options. Specifically the start x minutes before option.

[O19GP 7]

Hi @Luke, I did and I have no settings to start earlier or finish later.

[Luke 42453]

Hi, what exactly did you check, and what exactly did you find?

[O19GP 7]

@luke both the default option as well as on a per recording level. Both showing 0s in all fields. See attached screenshots.

[O19GP 7]

@Luke?

[Luke 42453]

Hi, what recording are we focusing on here?

[O19GP 7]

NOS Journaal, roughly running GMT 19:00 to 19:25 (country of broadcast time 20:00)

[Luke 42453]

I don't see anything obvious here. We will have to print more information in the log to see why it started early.

If you could prepare another example and include screenshots from the guide data in emby server, that would be helpful. thanks.

[O19GP 7]

@LukeComing back to this, as I still haven't found a way to fix it:

Here's more detailed log info:

Setup: Emby 4.9.3.0 running in Docker on WSL2 (Windows host). Container timezone set to Europe/London, confirmed BST. Host system clock synced via NTP, correct. Windows host clock matches WSL2 clock to the second.

The problem persists and I have a clean example. Buitenhof (Dutch channel, WebGrab+Plus EPG) on 26 April 2026:

- Emby guide shows start time: 11:10
- Recording timer fired: 11:00:13
- Actual broadcast start: ~11:13
- Recording ran for 69.73 minutes
- Result: recording started 10 minutes before guide time, ended ~60 seconds before programme finished

From the log:

2026-04-26 11:00:13.633 Info LiveTV: Recording timer fired for 98bc93fdf2a834b0f336065f2561a814 Buitenhof - S21:E24
2026-04-26 11:00:16.073 Info LiveTV: Will record to .../Buitenhof S21E24.ts for 69.73211289666666 minutes.

The same pattern occurs on UK channels using Emby's own guide data (not just WebGrab), so this is not an EPG source issue. Channel 4 News and ITV Evening News show identical behaviour — timer fires significantly before the guide-scheduled time, with a variable offset typically between 10 and 45 minutes early.

Pre/post padding is set to zero.

The issue started at the BST→GMT clock change in October 2025 and has persisted through the GMT→BST change in March 2026. Deleting and recreating all series timers did not resolve it.

Happy to provide additional logs or run any diagnostics that would help identify where the scheduling offset is being introduced.

-----
The screenshot is for this upcoming Sunday as I can't see yesterday's guide anymore. Time is exactly the same.

[sa2000 739]

2 hours ago, O19GP said:

Happy to provide additional logs or run any diagnostics that would help identify where the scheduling offset is being introduc

Lets get a zip of seriestimers.json and timers.json which are stored in the data/livetv folder together with a full log file - if possible and still available,  would like to see the logs from launch time up to time of end of recording. And in case I need to replicate, is this from an emby guide or xmltv ? if emby guide, could you give me the lineup id / country/zip code

[O19GP 7]

Here are all 3 files. In addition to Buitenhof, Channel 4 news is also a good example.

It's across both xmltv and Emby guide data, main one I use is GBR-1000197-DEFAULT

 

Edited April 27 by sa2000
removed raw unsantized log

[sa2000 739]

Thanks. So I started looking at the example you gave Buitenhof then realized that was a bad example because the channel is not in the GBR-1000197-DEFAULT lineup so I cannot check the schedule for the channel for the 26th

Can you please give me other examples that went wrong between 20:38 25th April and 19:53 26th April for a channel that is in the GBR-1000197-DEFAULT lineup

Edited April 27 by sa2000

[sa2000 739]

12 minutes ago, sa2000 said:

you please give me other examples that went wrong between 20:38 25th April and 19:53 26th April for a channel that is in the GBR-1000197-DEFAULT lineup

OK  - I can see it

 

2026-04-26 07:13:16.739 Info LiveTV: Creating recording timer for 3c036f699c507eff589750311e0c684b, Channel 4 News - . Timer will fire in 556.721005565 minutes

should fire in 9 hours 16 minutes 43 seconds - should fire at 16:30

2026-04-26 16:03:19.036 Info LiveTV: Recording timer fired for 3c036f699c507eff589750311e0c684b Channel 4 News - .

So this fired about 27 minutes early 

Could this be a WSL quirk?

 

 

[O19GP 7]

Yes timer created at 07:13:16, 556.72 minutes = 16:30:00 expected, fired at 16:03:19, so 26 minutes 41 early. That tracks with the pattern I've been seeing.

On the WSL question: I did check the WSL and Windows clocks against each other and they matched to the second at the time of checking. However that was a point-in-time check — it wouldn't catch a drift event that occurred earlier in the day and was subsequently corrected by NTP.

Is there a way to determine whether Emby's timer fires based on an absolute wall clock target, or on elapsed time from creation? If it's elapsed time, a clock jump between 07:13 and 16:03 could produce exactly this offset even if the clock looks correct afterwards.

All this worked fine until October. I didnt change any settings in Emby or WSL.

[sa2000 739]

20 minutes ago, O19GP said:

Is there a way to determine whether Emby's timer fires based on an absolute wall clock target, or on elapsed time from creation? If it's elapsed time, a clock jump between 07:13 and 16:03 could produce exactly this offset even if the clock looks correct afterwards.

I do not know - @Lukewill need to answer that. All I can say is that all timers are firing incorrectly

Why use WSL ? Can you reproduce this on windows or native linux machine

There are references to time going out of sync in WSL when you do web search - eg https://www.google.com/search?q=timers+not+accurate+in+wsl&oq=timers+not+accurate+in+wsl

Log shows all the trigger times were wrong. My gut feeling is that this is a WSL 2 issue

Analysis in excel shows they are all adrift 

Edited April 27 by sa2000

[O19GP 7]

Host runs 24/7, no sleep or hibernate. Checked the system journal for clock corrections or NTP events between timer creation (07:13) and firing (16:03) — nothing. No clock jumps logged.

The stored UTC times in seriestimers.json are correct. The timer creation log shows the right target time. Something in Emby's scheduler is firing timers before their scheduled time, but I can't find a system-level explanation for it.

As to why use WSL: it's been my setup for many years, without issue.

[sa2000 739]

On 22/12/2025 at 07:10, Luke said:

We will have to print more information in the log to see why it started early.

 

14 hours ago, O19GP said:

Is there a way to determine whether Emby's timer fires based on an absolute wall clock target, or on elapsed time from creation? If it's elapsed time, a clock jump between 07:13 and 16:03 could produce exactly this offset even if the clock looks correct afterwards.

All this worked fine until October. I didnt change any settings in Emby or WSL.

@Luke You can see from the log analysis that all the timers triggerd early and there is no consistency in how early 

What is the mechanism for the timer firing on linux ? 

[Luke 42453]

I think the first step is to expand on this log statement:

Quote

2026-04-26 07:13:16.739 Info LiveTV: Creating recording timer for 3c036f699c507eff589750311e0c684b, Channel 4 News - . Timer will fire in 556.721005565 minutes

And print the time that it should fire.

[sa2000 739]

4 hours ago, Luke said:

And print the time that it should fire

My gut feeling is that this calculation would be right and will give the right time but some issue with WSL regarding the firing 

But as you say, adding the extra logging is the first step

[O19GP 7]

On 29/04/2026 at 03:39, Luke said:

I think the first step is to expand on this log statement:

And print the time that it should fire.

Sure do I just share the whole log or is there anything in particular that I need to do to deliver this?

[sa2000 739]

55 minutes ago, O19GP said:

Sure do I just share the whole log or is there anything in particular that I need to do to deliver this?

we need to wait until that extra logging is included in an Emby Server beta version. Once that is available - then enable debug logging on emby server and relaunch to get fresh complete logs and have a number of scheduled recordings start and then download the full log file and attach together with zipped seriestimers.json and timers.json . Log(s) need to cover period from launch time up to time of several recordings start early

 

[O19GP 7]

Perhaps I'm missing something but wouldn't enabling debugging in my stable Emby version work?

[Luke 42453]

11 hours ago, O19GP said:

Perhaps I'm missing something but wouldn't enabling debugging in my stable Emby version work?

Hi, in this case, even that doesn't have enough information to explain what is going on, so we need to print more information to the log to see what's going on.

[O19GP 7]

Understood, I'll wait for the extra logging and go from there. Thanks!