Zwei VDR-Instanzen parallel betreiben

Hallo allerseits,

da ich einigen Problemen (siehe meine letzten Postings) nicht so ganz Herr werde (insbesondere seltsames Umschalten bei parallelen Aufnahmen und seltene Abstuerze auf bestimmten Kanaelen im Transfermode), eine Idee, zu der ich gerne Meinungen haette:

Kann man auf einer Maschine 2 VDR-Instanzen parallel laufen lassen? Beide bekommen jeweils ein eigenes Konfigverzeichnis, eigene Logs, alles eigen - nur das Video-Verzeichnis wird geteilt. Per Startoption laesst sich einschraenken, welche DVB-Geraete sie jeweils bekommen.

In meinem Fall (DVB 0: DVB-C ohne Signal, FF zur Wiedergabe, DVB 1 und 2 DVB-T) kann das dann so aussehen:

Instanz 1: Karten 1 und 2, Dummy-Device als Ausgabe, keine FB, vdradmin - nur zum Aufnehmen

Instanz 2: Karte 0, keine weitere Signalquelle, FB und proclcd als Plugin.- nur zum Anschauen von Aufnahmen

Damit verliert man Live-TV und man verliert die Moeglichkeit, Aufnahmen direkt am VDR zu programmieren - beides habe ich in nunmehr ueber 3 Jahren VDR genau einmal getan. Quasi-Live-TV geht nach wie vor... man schaltet Instanz 1 einfach per vdradmin auf Aufnahme und guckt die dann leicht versetzt mit Instanz 2 - also gewissermassen Timeshift etwas anders.

Vorteil ist, dass es nie wieder Transfermode gibt (den brauche ich normal auch nicht, nur fuehren erwaehnte Bugs dazu, dass die Ausgabe manchmal auf Live-TV schaltet, wenn eine zweite Aufnahme startet) und die beiden Instanzen unabhaengig sind - ein Absturz der Anguck-Instanz also keine Aufnahmen gefaehrdet.

Hat jemand sowas schonmal getan? Klappt das, wenn beide das gleiche Video-Verzeichnis haben?

Viele Gruesse,

Jan

Hi,

Zitat

Prinzipiell sollte dein Vorhaben gehen.

Mir ist gestern abend noch ein weiteres Problem eingefallen, dessen Loesung wohl extensive Scripts erfordern wuerde: Das Herunterfahren. An der Stelle muss man ja alle moeglichen Faelle beruecksichtigen, was ja durchaus einige sind. Vermutlich ist das sogar das staerkste Gegenargument.

Zitat

Ich bezweifele aber, dass es das Problem mit den Abstürzen lösen wird.

Warum?

Es gibt genau zwei Probleme:

1. Auf manchen Sendern stuerzt der Laden ab, allerdings nur im Live-TV, nicht bei einer Aufnahme und auch nicht beim Anschauen derselben. Stoert mich nicht so arg, weil wir ja kein Live-TV schauen und das nur zuschlaegt, wenn mein EPG-Scan-Script die Sender durchschaltet (es sei denn, es kommt mit Problem 2 zusammen).

2. Angesichts der 3 Tuner kommt die Aufnahmesteuerung dahingehend durcheinander, dass sie die Ausgabe auf einen der TV-Kanaele schaltet, wenn eine zweite Aufnahme startet. Noetig ist das keineswegs, weil der aktuelle Kanal ja vom signallosen Kabeltuner kommt (das klappt auch... schwarzes Bild und ab und an halt "frontend 0 timed out while tuning to channel 51") und darueber hinaus zwei Tuner vorhanden sind. Das ist aber momentan nur ein Schoenheitsfehler, der dazu fuehrt, dass Transfermode vorliegt, obwohl es nicht sein muss. Ich hab nur Angst, dass das in einem Fall passiert, wo der erste Fehler zuschlaegt - das wuerde dann eine Aufnahme versauen. Ist in den 6 Monaten, die das schon ist, aber noch nie passiert.

