HDHomeRun RECORD time source on Windows DVR?

[PTSD]

I recently configured an Intel NUC for HDHomeRun DVR recording. So far so good...

This NUC is running a basic install of Windows 10 IoT Enterprise LTSC 2021, with Microsoft Store functionality restored to allow install of UWP apps. This morning I applied my usual post-install registry tweaks to Windows on this NUC. One of those tweaks instructs Windows to allow the hardware Real-Time Clock to remain set to UTC:

Code: Select all

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=hex(b):01,00,00,00,00,00,00,00

I started applying this tweak to Windows installs awhile ago to handle dual-boot situations where booting back & forth between Windows and Linux would mess up the Time Zone offset in one OS vs. the other.

So far I haven't run into any issues with any apps that I run in Windows on my own PC with this tweak enabled. However, I noticed this morning after applying this setting on the Intel NUC running HDHomeRun RECORD, that today's HDHomeRun log file is apparently affected by this change:

• Leading timestamps in the log file entries were initally rolled back by eight hours following the post-tweak reboot

• "System: server time = " entries started showing "(correction of 28800s)" or thereabouts (i.e. 8 hours)

• Timestamps around that initial "correction" entry of approx. 8 hours were reverted to what they were prior to applying the tweak

The good news is that this issue hasn't changed the clock time display or program guide times in the HDHomeRum app when viewed on the NUC. Also, it hasn't affected actual recordings; they started today as scheduled and ran to completion, and they show the correct times whether played back on the NUC or remotely from other devices.

Some questions:

1. What exact method does HDHomeRun use on Windows use to query "server time"?
2. If using the RTC, should that be changed to instead query Win32tm or something similar?
3. Where does "current time" get stored after it's corrected?

Thanks in advance for your replies. In the meantime I will remove this registry tweak from the DVR. It's not needed there anyway since that hardware will be dedicated to DVR service and will not be dual-bootable for the foreseeable future.

[signcarver]

Every hour or so (might take 2) the record engine checks in with SD to find out what to record in the next 4 hours with also getting the time from SD's servers. Guide data is always UTC and the Record engine checks how off system time is. I'm not sure which method it reads system time but it shouldn't matter as the offset computed is the offset that it will use to record but there can be issues if the time gets (manually) set in between those requests for its marching orders unless the engine gets restarted but in theory unless you are periodically changing the time/timezone you shouldn't need to worry about that and that is the entire point of using that offset as system time might drift a bit.

The app however can be more prone with issues when system time isn't set correctly with proper time zone but typically if windows is displaying the correct time and is in the correct time zone, it will be correct.

[PTSD]

