Aufhängen bei Empfangsproblemen

[daffy]

Irgendwo hatte ich schon einmal von Problemen des DVBViewer gelesen, bei schwierigen Empfangsbedingungen stabil zu bleiben - sprich die Software "bleibt stehen".

 

Nun, ich denke ich habe es geschafft, hinreichend schwierige Empfangsbedingungen mit einem Leihgerät Pinnacle PCTV 200e im Rhein-Main-Gebiet zu erzeugen :-)

 

Computer-Umgebung: Siehe Signatur, plus: "aktuelle Pro beta", Pinnacle PCTV 200e BDA-Treiber v. 1.4.1.1 (MicroTv Series USB Driver) mit FX2 Firmware 2.7 - und natürlich die Pinnacle PCTV 200e selbst. (Keine andere Software von Pinnacle ist installiert - ich habe die BDA-Treiber direkt aus dem Installationspaket extrahiert und per Hand installiert)

 

Geographische Umgebung: Rhein-Main, mitten im Top-Empfangsgebiet (Zimmerantenne) für DVB-T, allerdings vermutlich schwieriges Mikro-Klima für den Empfang ;-)

 

Zunächst die gute Nachricht: Prinzipiell funktioniert die PCTV 200e, trotz Anzeige einer geringen Signalstärke.

 

Und nun das Problem: Auf der Suche nach Empfang für Kanal 8 habe ich mit dem USB-Gerät und dessen eingebauter Antenne ein wenig "herumgewedelt". Ziel war die Erzeugung ... variabler ... Empfangsqualität. Nun, diese Aktion war auch relativ erfolgreich, denn a) blieb der DVBViewer gelegentlich stehen und bekomme ich nun auch die ARD auf Kanal 8 bei 15% Signalstärke rein :-)

 

Zum Thema Aufhängen des DVBViewer kann ich noch beitragen, daß er nicht *immer* stehenbleibt. Typischerweise wedele ich und das Bild setzt aus - danach setzt es wieder ein ... und so weiter und so fort. Das Ansteigen der Discontinuities im Filter kann man während dies Prozesses prima mitverfolgen. Nur: Gelegentlich bleibt der DVBViewer halt *doch* stehen. Ooops. :-)

 

Hiermit stelle ich mich für die nächste Woche oder so als Versuchskaninchen für problematischen DVB-T-Empfang und DVBViewer-Bleibt-Stehen-Experimente bereit. Danach geht die PCTV 200e wohl wieder an ihren Eigentümer zurück - es sei denn, es passiert noch ein Signalstärke-Wunder ;-)

 

Hinweis: Ich verwende noch den DVBSource 2.4.2.0 - 2.4.3 hole ich mir gleich.

[Guest Lars_MQ]

Hmm zum theme die lügen rund um DVB-T und die bittere wahrheit hat halalev ein sehr gutes faq geschrieben, zu finden im FAQ.

 

Sicherlich keine direkte hilfe, aber es zerstört erstmal ordentlich die überallfernsehen hype Der mistl ist empfindlicher als die zwei teleskop-stangen tischantenne, die wir vor über 30 jahren bei uns aufm campingplatz für den portable benutzt haben.

Ich kann das aus eigener erfahrung sagen: jedesmal, wenn mein hund mit dem schwanz wedelnd neben mir steht am schreibtisch, kriege ich die 3. programme nicht rein...

[daffy]

... die lügen rund um DVB-T und die bittere wahrheit ...

 

... hatte ich schon berücksichtigt. Deswegen auch die DVB-T-Leihgabe und noch kein Kauf ;-)

 

Ich poste hier nur um zur Verbesserung der Stabilität des DVBViewer beizutragen - mein DVB-S-Empfang ist dazu (Gottseidank!) nicht geeignet.

 

jedesmal, wenn mein hund mit dem schwanz wedelnd neben mir steht am schreibtisch, kriege ich die 3. programme nicht rein...

 