Diese Situationen wuerden in einer Doppel-VDR-Config nicht mehr vorliegen, weil die Instanz 1 dann ganz sauber zwei T-Tuner und ein Dummydevice haette und es somit kein Live-TV mehr gibt, das woanders als im Nirvana landet.

Zitat

Ich kenn' die Vorgeschichte zwar nicht genau, aber währe es denn nicht einfacher auf Softdevice oder Xine umzusteigen? Die CPU müsste das ja locker packen.

Naja... das macht es aber nicht wirklich besser. Dann haette der VDR nur noch die beiden T-Karten, so dass das Softdevice STAENDIG beim Aufnehmen mitlaufen wuerde, ohne dass es irgendjemand braucht. Erhoeht den Stromverbrauch und sicher auch das Absturzrisiko bei unsauberem Empfang.

Zitat

Es gibt auch einen Patch der den Tuner der FF stilllegt, der könnte auch was bringen.

Vermutlich wuerde es das zweite Problem loesen, weil er dann nicht mehr mit den Sendern durcheinanderkommen wuerde. Das wuerde ich aber auch erreichen, indem ich den Kabel-Kanal aus der channels.conf rausnehmen wuerde. Riesiger Nachteil der Loesung waere aber wieder, dass die Kiste dann staendig im Live-TV laeuft, wenn aufgenommen wird (also insbesondere im Transfermode) und dann Problem 1 nach wie vor zuschlagen kann.

Was vermutlich wirklich helfen wuerde, waere sozusagen das Gegenstueck zum Dummydevice - also eine Software-Dummy-Karte, die nichts weiter als ein Standbild produziert und der ganz normal ein Kanal zugeordnet ist. Dann koennte man den VDR auf diesem Kanal parken und vermutlich wuerde es auch Fehler 2 nicht mehr geben, der IMO daher ruehrt, dass die Kabelkarte eben keinen Lock bekommt und somit bei der Kartenverteilung irgendwann nicht mehr beachtet wird. Ein wirklich gelocktes Dummy-Eingabe-Device sollte da besser sein. Nur: ich habe sowas nicht wirklich gefunden und als beste Loesung bislang den Tuner der FF auf einem nichtexistenten Kanal gestellt, was zumindest fast immer (wenn hoechstens eine Aufnahme laeuft) den gewuenschten Effekt hat.

Ebenso wirksam waere ein Plugin/Patch, der statt Live-TV einfach irgendwas anderes zeigen wuerde... ich hab schonmal ueberlegt, ob ich aus dem Image-Plugin da was basteln kann. Starten ginge ja per SVDRP, nur wuerde das nicht nach dem Angucken von Aufnahmen oder so helfen... Oder man nimmt das Analogplugin, zerlegt es so, dass alles, was auf die (nicht vorhandene) Analogkarte zugreift, wegfaellt und es nur noch im Endlosbetrieb ein MPEG ausgibt...

Viele Gruesse,

Jan

Hi,

Zitat

Lässt sich der Absturz mit zwei laufenden Aufnahmen (eine je Karte) und der gleichzeitigen Wiedergabe einer anderen Aufnahme auch provozieren?

Nein. Das laeuft bombenstabil. Er stuerzt selten auf ZDF oder 3Sat (IMO auch mal im ARD-Bouquet, bislang aber noch nie bei den privaten) ab, wenn er im Live-Modus laeuft. Das scheint dabei mit dem Inhalt zusammenzuhaengen. Frueher glaubte ich, dass es am Dolby liegt, aber das haben sie ja senderseitig bei DVB-T abgeschaltet. Irgendwas im Stream dieser Sender stoert den Transfermode.

Wenn ich exakt das gleiche im Timeshift gucke (wobei man wegen Absturz beim auf den Channel schalten Timeshift manuell per Aufnahme und sofortigem Start der Wiedergabe erreichen muss) laeuft das auch bombenstabil. Direktes Schalten auf den Kanal laesst den VDR hingegen abgammeln.

