VDR hat mich im Stich gelassen - keine Ahnung warum

Zitat von geronimo

Hi,

ich hatte mich schon auf den Krimi von gestern gefreut, aber dann musste ich feststellen, dass nur 56Mb in 50 Dateien geschrieben wurden.
Nee - mein Limit ist nicht 1Mb, sondern 200 ...

irgendwie scheint eine Karte im falschen Modus gewesen zu sein.

Aufnehmen dürfen bei mir nur die Budget-Karten. Trotzdem gibt es jede Menge Fehler ala

Code

[8837] ERROR: TS packet not accepted in Transfer Mode

Alles anzeigen

Da hat wohl das Wiedergabe-Device ein Problem.

Zitat

Zum Zeitpunkt der Aufnahme lief noch eine andere Aufnahme - aber 2 Aufnahmen bei 2 Budgetkarten dürfte doch keine Probleme verursachen.
Benutzer waren zu dem Zeitpunkt keine mehr aktiv.

Wenn mich jemand erleuchten und mir erklären könnte, was da schief lief - würde ich mich sehr darüber freuen.
Ich hänge mal einen komprimierten Log an.
Ein Not-Reset wäre möglich gewesen, ist aber nicht versucht worden.

Alles anzeigen

Hast du auch das Log, das während der Aufnahme geschrieben wurde?

Klaus

Zitat von geronimo

Moin Klaus,

das ist der Log von der Aufnahme.

Ich dachte, es ging um den Film "Tanz_mit_einem_Mörder", und von dem fand ich keine Einträge die Aufnahme betreffend.

Zitat

Zeile 134ff ist die eine Aufnahme und ab Zeile 142 startet die Aufnahme um die es geht.

Ah, das muß ich wohl in deinem ersten Posting übersehen haben...

Zitat

Ab Zeile 10 läuft eine Wiedergabe von einer SD-Aufnahme über die FF-Karte. Nach der Wiedergabe habe ich den Schnitt angestoßen und die Original-Aufnahme gelöscht.
Die Wiedergabe und der Schnitt erfolgten jeweils am VDR direkt, d.h. der Desktop-Rechner lief nicht mehr.
Wenn device 1 noch einen Wiedergabe-Lock hatte, dann hat xineliboutput den nicht freigegeben. Zu der fraglichen Zeit konnte es keine Verbindung mehr zum Desktop gegeben haben.

Die Fehlermeldungen vom Ende der Logdatei gehen weiter bis zum nächsten Morgen, d.h. es war noch eine andere Aufnahme von dem Fehler betroffen und ergab eine Aufnahme mit Länge 3 Sekunden. Klar habe ich noch den ganzen Log, ich dachte nur, dass vielleicht die wichtige Information am Anfang kommt, wo der Fehler anfängt.

Schon OK, ich war irgendwie neben der Spur

Nach Beendigung der Wiedergabe wird auf Kanal 14 (arte) geschaltet...

Oct 15 20:34:40 vdr vdr: [2926] switching to channel 14
Oct 15 20:34:40 vdr vdr: [8806] receiver on device 1 thread started (pid=2926, tid=8806)
Oct 15 20:34:40 vdr vdr: [8807] TS buffer on device 1 thread started (pid=2926, tid=8807)

...und zwar im Transfer Mode von Device 1. Die Wiedergabe erfolgt, vermute ich mal, über die FF-Karte ("vermute" deswegen, weil ja auch noch "xineliboutput" im Spiel ist, dessen Rolle mir hier nicht ganz klar ist).
Dann startet die Aufnahme auf Device 1...

Oct 15 22:10:00 vdr vdr: [2926] switching device 1 to channel 5
Oct 15 22:10:00 vdr vdr: [2926] timer 27 (5 2210-0020 'krimi~Varg Veum - Geschäft mit dem Tod~Thriller Norwegen/2011') start

...von Kanal 5 (ZDF HD) und unterbricht damit den Live-Empfang von arte, woraufhin auf den Kanal der zuletzt gestarteten Aufnahme geschaltet wird, also ZDF HD:

Oct 15 22:10:02 vdr vdr: [2926] switching to channel 5
Oct 15 22:10:02 vdr vdr: [2933] channel 5 (ZDF HD) event Mon 15.10.2012 21:45-22:12 (VPS: 15.10. 21:45) 'heute-journal' status 4
Oct 15 22:10:04 vdr vdr: [8839] buffer usage: 70% (tid=8837)
Oct 15 22:10:04 vdr vdr: [8839] buffer usage: 80% (tid=8837)
Oct 15 22:10:05 vdr vdr: [8837] ERROR: TS packet not accepted in Transfer Mode

Das verkraftet die SD-FF-Karte aber nicht, der Receiver-Thread auf Device 1 wird die Daten für die FF-Karte nicht mehr los, und das behindert wohl auch die Aufnahme.

Soweit mal ein erster Erklärungsversuch.

Klaus

Moin!

Zitat von geronimo

