Bitte um Hilfe beim Debuggen: Absturz beim Umschalten der Audio-Spur in PES

Es läßt mir keine Ruhe, warum es beim Umschalten der Audio-Spur in PES-Aufnahmen immer wieder zu Abstürzen kommt. Eventuell schlummert da noch ein Bug, der sich auch bei TS-Aufnahmen auswirken könnte, halt eben nur mit niedrigerer Wahrscheinlichkeit. Bevor das nicht geklärt ist, habe ich kein gutes Gefühl mit der Version 2.0.0...

Zur Vorgehensweise: entferne die Zeilen

if (isPesRecording)
     return; // for some unknown reason this doesn't work with PES recordings - causes a segfault

in der Funktion cDvbPlayer::SetAudioTrack() (dvbplayer.c) und starte die Wiedergabe einer PES-Aufnahme, die mehrere Audio-Spuren enthält. Nun schalte mehrfach zwischen den Audio-Spuren hin und her. Irgendwann bleibt die Wiedergabe hängen und nach einiger Zeit schlägt der Watchdog zu und/oder er stürzt ab.

Es wäre nett, wenn einige von euch mal versuchen könnten, das erstens nachzuvollziehen und zweitens vielleicht sogar die Ursache zu finden. Mehr Augen sehen einfach mehr...

Klaus

Zitat von mini73

Moin!

Kannst du eine (nicht zu) kurze Aufnahme bereitstellen? Ich hab leider schon lange keine PES-Aufnahmen mehr...

Gerne. Schick mir bitte eine Email an vdr-bugs@tvdr.de, dann geb ich dir den URL (möchte das ungern "public" posten, man weiß ja nie, wer mitliest... ;-).
Andere Interessenten bitte ebenfalls einfach melden.

Klaus

Zitat von TheChief

Ich hab das ganze mal mit zwei PES Aufnahmen probiert und die Audiospuren mehrfach gewechselt. Konnte es leider nicht nachvollziehen. Das einizge was mit aufgefallen ist: Beim Wechseln der Audiospuren sprang die Wiedergabe einige Sekunden zurück. Könnte natürlich auch am Ausgabedevice liegen (sothddevice). Werd aber nochmal probieren.

Es tritt auch bei mir nicht immer auf. Manchmal dauert es 10, 20 mal bis es auftritt, manchmal sogar gar nicht und ich muß VDR neu starten, um es provozieren zu können. Sieht irgendwie nach Race-Condition aus...

Zitat

EDIT: Ich meine mich aber zu erinnern, dass ich das Problem früher mal mit xineliboutput oder xine hatte. Welche Ausgabe verwendest Du? dvbhddevice? Dann liegt der Fehler vielleicht dort.

Ja, ich benutze dvbhddevice. Aber bisher habe ich keinen Hinweis darauf gesehen, daß es daran liegen würde. Auszuschließen ist es natürlich auch nicht, darum wäre es sehr hilfreich, wenn jemand mit einem anderen Ausgabedevice es auch nachvollziehen könnte.
Wie gesagt, es tritt nur sporadisch auf.

Klaus

Zitat von UFO

Bei mir bleibt er reproduzierbar in LOCK_THREAD in Goto() hängen.
Wenn ich dies herausnehme, bleibt er in LOCK_THREAD in Empty() hängen.
Nehme ich dies auch heraus, funktioniert die Umschaltung meistens. Manchmal gibt es einen Segfault.

Das ist ja schon mal interessant...

Zitat

Was auffällt: Bei PES-Aufzeichnungen startet die Wiedergabe immer am Anfang.
Stimmt da etwas mit index oder resume nicht?

Bei mir startet er PES-Wiedergaben immer da, wo ich aufgehört habe. Es sei denn, er ist abgestürzt und konnt die resume.vdr nicht mehr schreiben. Könnte das dein Problem sein? Oder sind deine PES-Aufnahmen vielleicht in einem read-only Verzeichnis?

Klaus

Zitat von UFO

Liegt nicht an den Zugriffsrechten. resume.vdr wird geschrieben, aber offenbar beim Starten der Wiedergabe nicht beachtet. Es gab auch keinen Absturz.

Ich starte die PES-Wiedergabe, springe mit "rot" 30min nach vorne, stoppe mit "blau".
Drücke ich wieder "blau", geht es am Anfang wieder los.

Ich hab das jetzt mal versucht, nachzustellen, aber es verhält sich immer wie erwartet.
Dabei habe ich beim Springen um 30 Minuten nach vorne sowohl mit Play als auch mit Pause getestet.
Schon seltsam das...

Zitat

Ich vermute, es zeigt irgendwo ein Ptr in den Wald und es gibt einen Überschreiber "mit wechselndem Effekt".

Sehr wahrscheinlich - nur leider recht schwer zu finden...