Aus Sicht des Hundes sicherlich praktisch: Bild bleibt stehen, Herrchen schaut auf, Hund hat Aufmerksamkeit <g>

[Guest Lars_MQ]

Oh der hat andere wege meine aufmerksamkeit zu erhaschen. Er weiss genau welcher arm der mausarm ist und blockiert den recht zielgenau

 

Die stabilität lässt sich nur in maßen verbessern, da viel von bda und dem treiber dafür abhängt und dort scheinen alle hersteller noch etwas zu üben.

 

Griga hat z.B. die terratec leute überzeugen müssen, das es sinnvoll ist, einen buffer in den treiber zu bauen, damit dort nicht bei jeder belastung des system disconties entstehen...

 

Aber wo wir im viewer was verbessern können, machen wir es auch.

 

Nachtrag: Mein bda teiber für dvb-t blockiert das gesamte system 60 sekunden (oder endlos) lang im settuner, ohne eine möglichkeit des abbruchs, wenn er keinen sauberen lock bekommt.

[daffy]

Ich poste hier nur um zur Verbesserung der Stabilität des DVBViewer beizutragen

 

Whoa.

 

Habe gerade mal ein wenig Silberfolie mit Überresten von Milka vor der Antenne hin und her gewedelt. Prompt ist der DVBViewer hängen geblieben.

 

Ah, trauschau! Ein wenig mehr Wedeln liefert folgendes Szenario:

 

Das Fernsehbild "steht" aber

 

* AC3Filter läuft noch (properies zeigen Bewegung, audio läuft)

* nvidia codec läuft auch noch (Bitrate-Anzeige zuckt)

* DVB Source läuft auch noch - allerdings ist Video PTS nach dem Wedeln drastisch verändert auf -13:-08:-58.-700 (und steigt wieder).

 

Ein "Rebuild Graph" löst das Problem.

 

Nächstes Szenario, da ich vergessen hatte von obigem Szenario einen Screenshot anzufertigen: Wir wedeln wieder mit den Resten einer Tafel Milka.

 

Bild und Ton setzen kurzzeitig aus - Discontinuities gibt es zuhauf und auch AC3Filter meldet Fehler im Audio stream. Das Gesamtsystem erholt sich aber nach wenigen Sekunden wieder - aber dann doch nicht vollständig: Video läuft wieder halbwegs flüssig, nur das Audio stottert und hinkt zwei bis drei Sekunden hinterher.

 

 

 

zeigt was im DVBSource (2.4.3) passiert - im Prinzup genau das umgekehrte Verhalten als bei dem ersten Szenario, wo Video PTS ins Negative sprang.

 

Ein "Rebuild Graph" löst das Problem - alles läuft wieder.

 

Vielleicht hilft ja eine Beschreibung dieses Verhaltens, den DVB Source (noch) robuster zu machen und das Gesamtsystem damit (noch) stabiler zu machen?

[daffy]

Nachtrag: Mein bda teiber für dvb-t blockiert das gesamte system 60 sekunden (oder endlos) lang im settuner, ohne eine möglichkeit des abbruchs, wenn er keinen sauberen lock bekommt.

 

Aua!

 

Welche Karte bzw. welches Hardware-Design ist das? Sowas kommt mir nicht ins Haus!

 

Die PCTV 200e verhält sich mit dem aktuellen Treiber problemlos - vorbehaltlich der Klärung der Frage, wer/was für das Hängen des DVBViewer bei Empfangsproblemen verantwortlich ist.

 

Als Kaufgerät hatte ich das WideView-Design mit dem WT-220U ins Auge gefaßt, unter anderem verkauft in bunten Papp-Kartons von dnt, Freecom, Hama und Yakumo.

[Guest Lars_MQ]

Welche Karte bzw. welches Hardware-Design ist das?

Ein technotrend treiber und ein gelabelter Technotrend stick. Ansonsten sehr gut, sieht aus wie ein schwangeres schweizer taschenmesser, ich brauch nur eine bessere antenne.

