GE: Fehler in erster bei Start einer zweiten Aufnahme

[Oliver59]

Hallo,

 

neulich habe ich die Tonspuren von sich überschneidenden Hörfilmen aufgenommen. Immer in der Sekunde, in der die zweite Aufnahme startete, trat in der ersten ein Fehler auf. Hier die Auszüge der Logdateien:

 

21:42:01 / 00:00:00 (~ 0,0 MB) Start -> Frühling im Herbst Bayerisches FS Süd (mis) 10-10 21-42-01.mp2

21:42:01 / 00:00:00 (~ 0,0 MB) PID 203: MPEG Audio Stereo, 48 kHz, 192 kbps

23:27:01 / 01:45:00 (~ 144,2 MB) Errors: 1

23:30:00 / 01:47:59 (~ 148,3 MB) Stop

 

23:27:01 / 00:00:00 (~ 0,0 MB) Start -> Große Freiheit Nr- 7 hr-fernsehen (mis) 10-10 23-27-01.mp2

23:27:02 / 00:00:01 (~ 0,0 MB) PID 303: MPEG Audio Stereo, 48 kHz, 192 kbps

00:17:01 / 00:50:00 (~ 68,6 MB) Errors: 1

01:30:00 / 02:02:59 (~ 168,9 MB) Stop

 

00:17:01 / 00:00:00 (~ 0,0 MB) Start -> Jahr des Drachen Das Erste (mis) 10-11 00-17-01.mp2

00:17:01 / 00:00:00 (~ 0,0 MB) PID 103: MPEG Audio Stereo, 48 kHz, 192 kbps

02:08:00 / 01:50:59 (~ 152,4 MB) Stop

 

Beim Schneiden mit mp3directcut traten dann auch Resyncs auf. Woran kann die Beeinflussung einer Aufnahme durch eine zweite liegen bzw. wie kann ich das vermeiden?

 

Gruß

 

Oliver

[Griga]

Woran kann die Beeinflussung einer Aufnahme durch eine zweite liegen

Bekannt ist das Problem bei bestimmten Kombinationen von DVB-Geräten. Wenn ein zweites Gerät für eine zweite Aufnahme initialisiert und getuned wird, kann es passieren, dass es das erste Gerät bzw. dessen Treiber kurzzeitig beeinträchtigt.

 

Diese Erklärung kommt bei dir jedoch nicht in Frage, da alle aufgenommenen Sender auf dem selben Transponder liegen, sie sich also mit einem Tuner aufnehmen lassen, und du hast auch nur einen.

 

Deshalb ist bei deinem schwachbrüstigen System (Intel Atom N270...) anzunehmen, dass die Vorgänge während eines Aufnahmestarts den PC so auslasten, dass der DVB-Gerätetreiber kurzzeitig ins Hintertreffen gerät und Daten verliert - insbesondere, wenn während der Aufnahmen ein Sender wiedergegeben wird. War das der Fall?

[Oliver59]

anzunehmen, dass die Vorgänge während eines Aufnahmestarts den PC so auslasten, dass der DVB-Gerätetreiber kurzzeitig ins Hintertreffen gerät und Daten verliert - insbesondere, wenn während der Aufnahmen ein Sender wiedergegeben wird. War das der Fall?

Nein.

[Griga]

Tja, dann musst du wohl selbst durch gezielte Versuche herausfinden, ob das an irgendwelchen von dir beeinflussbaren Bedingungen liegt. Aus der Ferne lässt sich kaum erahnen, was sich in deinem System abspielt. Zum Beispiel: Passiert es auch, wenn du während einer laufenden Aufnahme eine weitere Aufnahme eines anderen Senders manuell startest?

 

In deiner Setup.ini ist mir noch eine maßlose Übertreibung aufgefallen. Du verwendest den internen Aufgabenplaner des DVBViewer GE und lässt ihn 9 Timeraufnahmen im Voraus an den Windows Taskplaner übergeben. Das ist glatter Overkill. Zwei oder drei sollten auf alle Fälle reichen, und im Prinzip - nämlich wenn alles glatt läuft - sogar nur eine.

 

Der DVBViewer GE synchronisiert ohnehin seine Liste der Timer-Aufnahmen bei jedem Programmstart und Timer-Aufnahmestart neu mit dem Windos Taskplaner, d.h. sobald eine Timer-Aufnahme wegen Ausführung aus der Liste verschwindet, erhält der Windows Taskplaner automatisch die jeweils nächste. Wenn der DVBViewer GE dabei unsinnigerweise 9 Einträge übergibt (falls so viele nachfolgende Aufnahmen existieren), erzeugt das eine Menge Traffic in deinem PC. Auch das könnte zu Aufnahmefehlern beitragen.

[Oliver59]

Hallo Griga,

 