Kann man dem VDR irgendwie mitteilen, dass keine Wiedergabe mehr gewünscht ist?

suspendoutput-Plugin oder zusätzlich das dummydevice laden und das PrimaryDevice umschalten.

Lars.

Moin!

Du brauchst ja kein neues Plugin schnitzen, es reicht ja, xineliboutput zu erweitern, dass es bei Verbindungsende das PrimaryDevice zurücksetzt auf einen bestimmten Wert.

Lars.

Deine Budget Karten können mehr als Deine FF. Wenn zwei Aufnahmen starten, die auch mit der FF möglich sind, wird eine Budget Karte für eine mögliche dritte Aufnahme freigehalten. Die FF wechselt dann für das Live-Bild vom Direkt- in den Transfer-Mode. Die FF kann damit überfordert sein. Du kannst das verhindern, indem Du den Budget Karten die QPSK-Fähigkeit im Treiber wegpatchst. Eigentlich sollte der VDR so schlau sein und über die channels.conf erkennen, daß es keinen QPSK Sender bzw. Transponder gibt.

Gruß
e9hack

Zitat von geronimo

Das wäre der Traum schlechthin

... wenn der VDR die Devices nach den Erfordernissen der Sender belegen würde - träum

Auf dem Weg dahin würde es mir schon reichen, wenn man pro Kanal festlegen könnte, welche Karte er nicht nehmen darf. Schließlich sind 3sat und arte auch "nur" SD-Sender, deren Bandbreite ist aber so groß, dass die FF schon im Grenzbereich agiert.
Wenn man also ein Device für manche Sender sperren könnte, dann könnten Timer mit Minimalanforderungen (z.B. RTL, Sat1 etc.) sogar mit der FF befriedigt werden.
Meine derzeitige Konfiguration ist auch nur eine Holzhammer-Methode und ja, manchmal nervt es schon, dass ich einen ganzen Empfänger still legen muss...

Alles anzeigen

Das könnte ein Plugin über cDeviceHook::DeviceProvidesTransponder() machen.

Zitat

... aber vielleicht werden solche Themen ja nach 2.0 neu gestrickt? - man soll ja die Hoffnung nicht aufgeben

Die alten FF-Karten sind aber auch schon ziemlich "antik" und wurden ja schon allenthalben totgesagt

Klaus

Moin!

Gab's da nicht irgendwas mit einer CA-ID von 1?

Lars.

Zitat von geronimo

Meinst Du nicht auch, dass die Geschichte sich auch bei den neuen FF's wiederholen könnte?

Da du selber eine SD-FF-Karte verwendest gehe ich mal davon aus, daß das nicht das übliche "FF-Bashing" sein soll

Die SD-FF-Karten haben jahrelang gute Dienste geleistet, und die HD-Karten werden das sicher auch tun.
Ich werde sie zumindest so lange einsetzen, wie es technisch möglich und sinnvoll ist.

Klaus

Moin!

Zitat von geronimo

So ganz pragmatisch ...

Plugin bauen, cDeviceHook:: DeviceProvidesTransponder() benutzen und abhängig von der Geräte-ID (wo auch immer du die her nimmst, z.B. udev o.ä.) dann entweder true oder false zurückgeben...

(BTW: wie bekommt man es hin, dass Doppelpunkt-D kein Smiley wird?)

Lars.

Zitat von geronimo

Ich denke nur, die Technik wird sich weiter entwickeln und irgendwann steht die HD-FF an dem Platz, an dem die SD-FF heute steht.

Ja, und?
Irgendwann trifft das jedes technische Gerät.
Aber so lange es funktioniert kann man es doch mit Freude benutzen. Wenn du bei allem so denkst, dann dürftest du dir nie etwas kaufen, denn es könnte ja schon bald veraltet sein...

Zitat

Nicht weniger schlecht, aber trotzdem von vielen schon für tot erklärt.

Wahrscheinlich hauptsächlich von denjenigen, die nie eine hatten, und immer lästerten, daß sie ihnen viel zu teuer ist
Jedem das Seine...

Zitat

Gibt's da nicht schon einen Fred, der die aktuelle HD-FF für tot erklärt?

Also die real existierenden und in Benutzung befindlichen HD-FF-Karten sind beileibe nicht "tot".
Daß es wohl keine Neuauflage geben wird finde ich sehr schade, aber so ist es halt nunmal.

Zitat

Ich bin kein harter Mensch - mich interessieren eher die Weichteile
... und daher denke ich auch eher darüber nach, wie man Probleme entschärfen könnte. So ganz pragmatisch ...

Na also, dann bau dir ein auf deine ganz speziellen Bedürfnisse zugeschnittenes Plugin, das über cDeviceHook:: DeviceProvidesTransponder() die Steuerung übernimmt, und alles wird gut.

Klaus

Zitat von geronimo

Hm, könnte es sein, dass Du an der Ecke etwas dünnhäutig bist?