[Griga]

640 allocated buffers sind schlecht - das ist nämlich das Maximum. Danach hält ein WaitForSingleObject(hEvent,INFINITE) den Input-Stream an, bis wieder ein Puffer frei ist, bzw. der Inhalt an einen Decoder abgesetzt werden konnte .

 

Es muss eine Situation aufgetreten sein, in der die Decoder dem DVBViewer Filter über einen längeren Zeitraum keine Daten mehr abgenommen haben.

 

Eine kurze Rechnung: 640 Puffer á 8 KByte macht 5.242.880 Bytes. Gehen wir von einem Stream mit 3 MBit/s aus. Das sind 375.000 Bytes/s. Die bräuchten 5.242.880 / 375.000 = 14 s, um alle Puffer zu füllen.

 

Ich kann mir nicht vorstellen, welcher Vorgang die Decoder (oder vielleicht auch die Renderer) derart lahmlegt. Und derart kaputte PTS erzeugt. Deshalb fehlt mir eine konkrete Idee, wo man ansetzen könnte, außer bei dem INFINITE, das angesichts dieser Verhältnisse wohl deplatziert ist.

[Guest Lars_MQ]

Ich kann mir nicht vorstellen, welcher Vorgang die Decoder (oder vielleicht auch die Renderer) derart lahmlegt.

Milka machts möglich

[Griga]

Jetzt bin ich endlich auf die Idee gekommen, an meine Cinergy T2 die mitgelieferte Stabantenne anzuschließen (sonst Hausantenne, Diskontinuitäten absolut Fehlanzeige).

 

Aber hoffnungslos - ich kriege den Häng-Effekt nicht hin. Massenweise Diskontinuitäten, Bild steht oder produziert Klötzchen, Ton stockt. Durch sämtliche Sender geschaltet, Allocated Buffers bequemt sich bis 127, aber nicht mehr.

 

Muss mir wohl morgen eine Milka kaufen...

 

Allerdings ist mir dabei eine weitere Idee gekommen. Es gibt im Header der Transportstream-Pakete ein Flag:

 

transport_error_indicator -- The transport_error_indicator is a 1 bit flag. When set to '1' it indicates that at least 1 uncorrectable bit error exists in the associated Transport Stream packet. This bit may be set to '1' by entities external to the transport layer.

 

Also ein Paket mit Fehlern, die durch die im Transportstream eingebaute Fehlerkorrektur nicht behoben werden konnten. Datenschrott. Nun geht der DVBViewer traditionsgemäß davon aus, dass solche Pakete ihn erst gar nicht erreichen, da sie von der Hardware oder vom Treiber aussortiert werden. Bei der SkyStar2 ist das jedenfalls so.

 

Jedoch angenommen, andere Hardware bzw. deren Treiber liefert diesen Schrott hemmungslos ab.... dann kann alles mögliche passieren. Sowas müsste bereits im DVBViewer weggefiltert werden, nicht im DVBSource.

 

@Lars: Vielleicht kannst du das im nächsten Beta-Update berücksichtigen. Es handelt sich um das MSB im 2. Byte des Pakets:

 

//check transport_error_indicator
if Stream.Header[1] and $80 <> 0 then //faulty packet
 //discard it

[daffy]

640 allocated buffers sind schlecht - das ist nämlich das Maximum. Danach hält ein WaitForSingleObject(hEvent,INFINITE) den Input-Stream an, bis wieder ein Puffer frei ist, bzw. der Inhalt an einen Decoder abgesetzt werden konnte . 

 

Die Allocated Buffers sind während meines Wedelns immer gestiegen - ich habe wohl grob 30-40 Sekunden mit meinem improvisierten Fächer gespielt <g>.

 

Mit anderen Worten: Die Allocated Buffers habe ich nicht am Stück erzeugt, sondern scheibchenweise draufgepackt.

 