nun habe ich den Effekt mit Version 3.3.1 auf einem deutlich leistungsfähigeren System (Pentium B970) wieder: Gestern nahm ich aus dem Ruhezustand ohne Wiedergabe von 20.12 bis 22 Uhr Das Erste SD und von 20.57 bis 22 Uhr WDR Köln SD auf, und just um 20.57 Uhr hat die erste Aufnahme wieder einen Error. Den Aufgabenplaner lasse ich nur drei Tasks übergeben. Die support.zip liegt Dir ja vor.

Dürfen denn zwei Aufnahmen nur gleichzeitig starten? Auch dann tritt der Error gelegentlich auf, stört aber nicht, weil man den Anfang ja ohnehin schneidet.

 

Gruß

 

Oliver

[Griga]

und just um 20.57 Uhr hat die erste Aufnahme wieder einen Error.

Also nur einen diesmal, keine ganze Serie wie im letzten Log?

 

Wenn sich überschneidende Aufnahmen im Windows Aufgabenplaner vermerkt sind, versucht dieser, den DVBViewer GE ein zweites Mal zu starten, was sich leider nicht verhindern lässt. Die zweite GE-Instanz merkt jedoch, dass bereits eine läuft, und beendet sich sofort wieder. Trotzdem verursacht der Vorgang kurzzeitig Prozessorlast und Festplattenzugriffe, was unter ungünstigen Umständen zu Datenverlusten im Treiber des DVB-Gerätes führen kann. Dies gilt insbesondere, wenn ein Virenscanner alle Zugriffe überwacht.

 

Du kannst versuchen, die Priorität des DVBViewer GE unter Optionen - Allgemein zu erhöhen, zum Beispiel auf "Höher als normal" oder sogar "hoch". Dadurch räumt Windows dem DVBViewer GE bei der Zuteilung von Prozessorzeit gegenüber anderen Anwendungen Vorrang ein. Wenn man viele Aufnahmen durchführt, ist das ohnehin zu empfehlen. Die zweite Instanz startet mit normaler Priorität und beendet sich, bevor sie die eingestellte höhere Priorität erreicht, hat dann also effektiv eine niedrigere Priorität als die bereits laufende Instanz.

[Oliver59]

Also nur einen diesmal, keine ganze Serie wie im letzten Log?

 

Ja. Seit der Panne letzten Donnerstag wurden wieder etliche Aufnahmen einwandfrei durchgeführt.

 

 

Die zweite GE-Instanz merkt jedoch, dass bereits eine läuft, und beendet sich sofort wieder. Trotzdem verursacht der Vorgang kurzzeitig Prozessorlast und Festplattenzugriffe, was unter ungünstigen Umständen zu Datenverlusten im Treiber des DVB-Gerätes führen kann. Dies gilt insbesondere, wenn ein Virenscanner alle Zugriffe überwacht.

 

Bringt es etwas, bestimmte Dateien von der Prüfung auszuschließen?

 

 

Du kannst versuchen, die Priorität des DVBViewer GE unter Optionen - Allgemein zu erhöhen, zum Beispiel auf "Höher als normal"

 

Das war ohnehin eingestellt.

 

Gruß

 

Oliver

[Griga]

Bringt es etwas, bestimmte Dateien von der Prüfung auszuschließen?

 

Keine Ahnung. Das ist systemspezifisch. Du musst es einfach probieren.

[Mr. Bun]

Wenn sich überschneidende Aufnahmen im Windows Aufgabenplaner vermerkt sind, versucht dieser, den DVBViewer GE ein zweites Mal zu starten, was sich leider nicht verhindern lässt. Die zweite GE-Instanz merkt jedoch, dass bereits eine läuft, und beendet sich sofort wieder.

 

Das wäre nur dann eine mögliche Ursache, wenn die "zusätzliche Vorlaufzeit" Im Taskplaner auf null gesetzt wurde. Standardmäßig (und sinnvollerweise) finden die vom Aufgabenplaner veranlassten GE-Starts ja ein paar Minuten vor dem Aufnahmestart statt.

 

Jedenfalls habe ich das Phänomen "Aufnahmestart verursacht Störungen in laufender Aufnahme" sporadisch auch schon beobachtet. Und zwar in Einzelfällen sogar dann, wenn beide Aufnahmen auf dem selben Sender stattfanden - also nicht nur nicht getuned, sondern noch nicht mal andere PID's aus dem Stream gefiltert werden müssen.

 

Eine Ursache habe ich bisher nicht ermitteln können (alle Tests bei abgeschalteter Wiedergabe):

 

In einem Fall traten die Fehler nicht mehr auf, nachdem ich die Option "MPG/TS mit allen Tonspuren" deaktiviert hatte. Allerdings traten die Fehler zu einem späteren Zeitpunkt auch ohne diese Option auf.

 

Den gleichen Effekt (erst keine Fehler mehr, später dann doch wieder) hatte ich auch beim deaktivieren der Option "Video-Fülldaten entfernen".

 

In der Regel lassen sich aber selbst dutzende parallele Aufnahmen vom selben Transponder starten, ohne dass es zu Diskontinuitäten kommt.

 

