Hi all,
I use the nice "set system time" feature of vdr. But sometimes vdr seems to read gabage time from DVB, jumps through the time and miss out timers. To avoid souch time warping, I use the assumption, that garbage values never be the same twice:
eit.c, line 261 ff. ---------------------------------------------------------------------- cTDT::cTDT(const u_char *Data) :SI::TDT(Data, false) { CheckParse();
time_t sattim = getTime(); time_t loctim = time(NULL);
static int lastDiff = 0; int diff = abs(sattim - loctim); if (diff > 2) { if (abs(diff - lastDiff) < 3) { mutex.Lock(); isyslog("System Time = %s (%ld)\n", *TimeToString(loctim), loctim); isyslog("Local Time = %s (%ld)\n", *TimeToString(sattim), sattim); if (stime(&sattim) < 0) esyslog("ERROR while setting system time: %m"); mutex.Unlock(); } else { isyslog("diff = %d, ignored to avoid time warp :)", diff); } lastDiff = diff; } } ----------------------------------------------------------------------
Kind regards Andreas Böttger
Birgit & Andreas Böttger wrote:
Hi all,
I use the nice "set system time" feature of vdr. But sometimes vdr seems to read gabage time from DVB,
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
jumps through the time and miss out timers. To avoid souch time warping, I use the assumption, that garbage values never be the same twice:
eit.c, line 261 ff.
cTDT::cTDT(const u_char *Data) :SI::TDT(Data, false) { CheckParse();
time_t sattim = getTime(); time_t loctim = time(NULL);
static int lastDiff = 0; int diff = abs(sattim - loctim); if (diff > 2) { if (abs(diff - lastDiff) < 3) { mutex.Lock(); isyslog("System Time = %s (%ld)\n", *TimeToString(loctim), loctim); isyslog("Local Time = %s (%ld)\n", *TimeToString(sattim), sattim); if (stime(&sattim) < 0) esyslog("ERROR while setting system time: %m"); mutex.Unlock(); } else { isyslog("diff = %d, ignored to avoid time warp :)", diff); } lastDiff = diff; } }
On Sun, 19 Jun 2005, Klaus Schmidinger wrote:
Birgit & Andreas Böttger wrote:
Hi all,
I use the nice "set system time" feature of vdr. But sometimes vdr seems to read gabage time from DVB,
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
jumps through the time and miss out timers. To avoid souch time warping, I use the assumption, that garbage values never be the same twice:
I posted a patch for avoiding time jumps about two years ago, which I just reposted a minute ago.
It uses adjtime instead of stime.
I don't know if much has changed in VDR at this place in the last two years, but I guess that the basic idea is still the same.
Sergei
Klaus Schmidinger schrieb:
Birgit & Andreas Böttger wrote:
Hi all,
I use the nice "set system time" feature of vdr. But sometimes vdr seems to read gabage time from DVB,
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I don't know how that data is protected. Perhaps there is a bug somewhere in vdr... But as a workaround it's ok:
Jun 19 11:24:51 vdr vdr[2641]: diff = 11507939, ignored to avoid time warp :) Jun 19 11:24:55 vdr vdr[2641]: diff = 961, ignored to avoid time warp :) Jun 19 12:41:18 vdr vdr[2641]: diff = 2219, ignored to avoid time warp :) Jun 19 13:49:37 vdr vdr[2641]: diff = 13455538, ignored to avoid time warp :)
Kind regards Andreas Böttger
Klaus Schmidinger wrote:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I've seen this - though at least one year ago - with bad reception due to bad weather. For half an hour, the system time was jumping back and forward like crazy, starting and stopping some timers. Luckily, all timers were repeating, so none of them was gone after reception was back.
Cheers,
Udo
Klaus Schmidinger schrieb:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I have inserted two DEBUG lines:
sections.c: (vdr 1.3.22, leading spaces trimed) ----- // Distribute data to all attached filters: int pid = fh->filterData.pid; int tid = buf[0]; + if (pid == 0x14) { + isyslog("DEBUG cSectionHandler::Action() " + "Length: %d, buf: %03d;%03d;%03d;%03d;%03d;%03d;%03d;%03d;", + len, buf[0],buf[1],buf[2],buf[3],buf[4],buf[5],buf[6],buf[7]); + } for (cFilter *fi = filters.First(); fi; fi = filters.Next(fi)) { if (fi->Matches(pid, tid)) fi->Process(pid, tid, buf, len); } -----
eit.c: (vdr 1.3.22) ----- cTDT::cTDT(const u_char *Data) :SI::TDT(Data, false) { + isyslog("DEBUG cTDT::cTDT() " + "Data: %03d;%03d;%03d;%03d;%03d;%03d;%03d;%03d;", + Data[0],Data[1],Data[2],Data[3],Data[4],Data[5],Data[6],Data[7]); + CheckParse(); -----
Here are two examples:
[RTL, correct time] Jun 21 02:05:53 vdr vdr[22791]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;038;000;005;085; Jun 21 02:06:02 vdr vdr[22794]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;064;207;022;148;003; Jun 21 02:06:02 vdr vdr[22794]: DEBUG cTDT::cTDT() Data: 112;112;005;064;207;022;148;003; Jun 21 02:06:02 vdr vdr[22794]: diff = 1102463777, ignored to avoid time warp :) Jun 21 02:06:03 vdr vdr[22794]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;038;000;006;004;
[ARD, 21 seconds to late] Jun 21 11:13:23 vdr vdr[24655]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;038;009;019;035; Jun 21 11:13:23 vdr vdr[24655]: DEBUG cTDT::cTDT() Data: 112;112;005;209;038;009;019;035; Jun 21 11:13:24 vdr vdr[24655]: DEBUG cSectionHandler::Action() Length: 72, buf: 112;112;069;243;010;029;199;036; Jun 21 11:13:24 vdr vdr[24655]: DEBUG cTDT::cTDT() Data: 112;112;069;243;010;029;199;036; Jun 21 11:13:24 vdr vdr[24655]: diff = 749663640, ignored to avoid time warp :) Jun 21 11:13:25 vdr vdr[24655]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;038;009;019;037;
It seems that it's not a bug of vdr, or am I wrong? Could it be a driver problem? Or garbage from transponder?
Since one hour I use ZDF to get the system time from, waiting for "ignored to avoid time warp :)".
Kind regards Andreas Böttger
udo_richter@gmx.de(Udo Richter) 19.06.05 16:40
Klaus Schmidinger wrote:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I've seen this - though at least one year ago - with bad reception due to bad weather. For half an hour, the system time was jumping back and forward like crazy, starting and stopping some timers. Luckily, all timers were repeating, so none of them was gone after reception was back.
So: Who is doing the CRC checks? Maybe it's turned off or only an error bit is set but nobody cares about in further processing? (Maybe the cause for "unkown picture type" too?)
It's very unlikely that garbage can so often pass a CRC32 check.
Rainer
On 22 Jun 2005 Rainer Zocholl UseNet-Posting-Nospam-74308-@zocki.toppoint.de wrote:
udo_richter@gmx.de(Udo Richter) 19.06.05 16:40
Klaus Schmidinger wrote:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I've seen this - though at least one year ago - with bad reception due to bad weather. For half an hour, the system time was jumping back and forward like crazy, starting and stopping some timers. Luckily, all timers were repeating, so none of them was gone after reception was back.
So: Who is doing the CRC checks?
If CRC checking is enabled on dmx-filter setup (dmx_sct_filter_params.flags |= DMX_CKECK_CRC), the driver does it for you.
VDR doesn't enables the check. This would be difficult, as not all tables are CRC protected.
Regards.
Am Mittwoch 22 Juni 2005 00:10 schrieb Rainer Zocholl:
udo_richter@gmx.de(Udo Richter) 19.06.05 16:40
Klaus Schmidinger wrote:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I've seen this - though at least one year ago - with bad reception due to bad weather. For half an hour, the system time was jumping back and forward like crazy, starting and stopping some timers. Luckily, all timers were repeating, so none of them was gone after reception was back.
So: Who is doing the CRC checks? Maybe it's turned off or only an error bit is set but nobody cares about in further processing? (Maybe the cause for "unkown picture type" too?)
It's very unlikely that garbage can so often pass a CRC32 check.
The TDT is not specified to contain a CRC32 checksum. All larger tables have this, NIT, EIT, SDT, also TOT. The "small" ones TDT and RST have no checksum.
Marcel
Rainer
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Birgit & Andreas Böttger schrieb:
Since one hour I use ZDF to get the system time from, waiting for "ignored to avoid time warp :)".
Jun 22 07:33:12 vdr vdr[4284]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;039;005;051;017; Jun 22 07:33:23 vdr vdr[4287]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;040;005;087;087; Jun 22 07:33:23 vdr vdr[4287]: DEBUG cTDT::cTDT() Data: 112;112;005;209;040;005;087;087; Jun 22 07:33:23 vdr vdr[4287]: diff = 87874, ignored to avoid time warp :) Jun 22 07:33:24 vdr vdr[4287]: DEBUG cSectionHandler::Action() Length: 8, buf: 112;112;005;209;040;005;087;088; Jun 22 07:33:24 vdr vdr[4287]: DEBUG cTDT::cTDT() Data: 112;112;005;209;040;005;087;088; Jun 22 07:33:24 vdr vdr[4287]: System Time = Wed Jun 22 07:33:24 2005 (1119418404) Jun 22 07:33:24 vdr vdr[4287]: Local Time = Thu Jun 23 07:57:58 2005 (1119506278) Jun 23 07:57:58 vdr nvram-wakeup[10132]: RTC is not synchronously with system time! Jun 23 07:57:58 vdr nvram-wakeup[10132]: RTC isn't running in localtime nor in UTC/GMT time!
This is no garbage! It seems, that the time base of this transponder was wrong...
Ok, I will try the next transponder: ProSiebenSat.1
Kind regards Andreas Böttger
fboettger@t-online.de(Birgit & Andreas Böttger) 22.06.05 20:50
Jun 23 07:57:58 vdr nvram-wakeup[10132]: RTC is not synchronously with system time! Jun 23 07:57:58 vdr nvram-wakeup[10132]: RTC isn't running in localtime nor in UTC/GMT time!
This is no garbage! It seems, that the time base of this transponder was wrong...
Ok, I will try the next transponder: ProSiebenSat.1
It's usually not wise to use comerical transpnoders for such purposes, there timers are often broken. (They have no interest in your recording and skipping the adds!
Some time ago ZDF had, by "law", to transmitt a very exact 15,625kHz scan frequency for germany analog TV. I would assume that they still deliver a reliable time.
I see+hear a 6(!)sec gap between DVB-T and DVB-S for ARD, while ZDF is synchronous on both media (meanwhile).
Rainer
s.huelswitt@gmx.de(Stefan Huelswitt) 22.06.05 15:11
On 22 Jun 2005 Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.topp
Klaus Schmidinger wrote:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there? Maybe somebody should try to find out why that "garbage" is produced in the first place...
I've seen this - though at least one year ago - with bad reception due to bad weather. For half an hour, the system time was jumping back and forward like crazy, starting and stopping some timers. Luckily, all timers were repeating, so none of them was gone after reception was back.
So: Who is doing the CRC checks?
If CRC checking is enabled on dmx-filter setup (dmx_sct_filter_params.flags |= DMX_CKECK_CRC), the driver does it for you.
And what happens with the data if it fails? Is it decarded or just "tagged" to be invalid?
VDR doesn't enables the check.
Ah, that explains easily the "garbage" in "time", or? Does that explain the "unknown picture type" problem too?
This would be difficult, as not all tables are CRC protected.
VDR knows which tables are CRC protected, or not?
Rainer
marcel.wiesweg@gmx.de(Marcel Wiesweg) 22.06.05 19:09
Am Mittwoch 22 Juni 2005 00:10 schrieb Rainer Zocholl:
udo_richter@gmx.de(Udo Richter) 19.06.05 16:40
Klaus Schmidinger wrote:
Isn't all that data protected by CRC32 checksums? How could "garbage" get in there?
Maybe somebody should try to find out why that "garbage" is produced in the first place...
I've seen this - though at least one year ago - with bad reception due to bad weather. For half an hour, the system time was jumping back and forward like crazy, starting and stopping some timers. Luckily, all timers were repeating, so none of them was gone after reception was back.
So: Who is doing the CRC checks? Maybe it's turned off or only an error bit is set but nobody cares about in further processing? (Maybe the cause for "unkown picture type" too?)
It's very unlikely that garbage can so often pass a CRC32 check.
The TDT is not specified to contain a CRC32 checksum.
That makes (a bit) sense because that information is "transient" anyway (what's the use of a time 10 minutes ago when i woudl have to know it was 10min ago??)
Ok, then we can "forget" to use raw TDT to set system time.
All larger tables have this, NIT, EIT, SDT, also TOT. The "small" ones TDT and RST have no checksum.
So the only way use the time table would be to implement tests like "ntp" uses.
(taking at least 3 probes, limit the time skip to only few seconds etc.)
Rainer
On 23 Jun 2005 Rainer Zocholl UseNet-Posting-Nospam-74308-@zocki.toppoint.de wrote:
s.huelswitt@gmx.de(Stefan Huelswitt) 22.06.05 15:11
If CRC checking is enabled on dmx-filter setup (dmx_sct_filter_params.flags |= DMX_CKECK_CRC), the driver does it for you.
And what happens with the data if it fails? Is it decarded or just "tagged" to be invalid?
AFAIK it's discarded by the driver.
VDR doesn't enables the check.
Ah, that explains easily the "garbage" in "time", or? Does that explain the "unknown picture type" problem too?
AFAIK CRC checking only applies to section data and not to PES data.
This would be difficult, as not all tables are CRC protected.
VDR knows which tables are CRC protected, or not?
I think this can easily be tested out (if not documented somewhere in the DVB specs), but VDRs filter API would have to be extended to support CRC selection.
Regards.
s.huelswitt@gmx.de(Stefan Huelswitt) 23.06.05 15:55
Once upon a time "Stefan Huelswitt " shaped the electrons to say...
On 23 Jun 2005 Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.topp
oint.de> wrote: s.huelswitt@gmx.de(Stefan Huelswitt) 22.06.05 15:11
If CRC checking is enabled on dmx-filter setup (dmx_sct_filter_params.flags |= DMX_CKECK_CRC), the driver does it for you.
And what happens with the data if it fails? Is it decarded or just "tagged" to be invalid?
AFAIK it's discarded by the driver.
Then a wrong time would never reach VDR.
VDR doesn't enables the check.
Ah, that explains easily the "garbage" in "time", or? Does that explain the "unknown picture type" problem too?
AFAIK CRC checking only applies to section data and not to PES data.
This would be difficult, as not all tables are CRC protected.
VDR knows which tables are CRC protected, or not?
I think this can easily be tested out (if not documented somewhere in the DVB specs), but VDRs filter API would have to be extended to support CRC selection.
qwww...;.(
Thanks anyway! Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
On 23 Jun 2005 Rainer Zocholl UseNet-Posting-Nospam-74308-@zocki.toppoint.de wrote:
s.huelswitt@gmx.de(Stefan Huelswitt) 23.06.05 15:55
Once upon a time "Stefan Huelswitt " shaped the electrons to say...
On 23 Jun 2005 Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.topp
oint.de> wrote: s.huelswitt@gmx.de(Stefan Huelswitt) 22.06.05 15:11
If CRC checking is enabled on dmx-filter setup (dmx_sct_filter_params.flags |= DMX_CKECK_CRC), the driver does it for you.
And what happens with the data if it fails? Is it decarded or just "tagged" to be invalid?
AFAIK it's discarded by the driver.
Then a wrong time would never reach VDR.
See line below ;)
VDR doesn't enables the check.
Ah, that explains easily the "garbage" in "time", or? Does that explain the "unknown picture type" problem too?
AFAIK CRC checking only applies to section data and not to PES data.
This would be difficult, as not all tables are CRC protected.
VDR knows which tables are CRC protected, or not?
I think this can easily be tested out (if not documented somewhere in the DVB specs), but VDRs filter API would have to be extended to support CRC selection.
qwww...;.(
Thanks anyway! Rainer---<=====> Vertraulich // // <=====>--------------ocholl, Kiel, Germany ------------
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Rainer Zocholl schrieb:
It's usually not wise to use comerical transpnoders for such purposes, there timers are often broken. (They have no interest in your recording and skipping the adds!
Hmm, beside the garbage (caught by my patch) all tested transponders (other than ARD, 21 seconds to late) have correct time.
Some time ago ZDF had, by "law", to transmitt a very exact 15,625kHz scan frequency for germany analog TV. I would assume that they still deliver a reliable time.
Yesterday ZDF had a gab of one day for some minutes :)
With the patch, garbage (bad reception or what ever) is no problem, because those values will never be the same twice. But if a transponder is out of time (ARD and ZDF in my tests) we have no chance to detect that. Checking more than two values is useless imho. We could limit the time correction to some seconds, but if the system time is totaly wrong after a crash, we need a (very) big step asap...
Kind regards Andreas Böttger
s.huelswitt@gmx.de(Stefan Huelswitt) 23.06.05 18:36
Once upon a time "Stefan Huelswitt " shaped the electrons to say...
On 23 Jun 2005 Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.topp
oint.de> wrote: s.huelswitt@gmx.de(Stefan Huelswitt) 23.06.05 15:55
Once upon a time "Stefan Huelswitt " shaped the electrons to say...
On 23 Jun 2005 Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.to
pp oint.de> wrote: s.huelswitt@gmx.de(Stefan Huelswitt) 22.06.05 15:11
If CRC checking is enabled on dmx-filter setup (dmx_sct_filter_params.flags |= DMX_CKECK_CRC), the driver does it for you.
And what happens with the data if it fails? Is it decarded or just "tagged" to be invalid?
AFAIK it's discarded by the driver.
Then a wrong time would never reach VDR.
See line below ;)
VDR doesn't enable the check.
That's why i wrote "would" ;-)
Rainer
I use the nice "set system time" feature of vdr. But sometimes vdr seems to read gabage time from DVB,
I hereby vote to fix this. I lost a recording today because of time errors. See my (reduced) syslog:
Jun 25 19:00:06 vdr[947]: confirm: Taste drücken um Shutdown abzubrechen Jun 25 19:01:09 vdr[1219]: System Time = Sat Jun 25 19:01:09 2005 (1119718869) Jun 25 19:01:09 vdr[1219]: Local Time = Wed Jun 29 07:01:10 2005 (1120021270) Jun 29 07:01:10 vdr[947]: confirmed Jun 29 07:01:11 vdr[947]: executing '/usr/local/bin/vdrshutdown 1119734700 -286571 18 "Richling - Zwerch trifft Fell" 0' Jun 29 07:01:13 nvram-wakeup[1434]: Do NOT write into nvram. Wake Up time must be Jun 29 07:01:13 nvram-wakeup[1434]: at least 10 minutes in the future. Jun 29 07:01:13 vdr[947]: deleting timer 19 (18 2325-0010 'Richling - Zwerch trifft Fell') Jun 29 07:01:15 vdr[947]: SVDRP message: 'NVRAM-Wakeup failed...' Jun 29 07:01:15 vdr[947]: info: NVRAM-Wakeup failed... Jun 29 07:01:15 vdr[947]: closing SVDRP connection Jun 29 07:01:16 vdr[1211]: System Time = Wed Jun 29 07:01:16 2005 (1120021276) Jun 29 07:01:16 vdr[1211]: Local Time = Sat Jun 25 19:01:17 2005 (1119718877) Jun 25 19:01:17 vdr[1219]: System Time = Wed Jun 29 07:01:16 2005 (1120021276) Jun 25 19:01:17 vdr[1219]: Local Time = Sat Jun 25 19:01:17 2005 (1119718877)
The machine kept running for another 9 hours with the 'NVRAM-Wakeup failed...' message on screen before I noticed this. Of course the timer 19 was not recorded, though the machine was running at that time.
Cheers,
Udo
Udo Richter schrieb:
I use the nice "set system time" feature of vdr. But sometimes vdr seems to read gabage time from DVB,
I hereby vote to fix this. I lost a recording today because of time errors.
After some tests with other transponders, I currently use RTL again to set system time, because this is the most used transponder here.
Sometimes there are "garbage times", but this is no problem any longer :)
Jun 24 09:25:16 vdr vdr[20898]: diff = 86398, ignored to avoid time warp :) Jun 24 09:33:38 vdr vdr[20898]: diff = 1047043634, ignored to avoid time warp :) Jun 24 09:33:47 vdr vdr[20898]: diff = 5038, ignored to avoid time warp :) Jun 24 09:42:10 vdr vdr[20898]: diff = 49262, ignored to avoid time warp :) Jun 24 09:50:33 vdr vdr[20898]: diff = 1322, ignored to avoid time warp :) Jun 24 10:33:29 vdr vdr[20898]: diff = 2843878, ignored to avoid time warp :) Jun 24 10:33:31 vdr vdr[20898]: diff = 3314218, ignored to avoid time warp :) Jun 24 10:50:36 vdr vdr[20898]: diff = 1742, ignored to avoid time warp :) Jun 24 10:58:52 vdr vdr[20898]: diff = 528958, ignored to avoid time warp :) Jun 24 10:58:56 vdr vdr[20898]: diff = 2132884262, ignored to avoid time warp :) Jun 24 11:15:47 vdr vdr[20898]: diff = 9461758, ignored to avoid time warp :) Jun 24 11:24:11 vdr vdr[20898]: diff = 22082, ignored to avoid time warp :) Jun 24 16:00:54 vdr vdr[11790]: diff = 1916301377, ignored to avoid time warp :) Jun 24 16:17:48 vdr vdr[11790]: diff = 1744739819, ignored to avoid time warp :) Jun 24 17:08:13 vdr vdr[11790]: diff = 145784339, ignored to avoid time warp :) Jun 24 17:24:55 vdr vdr[11790]: diff = 179202481, ignored to avoid time warp :) Jun 24 17:41:52 vdr vdr[11790]: diff = 1618607957, ignored to avoid time warp :) Jun 25 11:53:46 vdr vdr[7595]: diff = 9153240, ignored to avoid time warp :) Jun 25 12:52:28 vdr vdr[7595]: diff = 3000, ignored to avoid time warp :) Jun 25 13:09:24 vdr vdr[7595]: diff = 4380, ignored to avoid time warp :) Jun 25 13:31:05 vdr vdr[7595]: diff = 3017820, ignored to avoid time warp :) Jun 25 13:47:48 vdr vdr[7595]: diff = 5160, ignored to avoid time warp :) Jun 25 14:04:47 vdr vdr[7595]: diff = 5441340, ignored to avoid time warp :) Jun 25 14:55:18 vdr vdr[7595]: diff = 1119704119, ignored to avoid time warp :) Jun 25 16:16:53 vdr vdr[7595]: diff = 311639, ignored to avoid time warp :) Jun 25 16:58:58 vdr vdr[7595]: diff = 2281, ignored to avoid time warp :) Jun 25 16:59:05 vdr vdr[7595]: diff = 69059, ignored to avoid time warp :) Jun 25 17:15:54 vdr vdr[7595]: diff = 8399, ignored to avoid time warp :)
To help you, I have attached a patch against vdr-1.3.27. This patch should also work with older versions of vdr. Go to the VDR directory and type: patch < vdr-1.3.27_time_warp.diff
Kind regards Andreas Böttger
diff -Nur vdr-1.3.27.ori/eit.c vdr-1.3.27/eit.c --- vdr-1.3.27.ori/eit.c 2005-06-11 17:31:21.000000000 +0200 +++ vdr-1.3.27/eit.c 2005-06-25 09:23:57.000000000 +0200 @@ -266,14 +266,21 @@ time_t sattim = getTime(); time_t loctim = time(NULL);
- if (abs(sattim - loctim) > 2) { - mutex.Lock(); - isyslog("System Time = %s (%ld)\n", *TimeToString(loctim), loctim); - isyslog("Local Time = %s (%ld)\n", *TimeToString(sattim), sattim); - if (stime(&sattim) < 0) - esyslog("ERROR while setting system time: %m"); - mutex.Unlock(); + static int lastDiff = 0; + int diff = abs(sattim - loctim); + if (diff > 2) { + if (abs(diff - lastDiff) < 3) { + mutex.Lock(); + isyslog("System Time = %s (%ld)\n", *TimeToString(loctim), loctim); + isyslog("Local Time = %s (%ld)\n", *TimeToString(sattim), sattim); + if (stime(&sattim) < 0) + esyslog("ERROR while setting system time: %m"); + mutex.Unlock(); + } else { + isyslog("diff = %d, ignored to avoid time warp :)", diff); } + lastDiff = diff; + } }
Birgit & Andreas Böttger wrote:
After some tests with other transponders, I currently use RTL again to set system time, because this is the most used transponder here.
I'm pretty sure my case of time warping was due to bad weather. I've not been home that time, but it was perfect sat dropout weather.
To help you, I have attached a patch against vdr-1.3.27. This patch should also work with older versions of vdr.
Nice, but I'll have to merge it with the settime patch (using external shell script to set time via sudo). Not a big deal, I'll write something similar to yours.
Cheers,
Udo
Udo Richter wrote:
Birgit & Andreas Böttger wrote: [...]
To help you, I have attached a patch against vdr-1.3.27. This patch should also work with older versions of vdr.
Nice, but I'll have to merge it with the settime patch (using external shell script to set time via sudo). Not a big deal, I'll write something similar to yours.
Let vdr do the user switching and save yourself from such hacks: http://www.suse.de/~lnussel/vdr/vdr-1.3.24-su.diff
cu Ludwig
On Mon, 2005-06-27 at 11:00 +0200, Ludwig Nussel wrote:
Udo Richter wrote:
Nice, but I'll have to merge it with the settime patch (using external shell script to set time via sudo). Not a big deal, I'll write something similar to yours.
Let vdr do the user switching and save yourself from such hacks: http://www.suse.de/~lnussel/vdr/vdr-1.3.24-su.diff
Nifty. Attached is a patch (to be applied over the above one) that makes it use the reentrant get*nam variants, making it compilable with a "thread poison" patched VDR. Caveat: I don't claim to understand the patch fully, it was mostly kind of borrowed from dbus :)
-
Birgit & Andreas Böttger -
Klaus Schmidinger -
Ludwig Nussel -
Marcel Wiesweg -
Rainer Zocholl -
s.huelswitt＠gmx.de -
Sergei Haller -
Udo Richter -
Ville Skyttä