Zitat

Am Beginn von Goto() lasse ich mir den "index"-Ptr ausgeben. In einem Fall hatte dieser einen merkwürdigen Wert. Dann gab es einen Segfault. Läßt sich momentan aber nicht mehr reproduzieren...

Hmm, das würde ja fast heißen, daß er sich den index-Pointer zerschießt.
Aber warum tritt das nur in dieser konkreten Konstellation auf? Goto() wird ja auch ansonsten immer wieder gemacht...

Klaus

Zitat von UFO

<edit>
Packt man das return in SetAudioTrack() wieder rein, funktioniert das Resume.
</edit>

Hab's gerade nochmal verifiziert, das Goto/Stop/Resume funktioniert bei mir mit und ohne das return.

Klaus

Zitat von UFO

Noch ein paar Erkenntnisse (SD-FF auf 32-Bit System):

Gut zu wissen, daß es schon mal nicht vom Ausgabedevice abhängt.

Zitat

Der LOCK_THREAD-Deadlock tritt immer auf - auch bei der Audio-Umschaltung von TS.
Hatte ich bisher nicht getestet.

Danke, das ist ein ganz wichtiger Hinweis. Bei mir war es bei TS nie und bei PES gleich beim ersten Versuch aufgetreten. Daher glaubte ich, daß es an PES liegt.
Also ist das jetzt momentan der "Show Stopper" für Version 2.0.0 ;-).

Zitat

Mit VDR 1.7.38 gibt es dieses Problem nicht, weder mit TS noch mit PES!

Der Goto()-Aufruf kam auch erst in der 1.7.39 rein, um das Stottern nach dem Umschalten des Audio-Tracks zu beheben.

Danke für deine Hinweise, Ich werde weiter forschen...

Klaus

Zitat von kls

Danke, das ist ein ganz wichtiger Hinweis. Bei mir war es bei TS nie und bei PES gleich beim ersten Versuch aufgetreten. Daher glaubte ich, daß es an PES liegt.

Nachdem ich jetzt immer weitere Debug-Ausgaben eingebaut habe, habe ich bemerkt, daß die Aufnahme, mit der ich zuletzt immer getestet hatte, doch eine TS-Aufnahme ist. Also ist das "... in PES" im Thread-Titel auf jeden Fall hinfällig. Die erste Aufnahme, bei der das Problem hier aufgetreten ist, war eine PES-Aufnahme, aber irgendwann muß ich wohl auf eine andere Aufnahme gewechselt sein, von der ich irrtümlich annahm, daß es auch eine PES-Aufnahme sei.

Inzwischen habe ich es auch mit einer ganz aktuellen TS-Aufnahme von gestern nachvollziehen können. Es ist also unabhängig von PES/TS und auch vom Alter der Aufnahme.
Am schnellsten kann man es provozieren, wenn man die "Audio"-Taste gedrückt hält und dadurch schnell durch die Tracks schaltet. Ein weiteres Indiz für ein Timing-Problem.

Das nur der Vollständigkeit halber. Ich verfolge jetzt die Lock-Problematik weiter...

Klaus

So, jetzt habe ich die Beteiligten an dem Deadlock ausgemacht.

cDvbPlayer::Action() macht LOCK_THREAD und lockt dann über cDevice::PlayTs() den mutexCurrentAudioTrack.

cDevice::SetCurrentAudioTrack() lockt den mutexCurrentAudioTrack und macht dann über cDvbPlayer::SetAudioTrack() und cDvbPlayer::Goto() ein LOCK_THREAD.

Also der "Klassiker", wie von Gerald schon so treffend bemerkt.

Mal sehen, wie ich das auflösen kann. Auf jeden Fall Danke an alle, die mitgemacht haben.

Klaus

Zitat von kls

Ich hab das jetzt mal versucht, nachzustellen, aber es verhält sich immer wie erwartet.
Dabei habe ich beim Springen um 30 Minuten nach vorne sowohl mit Play als auch mit Pause getestet.
Schon seltsam das...

War mein Fehler, da ich versehentlich mit einer TS-Aufnahme getestet hatte.
Nachdem ich es jetzt definitiv mit einer PES-Aufnahme probiert habe, kann ich das Problem doch nachvollziehen.
Sorry wegen der Falschmeldung.

Klaus

So, der erste Teil des Problems sollte mit beiliegendem Patch gelöst sein.
Nachdem in cDevice::PlayPesPacket() und cDevice::PlayTs() nur lesend auf availableTracks[current(Audio|Subtitle)Track].id zugegriffen wird und dieses Array immer an der gleichen Adresse liegt, sollte es hier auch ohne einen Lock auf mutexCurrentAudioTrack gehen. Bei intensiven Tests konnte ich zumindest keine Probleme mehr beobachten.

Klaus