[solved/workaround] Problem VDRAdmin Fernseher und analoge TV-Karte (Ivtv)

    Hallo


    ich habe ein Problem mit dem VDRAdmin Fernseher.


    Ich haben einen VDR mit einer FF-DVB-C und einer analogen Haupauge PVR 150. Das funktioniert auch soweit.


    Normalerweise wir der Treiber (IVTV0.4) für die PVR150 zuerst geladen und anschließend der für die DVB-C-Karte. Das funktioniert auch so soweit. Allerding habe ich dann im Webfrontend des VDRAdmin kein Fensherbild unter Fernseher.


    Lade ich den Treiber für die DVB-C-Karte nun aber vor dem IVTV-Treiber der PVR150, dann funktioniert der Fernseher im VDR-Admin, allerding erhalte ich kein Bild mehr vom Tuner der DVB-C-Karte (der Ausgang der DVB-C funktionietr jedoch noch, analoge Programme gehen).


    Scheinbar ist im VDR-ADmin irgendwo auf /dev/video0 gelinkt, was bei mir aber leider im Normalfalle von der PVR150 (und nicht der DVB-C-Karte) belegt ist. Kann man das irgendwo umkonfigurieren. Dazu habe ich leider nichts gefungen


    Schönen Gruß
    Negge

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    Edited 2 times, last by Negge ().

    Quote

    Original von Negge
    Scheinbar ist im VDR-ADmin irgendwo auf /dev/video0 gelinkt, was bei mir aber leider im Normalfalle von der PVR150 (und nicht der DVB-C-Karte) belegt ist. Kann man das irgendwo umkonfigurieren. Dazu habe ich leider nichts gefungen


    Wirklich gute Frage - Habe das gleiche Problem! Kam bisher aber noch nicht dazu, mir darüber Gedanken zu machen...


    Gruß kleinklausi

    SW: Ubuntu 10.04; yaVDR Pakete
    HW: Asus P5N7A-VM; 2x DVB-C rev2.1; Silverstone LC16B-M; Panasonic PT AX200e

    Problem liegt eigentlich beim VDR.
    Vdradmin verwendet grab von vdr das normalerweise auf /dev/video0 ausgeführt wird.
    Das kann man in den sourcen von vdr ändern.


    Patch bzw genaue Stelle find ich jetzt leider nicht.

    Gibs da denn nicht nen "Update" damit man das einfach einstellen kann. Ich möchte ungern die Sourcen kompilieren. Oder nen Workarround?

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    So, habe jetzt einen Workaround.


    Wenn man das pvrinput-Plugin benutzt (und nicht das AnalogTV), dann darf das Video-Device für den PVR-input auch nach der DVB-Karte geladen werden. Daher habe ich in /etc/modules dvb-ttpci vor ivtv eingetragen. Jetzt werden die dvb-module zuerste geladen und auf /dev/video0 gesetzt. Dann geht auch der vdradmin-Fernseher.


    DIe PVR-Karte landet nun auf /dev/video1. Das PVR-Input-Plugin scheint sich darin nicht zu stören. Selbst die channels.conf musste nicht angepasst werden...

    Server: Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 1,9TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless
    Client: Hardware: Lenovo Q150 (nur Netzwerk, 1GB RAM, ohne DVB-Karte, Igor-USB-Empfänger) System: Ubuntu 18.4 / YaVDR ansible

    Quote

    Original von wilderigel
    Problem liegt eigentlich beim VDR.
    Vdradmin verwendet grab von vdr das normalerweise auf /dev/video0 ausgeführt wird.
    Das kann man in den sourcen von vdr ändern.


    Patch bzw genaue Stelle find ich jetzt leider nicht.


    Da ich das Problem auf meinem Zweit-VDR auch habe und die Ladereihenfolge sich Kernel 2.6.15-ct-1 und udev sei Dank nciht mehr ohne größeren Aufwand festlegen läßt, habe ich in den Sourcen mal etwas recherchiert. Die erste (FF) DVB-Karte wird im Konstruktor cDvbDevice::cDvbDevice(int n) gesucht, indem versucht wird, in einer Schleife in /proc/video/dev/video? (? == 0 .. 99) zu öffnen. Genau dieses Verzeichnis gibt's auf meinen 2.6.16er-Systemen aber nicht mehr. Nach erfolgloser Suche wird 0 angenommen. Abschließend wird nachgeschaut, ob das Device 'nen Decoder hat. Und da scheint wohl der Hund begraben zu liegen: Meine PVR350 hat einen, allerdings kann man darüber keine Bilder auslesen. Allerdings wird IVTV vor den DVB-Treibern geladen. /dev/video0 ist daher wohl die PVR350. Das muß wohl dazu führen, daß am Schluß die Karte ausgesondert wird und devVideoIndex auf -1 gesetzt wird. Ansonsten (ohne IVTV oder andere Treiber, die /dev/videox-Devices erzeugen) wird immer die erste FF-DVB-Karte zum Grabben verwendet.


    Ich habe das Problem brute force daddurch gelöst, daß ich in GrabImage() die Abfrage auf devVideoIndex auskommentiert habe und beim Zusammenbauen des Device-Pfades ein paar Zeilen später einfach mal statt devVideoIndex hart 'ne 1 (-> /dev/video1) reingeschrieben habe, den Zugriff also hart auf die zweite Karte einstelle.


    Und siehe da - der VDR grabt wieder!


    So wie ich die Sache sehe, liegt die Ursache der Probleme letztendlich darin, daß die Device-Numerierung von Ein- und Ausgabegeräten nicht aneinander gebunden ist, d. h. das Device zum Grabben ist das zweite, während ansonsten die übrigen erzeugten Devices auf der niedrigeren Nummer liegen können.


    Der VDR hat dann doch letztlich keine Chance, selbst festzustellen, wie die Zuordnung ist, oder? Und was ist, wenn man zwei FF-Karten im System hat und auf der zweiten ausgibt? Da erscheint ja auch das OSD, gegrabt wird aber weiterhin auf der ersten.


    Wäre es dann nicht sinnvoller, dem VDR einfach eine vom Ausgabe-Device unabhängige Einstellmöglichkeit für das Grabbing-Device zu geben?


    Oder liege ich mit meinen Gedankengängen irgendwie falsch?


    Viele Grüße,
    Torsten

    "The day Microsoft makes something that doesn't suck is probably
    the day they start making vacuum cleaners" - Ernst Jan Plugge
    __________________
    Torsten Lang

    Edited 3 times, last by torsten lang ().

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login