VDR Portal

Quoted

Original von methodus

Ich hab bei mir hin und wieder Abstürze in der Art, dass das Bild einfriert und auch keinerlei Reaktion vom VDR mehr entgegen genommen wird. Ich weiß leider nicht, ob das von der PVR kommt oder von etwas anderem.. ich habe aber heute das Phänomen wieder gehabt, wobei diesmal der VDR noch reagiert und die Meldung "Transfer-Mode konnte nicht gestartet werden" kommt. Deswegen vermute ich, dass es daran liegt. Ich probier gleich mal die RC2 aus.

welche/wieviele PVR devices hast Du ?

ich habe tagelang versucht auf meinem Testsystem (mit einer PVR350 und einer PVRUSB2) einen freeze oder einen Transfermode-Fehler zu provozieren, aber es will mir einfach nicht gelingen...

dass die Meldung beim schnellen Umschalten kommen kann, ist nicht neu (war auch bei der 2008-10-04 so). Es ist durchaus gewollt gewesen, dass die ioctls zum Kanalwechsel erstmal in Ruhe abgearbeitet werden können, ehe schon wieder neue kommen. Dass die Funktion SetChannelDevice dabei diese blöde vdr-Fehlermeldung mit dem Transfermode auslöst, ist ein eher kosmetisches Problem. Wichtig ist, dass vdr hier nicht in einer Endlosschleife gefangen sein darf. Genau das war aber zumindest bei Tobias der Fall. Ich bin sicher, dass dieses Problem mit der rc2 gelöst ist.

Was die freezes angeht: Wenn das Bild nicht beim Kanalwechsel einfriert, sondern mitten im laufenden Betrieb, dann denke ich hier eher ein Hardware- oder Treiberproblem. Die ivtv-mailinglisten sind voll von solchen Fällen (Temperaturproblem, ausgetrocknete Elkos, DMA-Last auf VIA-Chipsätzen etc.).
Interessant wäre, ob diese Probleme abrupt mit dem Wechsel auf die neue pvrinput-Version begonnen haben, und ob zeitgleich auch Kernel/Treiber aktualisiert wurden.
An den buffer-Größen und dem laufenden read thread wurde im Plugin jedenfalls nichts verändert.

Quoted

Original von methodus
Das wäre jetzt natürlich schwer festzustellen, weil man für den neuen VDR meines erachtens IMMER auch einen neuen DVB-Treiber (API 5 gegenüber der 3 beim 1.6.0) benötigt. Ich habe mir die Liplianin-Treiber für meine CableStar installiert, worin doch auch die ivtv-Treiber enthalten sind, oder?

ich habe ja auch aktuelle v4l-dvb hg -Treiber laufen, und ich hoffe mal dass Liplianin sich da regelmäßig synchronisiert.

Quoted

Insofern kann ich es nicht ausschließen, dass es daran liegt. Aber zurück zum Transfer-Mode-Problem: heißt es, dass es weiterhin zu Fehlern kommen kann, aber nicht so schlimm sind, sofern der VDR weiterläuft? Weil ich hab bei mir heute, wie gesagt, festgestellt, dass der VDR zwar noch reagiert, aber die PVR keine Reaktion mehr liefert und eben mit der leidigen Meldung abwiegelt. Ich muss dann die PVR-Treiber neuladen (mittels restart, da ich noch keine Möglichkeit zum automatischen Treiber ent- und einladen habe)

soweit ich die Berichte verstanden habe, tritt bei 2 Leuten offenbar mit der rc1 das Problem auf, dass nach dem ersten Auftreten der Transfermode-Meldung gar kein PVR-Kanal mehr angewählt werden kann. Ansonsten läuft vdr weiter (auch DVB-Kanäle funktionieren). Jedoch laufen pvrinput-Kanäle erst wieder nach einem vdr-Neustart. Eiin Treiber-reload ist dafür nicht erforderlich.

Ob das Auftreten der Transfermode-Meldung in irgendeinem Zusammenhang mit dem Einfrieren steht, und wenn ja wie, ist noch unklar.

Mit der rc2 sollten keinerlei Transfermode-Fehlermeldungen mehr auftreten. Ein eventuelles Grundproblem (warum friert das Bild ein?) ist davon unbenommen.

Was mich wirklich wundert: Wieso ist das bisher weder bei mir noch bei den Betatestern (die teilweise schon seit Monaten eine nahezu unveränderte Version benutzen) aufgetreten? Ich konnte auch die Transfermode-Fehler nie provozieren, nichtmal ganz kurz.

ich halte das weder für sinnvoll noch umsetzbar.

Der Ablauf ist wie folgt:

vdr ruft die Funktion SetChannelDevice auf. Hier wird kein ioctl gesetzt, sondern die für den Kanalwechsel benötigten Daten werden nur Variablen zugewiesen. Jeder Aufruf weist die Variablen neu zu, egal wie schnell man zappt. Mit der rc2 kann hier keine Transfermode-Fehlermeldung mehr kommen.

Erst in OpenDvr -bevor Encoder und read thread wieder gestartet werden- werden die für den Kanal/Inputwechsel nötigen ioctls anhand der beim letzten SetChannelDevice-Aufruf gesetzten Variablen ausgeführt. (Die Gründe, warum dies nicht mehr in SetChannelDevice erfolgt, habe ich im 1. Beitrag erläutert.)
OpenDvr und CloseDvr sind so konstruiert, dass es zu keiner race condition kommen kann.

Mein Vorschlag ist, dass Ihr jetzt erstmal die rc2 ausprobiert. Im repository von gda+hotzenplotz5 ist es schon drin.

hattest Du diese freezes denn vorher mit pvrinput-2008-10-04 nicht? wär toll, wenn Du das mal gegenchecken könntest.

Du kannst auch mit Hilfe von ivtv-ctl die Karten einzeln tunen und dann mit cat streamen. Beispiel:
cat /dev/video0 > /video0/testvideo.mpg

Quoted

Original von methodus
Zu deinem Vorschlag mit dem Streamen: soll ich damit testen, ob die Karte selbst einfriert oder dein Plugin? Ich steh dann nämlich vor dem Problem, wohin mit den Daten... das Einfrieren tritt ja nur sproradisch auf. Manchmal nach 10 Minuten, teilweise auch erst nach 10 Stunden!

puh, für 10 Stunden bräuchtest Du eine große Platte. Wenn das ganze System einfriert, merkst Du das aber ja auch, wenn Du nach /dev/null streamst.

Quoted

Die Karte ist inaktiv, wenn sie nicht genutzt wird, richtig?

korrekt. Das device ist geöffnet, aber es gibt keinen Lesezugriff. Der Encoder läuft somit nicht.

Quoted

Ich könnte nur noch probieren, ob die Freezes auftreten, wenn ich mal nen Tag lang nur die digitale Karte verwende.

sehr unwahrscheinlich. Wenn, dann würde es ohne PVR150 vermutlich auch einfrieren.

das pvrusb2-Plugin ist Geschichte. pvrinput unterstützt vollständig die PVRUSB2, und zwar mit der gleichen Kanalsyntax wie für ivtv/cx18-Karten.