Thread Rating:
  • 0 Vote(s) - 0 Average
Daylight savings time on Recordings
#1
Since the change from GMT to British Summer Time (GMT+1) last Sunday, the start time on the Recordings list in my Kodi/DVBViewer is one hour later than the actual start time on all entries before the change. Recordings completed after the change show correctly. For example, a recording starting at 21:00 on the previous Sunday now shows as 22:00, while the one from this Sunday shows 21:00, as expected, These times appear to be from the EPG, as the actual timer start was 20:58. This is in Kodi 17.0, with 2.4.6. It's also on another system with Kodi 16.1, but only after restarting both Kodi and RS - before the restarts, the times were all 1 hour earlier (e.g. 20:00 for the new recording, 21:00 for the older ones.

I have not found any effect on playback of these recordings. so the impact is not serious. It just looks odd. The TV Guide is not affected.

None of the RS interfaces show this issue in the Recordings list - EPG start/end times are all correct. The PCs show the correct time.

PS. The above systems are Windows 7. I'm seeing the same issue on Android 6 with 17.1/2.4.7
Reply
#2
(2017-03-28, 02:14)jim300 Wrote: Since the change from GMT to British Summer Time (GMT+1) last Sunday, the start time on the Recordings list in my Kodi/DVBViewer is one hour later than the actual start time on all entries before the change. Recordings completed after the change show correctly. For example, a recording starting at 21:00 on the previous Sunday now shows as 22:00, while the one from this Sunday shows 21:00, as expected, These times appear to be from the EPG, as the actual timer start was 20:58. This is in Kodi 17.0, with 2.4.6. It's also on another system with Kodi 16.1, but only after restarting both Kodi and RS - before the restarts, the times were all 1 hour earlier (e.g. 20:00 for the new recording, 21:00 for the older ones.

I have not found any effect on playback of these recordings. so the impact is not serious. It just looks odd. The TV Guide is not affected.

None of the RS interfaces show this issue in the Recordings list - EPG start/end times are all correct. The PCs show the correct time.

PS. The above systems are Windows 7. I'm seeing the same issue on Android 6 with 17.1/2.4.7


This is an ancient Kodi bug. You need to restart Kodi once after the daylight time change happened.

It's just an UI glitch. Internally, Kodi PVR uses UTC, and everything except the visualization of time for some items should work.

Kodi would need to detect the daylight change and to reload all epg items, timers, recordings in case. This does currently not happen.
Reply
#3
(2017-03-28, 08:31)ksooo Wrote: This is an ancient Kodi bug. You need to restart Kodi once after the daylight time change happened.

I did that several times. Before the restart, the times were 1 hour early; after, they'd all shifted 1 hour. I even cleared the data out but there's no change. The error is still present.

The Recording Service API delivers the recordings list with the time as a string e.g.

Code:
<recording id="1754" charset="255" content="191" start="20170319210000" duration="010500">
.
.
.
<recording id="1761" charset="255" content="191" start="20170326210000" duration="010500">

The first record is from before the time change, the second is after. Both have the same start "210000", but the Kodi list shows them as "22:00" and "21:00" respectively. Perhaps the add-on is using some library function that converts all times to local, when it shouldn't be doing any conversion at all.
Edit: converted times corrected. DST = 2100, NoDST = 2200
Reply
#4
I'm using mktime to convert the parsed string to a time_t with tm_isdst being set to -1 so mktime determines whether DST is in effect at that specified time itself. See: https://github.com/manuelm/pvr.dvbviewer...a.cpp#L443 + https://github.com/manuelm/pvr.dvbviewer....cpp#L1243
Reply
#5
If I understand this correclty:
ParseDateTime() parses the date/time obtained from the RS API string;
mktime subtracts 1 hour from timeinfo.tm_hour if it determines DST was in effect at that point in time;
Kodi (after restart) adds 1 hour to the time if DST is in effect currently, otherwise no change.

RS API string---------ParseDateTime/NoDST-----DST local
20170319210000 > 20170319210000 >>>>> 20170319220000
20170326210000 > 20170326200000 >>>>> 20170326210000
Did I get that right? If so, then only recordings made in the current DST period (including previous years) will display the original time. Comparing some old recordings, I see the same error from last year. All the recordings made from October 2015 to March 2016 show in Kodi as 1 hour later than in Recording Service web interface. Same error reported here by a MediaPortal user.

I believe Kodi should display start times in the same way as RS does, How can this be done? Could ParseDateTime check local time's DST status and set tm_isdst accordingly (0 or 1) so that mktime would only subtract the hour when DST is active? This would mirror the Kodi action and cancel out any changes. Would that change affect the function's use elsewhere?
Reply
#6
(2017-03-28, 22:31)manül Wrote: I'm using mktime to convert the parsed string to a time_t with tm_isdst being set to -1 so mktime determines whether DST is in effect at that specified time itself. See: https://github.com/manuelm/pvr.dvbviewer...a.cpp#L443 + https://github.com/manuelm/pvr.dvbviewer....cpp#L1243


Kodi PVR API expects all time values in UTC.
Reply
#7
(2017-03-29, 07:44)ksooo Wrote: Kodi PVR API expects all time values in UTC.

Has this changed or is this just not documented? Because this code is a bit older, recordings times are ok here on linux and I'm in CET/CEST. Also UTC is only mentioned in PVR_TIMER attributes.
Reply



Daylight savings time on Recordings00