Das kann durchaus sein. Ich bin einfach diesen "Beißreflex" leid, den so manche hier haben, sobald das Thema FF-Karte zur Sprache kommt.

Zitat

Du hast mich jetzt 2 mal mistverstanden. Vielleicht willst Du mich ja auch garnicht verstehen?

Vielleicht liegt es einfach daran, daß du dich nicht klar genug ausgedrückt hast?

Zitat

Mein Denkanstoß sollte eher in die Richtung gehen: warum nicht gleich von Anfang an davon ausgehen, dass devices unterschiedlich sind und unterschiedliche Fähigkeiten haben? Wenn man es als "normal" ansieht, dass devices unterschiedlich sind, kommt der näxte Schritt von ganz alleine: nämlich dass Anwender die Unterschiede ausnützen wollen.

Das tut VDR doch bereits - soweit das halt möglich ist.
Aber woher soll er wissen, daß ein bestimmtes Device einen bestimmten Sender nicht "verkraftet", wenn er dafür keine Parameter hat?

Zitat

Da müssten wir erstmal Begrifflichkeiten klären, da ich von der Ecke absolut keine Ahnung habe.
Was ist jetzt ein Transponder?
Entspricht das dem Bouquet, oder eher der Ebene DVB-C / DVB-S?

Der Transponder ist die Frequenz, auf der ein (oder mehrere) Kanäle übertragen werden.

Zitat

Ich sehe (noch) nicht, dass ich mit dem API-call weiter komme.
Mein Ansinnen ist doch, einen einzelnen Sender zu sperren, bzw. zu erlauben.
So aus dem Bauch heraus ist mir Transponder zu grob - oder irre ich mir da?

Die Funktion DeviceProvidesTransponder() bekommt den kompletten Kanal (cChannel) und kann sich so alle seine Parameter anschauen um zu beurteilen, ob das jeweilige Device diesen Kanal empfangen kann. Wenn du also eine Liste der Kanäle hast, die z.B. Device 1 nicht empfangen kann, dann kannst du diese innerhalb deiner Implementierung benutzen, um zu verhindern, daß Device 1 auf einen dieser Kanäle schaltet. Dabei kannst du auch innerhalb des selben Transponders den einen Kanal zulassen und den anderen sperren.

Zitat

Also in meinem konkreten Fall müsste ich abfragen können, welche Bandbreite ein Sender benötigt und bei welcher Bandbreite die Karte anfängt rumzuzicken.

Und genau da wird's schwierig, weil eben diese Parameter nicht vorhanden sind (zumindest wüsste ich nicht, wo die in den SI-Daten versteckt wären). Du müsstest das also wohl eher empirisch ermitteln.

Zitat

Dann könnte bei einem Timer entschieden werden, welche Karte verwendet werden kann und darf.
Wie kann mir bei der Fragestellung die empfohlene API weiterhelfen?
Wenn ich es richtig sehe, wird der HW-Dekoder ja erst bei der Anzeige verwendet, nicht aber bei der Aufnahme?
Sonst müsste ich die Fähigkeit auch noch abprüfen.

Das cDeviceHook:: DeviceProvidesTransponder() API greift nur für den reinen Empfang. Ob ein Ausgabe-Device einen bestimmten Kanal "verkraftet", dafür gibt es bisher noch kein API. Aber natürlich könnte man sowas auch einführen. Vielleicht über eine Erweiterung der Funktion cDevice::HasDecoder(), in der Form

bool cDevice::HasDecoder(int Vtype = 0);

Damit könnte dann vor dem Umschalten auf einen bestimmten Kanal (oder vor der Wiedergabe einer Aufnahme) abgefragt werden, ob das Ausgabedevice überhaupt in der Lage ist, das material Wiederzugeben.
Aber auch damit dürfte es wohl schwer werden, alle Probleme zu erledigen, die sich aus Bandbreitenproblemen ergeben...

Klaus

Moin!

Zitat von kls

Vielleicht über eine Erweiterung der Funktion cDevice::HasDecoder()

Ich denke, das sollte das Ausgabedevice selbst regeln können. Wenn es die Daten nicht verarbeiten kann, kann es eine entsprechende Meldung ins syslog und vielleicht sogar auf's OSD schicken und die Video-/Audiodaten einfach unter den Tisch fallen lassen, sprich, den Ringbuffer leeren, damit der nicht überläuft. Wie reagiert der vdr eigentlich, wenn das Ausgabedevice nicht schnell genug die Daten verarbeitet? Kommt da nur ein "buffer overrun"?
Es muss ja nicht nur vom Vtype abhängig sein, die PVR350 z.B. verträgt keinen AC3-Ton (mittlerweile dekodiert das Plugin den Ton und gibt ihn als mp2 aus).

Gero: Ich weiß noch nicht genau, wie mein Wochenende aussieht, aber vielleicht schaffe ich es, dir ein Grundgerüst für so ein Plugin vorzugeben, damit du eine Vorstellung davon bekommst.

Lars.