Here's a snippet from today's log file where the UTC time zone change in the RTC is reflected. (I planned to add the entire log as an attachment here but can't figure out how to do that.)

Code: Select all

20240229-14:41:21 System: server time = Thu Feb 29 14:41:21 2024 (correction of 0s)
20240229-14:41:21 Recording: record The Young and the Restless S51E103 20240229 [20240229-1930] on 2.1 (12 15)
20240229-14:41:21 Recording: record The Bold and the Beautiful S37E111 20240229 [20240229-2030] on 2.1 (11 15)
20240229-14:41:21 Recording: event download success
20240229-14:41:21 Recording: disk space available = 728GB
20240229-14:41:21 Recording: current time = Thu Feb 29 14:41:21 2024 (correction of 0s)
20240229-14:41:21 Recording: event The Young and the Restless S51E103 20240229 [20240229-1930] in future
20240229-14:41:21 Recording: next timer event in 4h48m09s
20240229-14:42:57 Status: Resource: nbk=2 dmk=342
20240229-14:44:57 Status: Resource: nbk=2 dmk=342
20240229-14:46:57 Status: Resource: nbk=2 dmk=342


HDHomeRun RECORD 20231214 Windows 567CEE5D-02EC-454B-B3C6-590AB3070E64
20240229-06:49:08 Recording: RecordPath[0] = 'D:\Recorded TV\HDHomeRun\'
20240229-06:49:08 Recording: RecordPath D:\Recorded TV\HDHomeRun\ = ntfs
20240229-06:49:08 System: StorageID: 567CEE5D-02EC-454B-B3C6-590AB3070E64
20240229-06:49:08 System: LocalIP: [fe80::12a0:73bf:f7c9:7689]/64 (ifindex 9)
20240229-06:49:08 System: LocalIP: 192.168.2.10/24 (ifindex 9)
20240229-06:49:08 System: website port = 49671
20240229-06:49:08 Recorded: RecordPath 'D:\Recorded TV\HDHomeRun\' (ntfs)
20240229-06:49:08 Status: Resource: nbk=1 dmk=248
20240229-06:49:08 Status: ticks = 11640
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\ with 7 subdirs and 0 recordings
20240229-06:49:08 Recording: sending discover using local ip [fe80::12a0:73bf:f7c9:7689] (ifindex 9)
20240229-06:49:08 Recording: sending discover using local ip 192.168.2.10 (ifindex 9)
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\World's Funniest Animals\ with 0 subdirs and 2 recordings
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\The Young and the Restless\ with 0 subdirs and 3 recordings
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\The Voice\ with 0 subdirs and 2 recordings
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\The Bold and the Beautiful\ with 0 subdirs and 7 recordings
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\American Idol\ with 0 subdirs and 2 recordings
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\America's Got Talent Fantasy League\ with 0 subdirs and 9 recordings
20240229-06:49:08 Recorded: directory D:\Recorded TV\HDHomeRun\America's Funniest Home Videos\ with 0 subdirs and 3 recordings
20240229-06:49:08 Recording: sending discover using local ip [fe80::12a0:73bf:f7c9:7689] (ifindex 9)
20240229-06:49:08 Recording: sending discover using local ip 192.168.2.10 (ifindex 9)
20240229-06:49:08 Recording: discover response from 567CEE5D-02EC-454B-B3C6-590AB3070E64 http://[::1]:49671
20240229-06:49:08 Recording: discover response from 567CEE5D-02EC-454B-B3C6-590AB3070E64 http://127.0.0.1:49671
20240229-06:49:08 Recording: discover response from 567CEE5D-02EC-454B-B3C6-590AB3070E64 http://[fe80::12a0:73bf:f7c9:7689]:49671
20240229-06:49:08 Recording: discover response from 567CEE5D-02EC-454B-B3C6-590AB3070E64 http://192.168.2.10:49671
20240229-06:49:08 Recording: discover response from 1078183D http://[fe80::218:ddff:fe07:8183]:80
20240229-06:49:08 Recording: discover response from 1078183D http://192.168.2.21:80
20240229-06:49:08 Recorded: recorded sync to record-api.hdhomerun.com
20240229-06:49:08 Recording: event download from record-api.hdhomerun.com
20240229-06:49:08 Recording: 1078183D lineup request success (found 168 channels)
20240229-14:49:08 System: server time = Thu Feb 29 14:49:08 2024 (correction of 28799s)
20240229-14:49:08 Recorded: recorded sync success
20240229-14:49:08 System: server time = Thu Feb 29 14:49:08 2024 (correction of 28799s)
20240229-14:49:08 Recording: record The Young and the Restless S51E103 20240229 [20240229-1930] on 2.1 (12 15)
20240229-14:49:08 Recording: record The Bold and the Beautiful S37E111 20240229 [20240229-2030] on 2.1 (11 15)
20240229-14:49:08 Recording: event download success
20240229-14:49:08 Recording: disk space available = 728GB
20240229-14:49:08 Recording: current time = Thu Feb 29 14:49:08 2024 (correction of 28799s)
20240229-14:49:08 Recording: event The Young and the Restless S51E103 20240229 [20240229-1930] in future
20240229-14:49:08 Recording: next timer event in 4h40m22s

[PTSD]

The app however can be more prone with issues when system time isn't set correctly with proper time zone but typically if windows is displaying the correct time and is in the correct time zone, it will be correct.

Windows is still displaying the correct time and time zone after applying this tweak and rebooting the OS; it's already working against UTC +TZ offset. This tweak just stores UTC in the RTC (which is not historical practice).

It seems that HDHomeRun is assuming that the RTC on a Windows system is always reflecting local time, and it's querying something that reads the RTC value, instead of Windows' computed time. That's why the HDHomeRun logs are showing an 8 hour correction with the tweak applied.

But that may be the expected behavior for DVR functionality (i.e. it always corrects for the amount of seconds offset from UTC) and this tweak just surfaces that expected behavior...

[nickk]

The HDHomeRun DVR does not use the local clock for recordings so it doesn't matter how it is set. Instead it uses a free-running timer and the UTC time it gets from our servers.

The HDHomeRun app applies your local timezone offset for displaying times.

While it won't affect recordings the log reporting an 8 hour offset indicates that the Windows config is wrong. The code asks Windows for the current UTC time and then reports how far off it is vs the UTC time it gets from our servers. Being off by 8 hours indicates that Windows UTC time is wrong.

[PTSD]

Thanks Nick. Yeah that "(correction of 28799s)" just plain looked wrong.

Something strange is happening somewhere under the hood with that "RealTimeIsUniversal" setting enabled, and I'm satisfied that disabling it is the right thing to do for an HDHomeRun Windows DVR. It's definitely helpful on a system that dual boots Windows and Linux, but it's not necessary here.