Die einzige Abhilfe, die ich bisher gefunden habe, ist ein GE-Neustart. Danach treten diese Fehler erst mal (zumindest für einige Stunden) nicht mehr auf.

[Griga]

 

Das wäre nur dann eine mögliche Ursache, wenn die "zusätzliche Vorlaufzeit" Im Taskplaner auf null gesetzt wurde.

 

 

 

Stimmt, das habe ich nicht bedacht.

 

Jedenfalls habe ich das Phänomen "Aufnahmestart verursacht Störungen in laufender Aufnahme" sporadisch auch schon beobachtet. Und zwar in Einzelfällen sogar dann, wenn beide Aufnahmen auf dem selben Sender stattfanden - also nicht nur nicht getuned, sondern noch nicht mal andere PID's aus dem Stream gefiltert werden müssen.

 

Einem Stream einen neuen "Klienten" hinzuzufügen ist ein kritischer Moment, da hierbei zwei Threads um Zugriffe konkurrieren, die insbesondere bei einem Prozessor mit mehreren Kernen gleichzeitig stattfinden können. Der für Benutzer-Interaktionen zuständige UI-Thread muss eine Liste ändern, die PIDs und die Klienten enthält, die sie angefordert haben. Der Streaming Thread, der die Daten vom Treiber anliefert und an die Klienten verteilt, liest diese Liste permanent

 

Während einer Änderung der Liste darf der Streaming Thread auf keinen Fall auf undefinierte Zwischenzustände treffen, sonst drohen haarige Abstürze. Deshalb gibt es Code-Abschnitte, die als "kritisch" gekennzeichnet sind (Critical Section). Das Betriebssystem sorgt dafür, dass niemals zwei Threads gleichzeitig solche kritischen Abschnitte abarbeiten. Kurz gesagt wird ein Thread zeitweilig angehalten, wenn sich bereits ein anderer in dem kritischen Abschnitt befindet, und erst fortgesetzt, nachdem der andere den Abschnitt verlassen hat.

 

Wenn ein Rekorder aus dem UI heraus eine Anzahl PIDs anfordert, unterbricht er damit ein bereits laufendes Streaming mehrfach. Es ist nicht auszuschließen, dass der Thread dabei so in Verzug kommt, dass er Daten verliert - wenn auch nicht wahrscheinlich.

 

Sollte dies das Problem sein, bietet es sich an, die Priorität des Streaming Thread zu erhöhen (also die relative Priorität innerhalb der Anwendung). Dafür gibt es einen Mechanismus. In der Sektion [Hardware] der Datei Setup.ini befindet sich für jedes Gerät ein Eintrag der Art

 

Priority.0=1

 

der die Priorität des Streaming Thread bestimmt. Die Zahl hinter dem Punkt ist die Gerätenummer. Sie darf nicht geändert werden. Die 1 ist im DVBViewer GE ein Standardwert mit der Bedeutung "Priorität höher als normal", also leicht angehoben. 0 wäre normale Priorität. Diesen Wert kann man auf 2 ändern (gleich "höchste Priorität"). Der DVBViewer GE muss dabei geschlossen sein. Als Resultat wird dem Streaming Thread von Windows mehr Rechenzeit zugestanden, und er kommt nach einer Unterbrechung schneller wieder zum Zuge.

 

Dass sich die Diskontinuitäten nur schlecht gezielt reproduzieren lassen, dürfte daran liegen, dass sie stark von zufälligen Faktoren abhängen - es spielt eine Rolle, was sonst gerade im System los ist, ob der Treiber des DVB-Geräts gerade sofort Daten los werden muss oder nicht, usw. Der DVBViewer Pro verwendet übrigens 2 = höchste Priorität als Standard. Im DVBViewer GE gab es bislang keinen Anlass, über 1 hinauszugehen. Aber vielleicht ändert sich das jetzt. Probiert es bitte aus!

[Mr. Bun]

Danke für die Erläuterung.

Ich hatte bisher nur kurz Zeit, das Verhalten mit Priority.x=2 zu testen, es sah aber eher nach einer Verschlimmbesserung aus : Damit wurden schon direkt nach dem GE-Neustart Fehler durch startende Aufnahme in bereits laufenden Aufnahmen des selben Senders verursacht. Mit Priority.x=1 kommt es dazu - wie beschrieben - erst mal nicht. Ich werde das aber noch ausführlicher testen und auch eine Gegenprobe mit der Pro machen.

 

es spielt eine Rolle, was sonst gerade im System los ist

In diesen Tests war die GE die einzige geöffnete Anwendung (dazu noch Virenscanner etc, aber nicht was eine hohe CPU-Last erzeugt hätte).

Bisher habe ich diese Fehler übrigens nur auf dem Athlon II X2 System beobachtet, nicht aber auf dem Intel 4-Kern.

 

[Griga]

Passiert das auch bei einer Umschaltung des wiedergegebenen Senders auf einen anderen des selben Transponders, oder nur bei einem weiteren Aufnahmestart?