Nachdem mir LordJaxom freundlicherweise Zugriff auf seinen VDR gegeben
hat, wo der UPT-Fehler sehr gut reproduzierbar auftritt, habe ich nun endlich
eine ganz heiße Spur gefunden 
Die Ursache des Problems ist anscheinend, daß VDR die PIDs bereits setzt,
wenn der Tuner evtl. noch keinen Lock hat. Wenn man nach dem Tunen wartet
bis ein Lock da ist und erst dann die PIDs setzt, scheint der UPT-Fehler
nicht mehr aufzutreten - zumindest konnte ich ihn trotz heftigstem Zappen
auf LordJaxom's Maschine nicht mehr hervorrufen (und vor der Änderung
trat er dort manchmal schon nach einmaligem Umschalten auf).
Ok, hier also ein schneller Hack, damit alle UPT-Geplagten das vorab schon
mal testen können. Es ist für VDR 1.2.6 und 1.3.x die gleiche Änderung, nämlich
--- dvbdevice.c 2004/01/25 13:50:21 1.79
+++ dvbdevice.c 2004/02/06 15:44:57
@@ -751,6 +751,11 @@
dvbTuner->Set(Channel, DoTune, !EITScanner.UsesDevice(this)); //XXX 1.3: this is an ugly hack - find a cleaner solution//XXX
+ //XXX
+ time_t t0 = time(NULL);
+ while (!dvbTuner->Locked() && time(NULL) - t0 < 5)
+ fprintf(stderr, ".");
+ //XXX
// PID settings:
if (TurnOnLivePIDs) {Bei VDR 1.2.6 dürften die Zeilennummern anders sein, aber sucht einfach
in VDR/dvbdevice.c nach "PID settings" und fügt die Zeilen davor ein. Die
Ausgabe ist momentan nur um zu sehen, ob er da reinkommt.
In VDR 1.2.6 muß zusätzlich noch die Zeile
bool Locked(void) { return tunerStatus == tsLocked; }
in cDvbTuner nach
bool Locked(void) { return tunerStatus >= tsLocked; }
geändert werden.
So, vielleicht haben wir ja Glück und der UPT-Fehler ist damit behoben.
Im Moment wird dadurch das Kanalumschalten wohl etwas langsamer,
aber ich werde das dann alles in den cDvbTuner-Thread verlagern, so daß es
wieder so schnell gehen sollte wie gewohnt. Im Moment wäre mir erstmal
wichtig zu erfahren, ob es jemanden gibt, der trotz dieser Änderung den
UPT-Fehler immer noch bekommt.
Klaus
