Problem mit GRAB / vdradmin-Fernseher und Kernel 1.1.1

    Da die Frage immer wieder auftaucht:


    In der monetanen Treiberversion 1.1.1 führt ein GRAB bzw die Benutzung des vdradmin 1Hz-Fernsehers zu einem Absturz.


    Peter hat da aber einen kleinen Workaround rausgefunden, der im nächsten Treiberpaket sicher enthalten sein wird. Das ganze ist noch weitgehend ungetestet:


    Statt des video-buf modules des Kernels muss das entsprechende Modul des DVB-Treibers installiert werde.


    Dies erreicht ihr am einfachsten, indem ihr die Datei video-buf.o in /lib/modules/<mein-kernel>/kernel/drivers/media/video wegkopiert. (Bitte nicht ganz und gar löschen, wenns nicht klappt, müsst ihr die Datei wieder reinkopieren!)


    Wenn ihr dann "depmod" aufruft und keine Fehlermeldungen erscheinen, könnt ihr den Rechner neu starten und dann sollte es funktionieren.


    Tobias

    Hallo Tobi,


    hat geklappt bei mir. Schön, dass ich jetzt auch wieder Menübilder für die DVDs erzeugen kann. Herzlichen Dank an Peter und Dich!


    Viele Grüsse,
    Peter

    VDR2 (produktiv):
    HW: ASRock Q1900M, Celeron J1900 2GHz, 4GB RAM, WD20EFRX (2TB), TechnoTrend Premium S2-6400, Digital Devices Cine S2 V7A
    SW: VDR 2.2.0 auf Kernel 5.4.0 (Ubuntu 20.04.1)


    VDR1 (Reserve):

    HW: Dell XPS420, Core2 Quad 2,40GHz, 3GB RAM, WD15EVDS (1,5TB), TechnoTrend Premium S2-6400, TeVii S470 DVB-S2

    SW: VDR 1.7.18 auf Kernel 2.6.35 (Ubuntu 10.10)

    hallo,


    herzlichen dank an tobi und peter - hat auch bei mir soweit geklappt.
    folgendes ist mir jedoch aufgefallen unter der neuen konfiguration:


    wenn ich nun per fernseher im vdradmin befehle eingebe, hört der vdr nicht mehr auf zu grabben - bis zu einem neustart.


    auszug aus messages (nach aktivem einsatz des fernsehers im vdradmin):


    Apr 11 13:10:50 vdr vdr[15794]: timer 5 modified (active)
    Apr 11 13:10:50 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:13:27 vdr vdr[15794]: connect from 127.0.0.1, port 32803 - accepted
    Apr 11 13:13:28 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:13:59 vdr vdr[15794]: connect from 127.0.0.1, port 32804 - accepted
    Apr 11 13:13:59 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:13:59 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:00 vdr vdr[15794]: connect from 127.0.0.1, port 32805 - accepted
    Apr 11 13:14:01 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:01 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:05 vdr vdr[15794]: connect from 127.0.0.1, port 32806 - accepted
    Apr 11 13:14:05 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:05 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:07 vdr vdr[15794]: connect from 127.0.0.1, port 32807 - accepted
    Apr 11 13:14:07 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:07 vdr vdr[15794]: connect from 127.0.0.1, port 32808 - accepted
    Apr 11 13:14:07 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:07 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:11 vdr vdr[15794]: connect from 127.0.0.1, port 32809 - accepted
    Apr 11 13:14:11 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:11 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:15 vdr vdr[15794]: connect from 127.0.0.1, port 32810 - accepted
    Apr 11 13:14:15 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:15 vdr vdr[15794]: connect from 127.0.0.1, port 32811 - accepted
    Apr 11 13:14:15 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:15 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:15 vdr vdr[15794]: connect from 127.0.0.1, port 32813 - accepted
    Apr 11 13:14:15 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:15 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:18 vdr vdr[15794]: connect from 127.0.0.1, port 32814 - accepted
    Apr 11 13:14:19 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:19 vdr vdr[15794]: connect from 127.0.0.1, port 32815 - accepted
    Apr 11 13:14:19 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:19 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:20 vdr vdr[15794]: connect from 127.0.0.1, port 32816 - accepted
    Apr 11 13:14:20 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:20 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:25 vdr vdr[15794]: connect from 127.0.0.1, port 32817 - accepted
    Apr 11 13:14:25 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:25 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:26 vdr vdr[15794]: connect from 127.0.0.1, port 32818 - accepted
    Apr 11 13:14:27 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:28 vdr vdr[15794]: connect from 127.0.0.1, port 32819 - accepted
    Apr 11 13:14:28 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:28 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:30 vdr vdr[15794]: connect from 127.0.0.1, port 32820 - accepted
    Apr 11 13:14:30 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:30 vdr vdr[15794]: connect from 127.0.0.1, port 32821 - accepted
    Apr 11 13:14:30 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:30 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:30 vdr vdr[15794]: connect from 127.0.0.1, port 32823 - accepted
    Apr 11 13:14:30 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:30 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:14:35 vdr vdr[15794]: connect from 127.0.0.1, port 32824 - accepted
    Apr 11 13:14:35 vdr vdr[15794]: grabbing to /tmp/vdr.jpg (JPEG 70 384 288)
    Apr 11 13:14:35 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:22:00 vdr vdr[15794]: timer 4 (7 1200-1322 'Pocahontas 2 - Reise in eine neue Welt') stop
    Apr 11 13:22:00 vdr vdr[15794]: deleting timer 4
    Apr 11 13:22:00 vdr vdr[15794]: executing '/usr/bin/recordingaction after "/video/Pocahontas_2_-_Reise_in_eine_neue_Welt/2004-04-11.12.00.95.95.rec"'
    Apr 11 13:24:36 vdr vdr[15794]: connect from 127.0.0.1, port 32825 - accepted
    Apr 11 13:24:39 vdr vdr[15794]: timer 4 modified (active)
    Apr 11 13:24:40 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:30:41 vdr vdr[15800]: System Time = Sun Apr 11 13:30:41 2004 (1081683041)
    Apr 11 13:30:41 vdr vdr[15800]: Local Time = Sun Apr 11 13:30:38 2004 (1081683038)
    Apr 11 13:34:37 vdr vdr[15794]: connect from 127.0.0.1, port 32826 - accepted
    Apr 11 13:34:42 vdr vdr[15794]: timer 4 modified (active)
    Apr 11 13:34:42 vdr vdr[15794]: closing SVDRP connection
    Apr 11 13:36:28 vdr vdr[15794]: caught signal 15
    Apr 11 13:36:29 vdr vdr[15794]: saved setup to /etc/vdr/setup.conf
    Apr 11 13:36:30 vdr vdr[15794]: stopping plugin: femon
    Apr 11 13:36:30 vdr vdr[15794]: stopping plugin: streamdev-server
    Apr 11 13:36:30 vdr vdr[15802]: Streamdev: Server thread stopped
    Apr 11 13:36:30 vdr vdr[15794]: exiting
    ....


    erst nach einem -manuellen- neustart des vdr hört er auf zu grabben ...?
    habe keine ahnung, ob das so o.k ist - wollte dies halt mal als auffälligkeit mit der bitte um prüfung hier reinstellen. ;)


    schöne grüsse


    marpiet



    HDVDR: yavdr-0.6.0-stable: Intel G2120,Intel DH 77EB mit CIR, Co-Haus CIR, 64 GB SSD, 3 TB WD Red, Cine S2 V6.5 + Duoflex S2 an Centauri Multiswitch,
    Zotac Nvidia GT 630

    :prost2


    Einmal editiert, zuletzt von marpiet ()

    Hallo Tobi,
    jetzt funktioniert GRAB zwar wieder, aber mit einer ganz dummen Eigenschaft: es grabbt von der falschen FF-Karte.
    Hintergrund: ich habe zwei vdr-Instanzen laufen, eine mit einer Budget- und FF-Karte (diese soll auch grabben) und eine zweite mit nur einer FF-Karte. Das GRAB-Kommando kommt auch bei der richtigen vdr-Instanz an, als Bilder erhalte ich jedoch die Bildinhalte der FF-Karte der anderen Instanz. Wie kann denn das sein, dass vdr auf eine Karte zugreift, die ich ihm überhaupt nicht zugewiesen habe?
    Vielleicht hat das damit zu tun, dass die Treiber 1.1.1 die Karten in einer anderen Reihenfolge finden, als die 1.1.0 Treiber dies taten. Ich musste die D-Parameter nach dem Update auf 1.1.1. in meiner runvdr umsortieren.
    Gruss,
    Peter

    VDR2 (produktiv):
    HW: ASRock Q1900M, Celeron J1900 2GHz, 4GB RAM, WD20EFRX (2TB), TechnoTrend Premium S2-6400, Digital Devices Cine S2 V7A
    SW: VDR 2.2.0 auf Kernel 5.4.0 (Ubuntu 20.04.1)


    VDR1 (Reserve):

    HW: Dell XPS420, Core2 Quad 2,40GHz, 3GB RAM, WD15EVDS (1,5TB), TechnoTrend Premium S2-6400, TeVii S470 DVB-S2

    SW: VDR 1.7.18 auf Kernel 2.6.35 (Ubuntu 10.10)

    Hi


    ich habe das gleiche Prob. VDR stürzt sang und klanglos ab wenn man GRAB benutzt. Dummerweise habe ich keine video-buf.o im Verzeichnis kernel/drivers/media/video :( :(
    allerdings gibts sie in kernel/misc und kernel/v4l. Nehme ich sie dort heraus (umbenennen) dann funzt GRAB trotzdem nicht :(. Neustart und depmod habe ich gemacht.
    Irgendwelche Idee außer neue DVB Treiber? Nutze Suse 8.2


    Tobias

    :vdr1 VDR User #626:fans
    VDR II: YeongYang A106, Fusi D1522, Celeron 2GHz, Frontend per DVB-s FF, 2xDVB-c, ATRIC-IR, YaVDR 0.3a
    VDR III HDTV: Inter-Tech 2008V mit iMonLCD, Atric, ASRock Extreme3 770 AM3, AMD Sempron 140 1x 2.70GHz AM3, 1,5TB WD15EADS, 2TB WD20EARS, 2x4GB DDR3-1600, NVidia GT520 passiv, 3x DVB-c, YaVDR 0.5 @ Samsung PS-50B550

    Cool, das hat funktioniert.
    Was eine kleine Datei so alles anrichten kann...
    Ich hatte mich auf ein BIIIIG Problem eingestellt.


    Vielen Dank.


    Gruß Richie

    Yeong Yang Casper 106 - AMD Sempron 2200+ - 1xTT1.5 - 1xTTBudget - 1x WD 120 GB - 1x Samsung 160 GB - LG DVD+/-R/RAM - Lirc - blaues Grafik-LCD 128x64 - c't vdr 4.5++ (1.3.41 von tobi) - Kernel 2.6.12 - Multipatch

    Hallo!


    Weiß zufällig jemand wie das auf einem PPC-System funktioniert?
    Unter ..../kernel/drivers/media/video gibt es zwar ein video-buf.ko Modul, aber wenn ich das entferne startet nach einem Reboot der vdr nicht mehr.
    depmod gibt keine Fehlermeldung aus. Auf x86 gibt es wohl mehrere video-buf-Module, auf PPC (Macintosh) anscheinend nur eins.


    Ist das eigentlich ein Problem im DVB-Treiber oder im Videotreiber?
    Wenn ich den DVB aus dem CVS nehme, hat der auch noch das Problem?


    Für jede Hilfe dankbar,
    eweri

    vdr streamen auf MacOS X mit vlc und iTunes für Radiosendungen

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden