Re: AW: [vdr] Problem with audio sync in playback - maybe caused by ntpd stepping local clock?
martin wrote: ... I am not sure about, how actually the time is set via VDR. Maybe Klaus can give us a hint. See cTDT::cTDT() in eit.c. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AW: AW: [vdr] Problem with audio sync in playback - maybe caused by ntpd stepping local clock?
Oh .. documentation by source :) *smile* So, as far as i can read with my basic knowledge: if there is a difference of more then 2 (don't know the unit, but I think it must be seconds), there is a step in time. This can be sometimes not so nice, as it can give consistency problems (e.g.: timestamps in syslog or file system) So ntpdate would be the more advanced way, if you have a internet connection available. Regards, Martin -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Klaus Schmidinger Gesendet: Freitag, 20. Oktober 2006 13:54 An: vdr@linuxtv.org Betreff: Re: AW: [vdr] Problem with audio sync in playback - maybe caused by ntpd stepping local clock? martin wrote: ... I am not sure about, how actually the time is set via VDR. Maybe Klaus can give us a hint. See cTDT::cTDT() in eit.c. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: AW: [vdr] Problem with audio sync in playback - maybe caused by ntpd stepping local clock?
martin wrote: So, as far as i can read with my basic knowledge: if there is a difference of more then 2 (don't know the unit, but I think it must be seconds), there is a step in time. If SAT time and internal clock differ by more than 2 seconds, and this time offset is reported twice in a row, the clock is set in one step. This can be sometimes not so nice, as it can give consistency problems (e.g.: timestamps in syslog or file system) Even more severe. In case of very large time jumps, this can even lead to the famous video data stream broken and similar timeout issues. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
RE: [vdr] Problem with audio sync in playback
I tested with VDR 1.4.3 and test_av app included in 22623 test firmware package, with firmwares 261a, 261f, 2622 and that test version 22623. Everytime playback stuttered and lost a/v sync after scene change situation. So I think this is more like dvb firmware/driver problem than VDR problem. However this is very annoying. I agree, this is not VDR problem but firmware. However, I don't know which mailing list is better to report this problem: vdr or dvb thus I've sent this here. My gut feeling is that these problems appeared around when AC3 bitstream out came into DVB firmware, and I think that was done by Werner Fink. I think he has kept knowledge by himself, so maybe he should be able fix the situation? http://www.linuxtv.org/download/firmware/ 2004-12-26 dvb-ttpci-01.fw-261d Changes by Werner Fink: - Implement AC3/DTS replay capability - Proper handling of OSD bitmap loading with timeouts - Set interpolated option of video decoder to reduce block noise on hard picture changes - FlushTS command fixes 2003-10-13 dvb-ttpci-01.fw-261b fixed distortions when switching channel while recording .. 2003-07-09 dvb-ttpci-01.fw-261a (this is the first new type of firmware(is it?), and was already tested by you) But this is a feeling, not a fact. So maybe older default firmware for old type of driver should be tested, I mean not dvb-ttpci* type of file, I mean Root Dpram -files. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