Kann man eine einzelne, kaputte PTS einigermaßen zuverlässig erkennen? Kann man zuverlässig erkennen, ob die Kombination aus Video PTS und Audio PTS in sich sinnvoll ist?

 

Einmal erkannt, könnte man doch einen kompletten "flush down the toilet" machen und damit einerseits die nachgelagerten Stufen vor Müll schützen und intern auch einen sinnvollen, konsistenten Zustand (inklusive Buffers zurück auf Null) wiederherstellen?

 

Die Frage ist halt: Wann ist alles verloren? Dann kann man reagieren ;-)

 

Und wenns hart auf hart kommt, dann kann man ja vielleicht eine Konfigurationsoption anbieten, die dem Anwender überläßt, ob er ein eher laufend stotterndes Bild haben möchte oder dann doch das Bild lieber nur dann angezeigt werden soll, wenn es als halbwegs stabil "erkannt" wird.

 

Disclaimer: Ich habe keine Ahnung, ob im System genügend Daten vorhanden sind, um derartige Entscheidungen zu treffen.

[Guest Lars_MQ]

Also um das mal deutlich zu sagen, eine solches verwerfen macht den empfang ncht besser! Also lieber überlegen, ob nicht doch ein anschluss an die hausantenne sinnvoll wäre, da ein stream voller fehler auf dauer auch keinen spass macht. Und es kann auch nicht aufgabe der applikation sein verhuntze oder ungenügende empfangsverhältnisse zu kompensieren.

[Griga]

eine solches verwerfen macht den empfang ncht besser!

 

Nein, sicher nicht. Aber verhindert vielleicht Hänger, Abstürze und sonstige unkontrollierbare Folgen durch Datenschrott. Denke daran, dass fast alle nachfolgenden TS-Verwerter im DVBViewer zwar auf Diskontinuitäten achten, aber ansonsten davon ausgehen, dass die Pakete in Ordnung sind.

 

Ich denke, das sollte geklärt werden. Notfalls mit einer GE-Testversion, die ich in den Mitgliederbereich hochlade.

[daffy]

Also um das mal deutlich zu sagen, eine solches verwerfen macht den empfang ncht besser!

 

Da stimme ich Dir vollkommen zu.

 

Allerdings habe ich bei Software den oftmals morbiden Drang, das gute Stück an seine Grenzen zu bringen ;-)

 

Mir ist klar, daß für einen ernsthaften Betrieb hardwareseitig etwas passieren muß - ob das nun eine bessere Antenne ist oder ein Stick mit besserem Tuner sei einmal dahingestellt. Die PCTV 200e wirds aber nur dann werden, wenn ich sie wirklich billig nachgeworfen bekomme.

 

[Angenehmer Nebeneffekt: Bei Verbesserung der Antennen-Situation würde sich wohl auch mein in Stereo grenzwertiger UKW-Empfang verbessern. Ich glaube wirklich, daß die paar Quadratmeter dieses speziellen Empfangsort hier in sich problematisch sind.]

[Griga]

Außerdem kann jeder von schlechtem Empfang erwischt werden. Da reicht ein kleines Unwetter.

 

Einmal erkannt, könnte man doch einen kompletten "flush down the toilet" machen

 

Schön gesagt aber dieser Flush ist nicht so einfach. Im DVBSource begegnen sich 4 Threads - Zulieferer, Video-Pin, Audio-Pin und die Applikation, die alles von außen kontolliert. Sozusagen die Gegend, wo sich CriticalSection und Event-Objekt gute Nacht sagen. Wenn dort ein Thread einfach die Toilettenspülung betätigt... naja, dann wirklich gute Nacht.

 

Zudem ist der DVBViewer Filter nur einer von mehreren TS-Verwertern im DVBViewer. Was z.B. der EPG-Parser in einer Krisensituation macht, weiß keiner so genau. Deshalb mein Drang, erst mal eine Lösung möglichst weit "unten" zu versuchen.