Oft kommt es nicht vor: Ich lasse etwa alle drei Tage mein EPG-Scan-Script laufen, das 30 Sekunden auf jedem Sender verharrt und alle durchlaeuft. Im Schnitt passiert das dann etwa einmal pro Woche. Problem dabei ist, dass er beim Start per Gentoo-vdrwatchdog den gleichen Zustand der Empfangskarte vorfindet und darum wieder abstuerzt, ehe der initial Channel greift. Dieses Problem habe ich aber dadurch geloest, dass ich im watchdog-Script einfach die Karten per dvbtune so verstimme, dass er beim Start nichts sinnvolles mehr empfaengt und der VDR erstmal wieder tunen muss.

Damit gibt es beim Scannen dann nur noch einen Absturz, was im Grund egal ist, weil da parallel keine Aufnahme laeuft. Selbst Live-TV ist mir egal... wie gesagt - stoeren tut nur die Moeglichkeit, dass er infolge des anderen Fehlers beim Aufnehmen zufaellig in so einen Kanal im Transfermode schaltet.

Zitat

Ich würde bei den Problemen zu erst mal auf eine ungünstige IRQ Verteilung tippen. Muss sich die FF die Int-Leitung mit einem anderen Device teilen?

Nein, tut sie nicht. Ich hab beim Aufbau extra darauf geachtet und solange Karten umgesteckt, bis beide PCI-Karten und das USB ehci (die zweite Empfangskarte ist ja USB) eigene Interrupts haben, die sie mit nichts teilen, auch mit dem Netz nicht (die Kiste ist diskless).

Die Interruptlast muss beim Fall "2 Aufnahmen + Wiedergabe" also VIEL hoeher sein als beim Live-TV, da hier ja noch parallel 3 NFS-Stroeme laufen. Auch Live-TV auf z.B. den privaten ist beliebig lange stabil und die Datenraten bei ZDF sind soviel hoeher auch nicht mehr (zumal das bei DVB-T ja ohnehin kein wirkliches Thema ist).

Der Absturz selbst spricht auch eher gegen IRQ-Probleme... der VDR verabschiedet sich mit:

Jan  3 21:05:39 sempria vdr[3840] general protection rip:2b017d323e43 rsp:7fff2e5d4760 error:0

Mehr gibts da nicht... davor normale Ausgaben, danach der Neustart. Also einfach nur ein protection fault.

Ich glaube, dass das Problem irgendwo da zu suchen ist, dass der VDR fuer 64 Bit kompiliert ist - beweisen kann ich das aber nicht. Allerdings will ich das nur hoechst ungern aendern und einfach zur Verifikation ist das entschieden zu aufwendig.

Zitat

Ich weiss nicht, mit so Kanälen in der channels.conf hatte ich schon öfters Ärger.

Unter 2.6.17, VDR 1.4.0 und 32-Bit-Linux lief es auf dem vorherigen Epia-Board zumindest in diese HInsicht stabil. Das trat erstmals bei Linux 2.6.20, VDR 1.4.6 und 64 Bit auf.

Zitat

Wenn ich mich noch recht erinneren wird beim Xine-Plugin nur dekodiert, wenn der Player geöffnet wird (ist aber schon ein bischen her, dass ich damit rumgespielt habe).

Ja, ist so. Ich hatte das am Beginn meiner VDR-Zeit mal zu laufen auf dem Epia und hatte es als recht schrecklich hinsichtlich der Stabilitaet in Erinnerung. Die FF war zumindest fuer mich dann eine Offenbarung. Kann natuerlich auch am Epia gelegen haben - das Sempron-Board zusammen mit der nVidia-Karte hat natuerlich viel mehr Power. Fakt ist aber, dass Xine gerne abstuerzt, wenn leichte Empfangsfehler vorliegen, auch bei der Wiedergabe von Aufnahmen. Da ist IMO die FF toleranter.

Und: Angucken von Aufnahmen ist der primaere Zweck dieses VDR. Das erzwungene Live-TV in manchen Situationen ist nur ein unerwuenschtes Uebel - darum wuerde ich lieber dieses vermeiden wollen.

Viele Gruesse,

Jan