Hi, all! Please explain me how VPS works in VDR? I reside in GMT+2 (+3h in summertime) timezone and when watching for example ZDF EPG shows correct time, but VPS reports +1h. Is it transmitted in localtime? Example: EPG: 06.06.2006 21:15-22:00 (45 min) VPS: 06.06 20:14 and as result +1:01
Is it correct?
Regards, SK
Suur Karu wrote:
Hi, all! Please explain me how VPS works in VDR? I reside in GMT+2 (+3h in summertime) timezone and when watching for example ZDF EPG shows correct time, but VPS reports +1h. Is it transmitted in localtime? Example: EPG: 06.06.2006 21:15-22:00 (45 min) VPS: 06.06 20:14 and as result +1:01
Is it correct?
The "Programme Identification Label" (PIL) is the "first published start time of a certain event", and it is in local time. So if you're not in the same time zone as the broadcast station, there's a problem.
Maybe we also need to take into account the "local time offset descriptor" to find out the actual time offset of the broadcast station, but IIRC that descriptor wasn't broadcast back when I started implementing VPS. I'll take a look at this...
Klaus
Klaus Schmidinger wrote:
Suur Karu wrote:
Hi, all! Please explain me how VPS works in VDR? I reside in GMT+2 (+3h in summertime) timezone and when watching for example ZDF EPG shows correct time, but VPS reports +1h. Is it transmitted in localtime? Example: EPG: 06.06.2006 21:15-22:00 (45 min) VPS: 06.06 20:14 and as result +1:01
Is it correct?
The "Programme Identification Label" (PIL) is the "first published start time of a certain event", and it is in local time. So if you're not in the same time zone as the broadcast station, there's a problem.
Maybe we also need to take into account the "local time offset descriptor" to find out the actual time offset of the broadcast station, but IIRC that descriptor wasn't broadcast back when I started implementing VPS. I'll take a look at this...
After some testing it appears like most broadcasters do send the TOT data. This one also carries the current time in UTC, and since the TOT is CRC32 protected, it would even have an advantage over the TDT, which might contain garbage without being noticed (that's why VDR's cTDT uses 'lastDiff' in an attempt to detect invalid time data). However, some broadcasters only send TDT, so we would probably have to parse both of them.
So switching from TDT to TOT would have two advantages: having the current time in a CRC32 protected way, plus giving us information about the broadcaster's time zone. Unfortunately the time zone information is not given directly, but rather as a "current offset from UTC", thus also including any DST (daylight saving time). Fortunately, though, it contains both the current and the next offset (i.e. the one for DST and the one without DST), so taking the smaller one of these should give us the actual time zone.
The attached patch adds parsing the TPT to VDR/eit.c and writes some debug output to the console. For the German RTL channels this looks like this:
TDT Sat Jun 17 11:55:18 2006 TOT Sat Jun 17 11:55:18 2006 58 DEU 0 0 200 Sun Oct 29 02:00:00 2006 100 AUT 0 0 200 Sun Oct 29 02:00:00 2006 100 CHE 0 0 200 Sun Oct 29 02:00:00 2006 100
Apparently the TOT can contain information for various time zones, so I'm not quite sure as to how exactly this can be used in case the entries would lead to different results.
Note that the attached patch is just for investigating the TOT. It does not add any functionality, and it turns off setting the system time. So don't use it in a production system unless you know what you are doing. I'm just posting it in case somebody is interested.
The remaining problem is that the time zone information needs to be assigned to the individual channels, so that it is available when an EPG event with VPS information is detected. However, the TOT's repeat frequency varies greatly between broadcasters. Some repeat it every second, while others send it only twice per minute. This means that EPG events with VPS information can only be processed correctly after the TOT has been seen - which can take quite a while.
Anyway, since this would require some incompatible changes (channels would need to store their time zone), I'm afraid I can't make changes here in version 1.4. I'll see what I can do in version 1.5.
It's a real pitty that the authors of the DVB standard have totally messed up the Programme Identification Label. Instead of making this a sequence of digits, they really should have made this a "time in UTC". Then we wouldn't have this problem...
Klaus