Posts by Fourty2

    Hallo kfb77,


    habe da eben zufällig noch einen Lock-Fehler im Log gefunden, den es mehrfach in der Vergangenheit (immer dieselbe Stelle gibt):



    Version ist noch 3.0.12.


    Grüße,

    Stefan

    Das kenne ich doch irgendwoher...

    Habe den VDSB Neustart deaktiviert und den Watchdog auf 300s gesetzt. Das reicht in der Regel, bis epgsearch, epg2vdr, scraper2vdr und der vdr mit dem Streit um das Aufnahmen-Lock durch sind.


    Alternativ Aufnamestart bei manuell erzeugten Timer auf +/- 1 Min legen.


    Stefan

    Da ist noch ein kleiner Bug in der Timerverwaltung:

    Code
    1. Thu Jul 1 18:25:03 [3084] INFO: starting markad v3.0.5 (5e56e72) (64bit)
    2. Thu Jul 1 18:25:03 [3084] INFO: using libavcodec.so.58.91.100 with -1 threads
    3. Thu Jul 1 18:25:03 [3084] INFO: on /srv/vdr/video/local/####/2021-07-01.18.25.107-0.rec
    4. Thu Jul 1 18:25:04 [3084] INFO: paused by signal


    Alle Aufnahmen danach wurden bereits markiert. Was war hier anders?

    Habe, nachdem die Credits durch waren, den Timer gelöscht, damit die Karte frei wurde, also den Nachlauf abgebrochen. Die Aufnahme wird dann nicht mehr bearbeitet (aber vermutlich auch nicht beachtet)


    Stefan

    kfb77

    Balken kommen vom Himmel, wie es halt gerade paßt:


    Dezent.


    So lala:


    HD in 4:3 (Zack Synders Justice League) oder, Moment ... "Lucy in the Sky"


    mal breit:


    mal links und rechts:


    obwohl, vorher war besser:

    nee, gucken wir nochmal ...


    Wenn Du Anschauungsmaterial brauchst, melde dich.


    Stefan

    Hab die Aufnahme mal als tar.gz auf den Webserver gelegt. Keine Ahnung, ob der mit 5 GB am Stück klar kommt. :-)


    System ist Debian GNU/Linux 10 (buster) 5.10.43-cherrytrail

    Der Kernel hat einen march=native patch mit O2 Optimierung...


    FFMPEG:

    ffmpeg version 4.3.1-1~hit1u0 Copyright (c) 2000-2020 the FFmpeg developers

    built with gcc 8 (Debian 8.3.0-6)

    configuration: --prefix=/usr --extra-version='1~hit1u0' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared

    libavutil 56. 51.100 / 56. 51.100

    libavcodec 58. 91.100 / 58. 91.100

    libavformat 58. 45.100 / 58. 45.100

    libavdevice 58. 10.100 / 58. 10.100

    libavfilter 7. 85.100 / 7. 85.100

    libavresample 4. 0. 0 / 4. 0. 0

    libswscale 5. 7.100 / 5. 7.100

    libswresample 3. 7.100 / 3. 7.100

    libpostproc 55. 7.100 / 55. 7.100

    Hyper fast Audio and Video encoder

    Habe gerade mal wieder einen MarkAd Segfault. Passiert selten, meist gibt es dann keine Endmarken.

    Ideen? Aufnahme war nach vdr-2.5.x Routinen, vdr-checkts und ffmpeg i.O.


    Wunderbar!


    Funktioniert hier auch:


    Danke,

    Stefan

    So manuell beendet, Film durch:


    Vielleicht besser den hier?

    Jun 27 20:09:21 roadrunner vdr: [22467] markad debug: cRecordControl::Stop called

    Jun 27 20:09:21 roadrunner vdr: [22467] markad debug: cRecorder destructor called

    Och, ich hätte auch einen Patch für einen gut gepflegten Kodi Bug ... :-)


    Aber die gesuchte Funktion müßte im VDR bereits vorhanden sein:


    Denn der VDR sucht gerade ein freies Device für die dritte Aufnahme (Pro7), das sollte gegen 20:13 frei werden.

    Von "Live" 3sat HD auf die andere Aufnahme geschaltet:

    und wieder zurück


    Das ist einmal osdteletext, soweit, wie auf 3sat Videotext gesendet wird:

    Code
    1. Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 0
    2. Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 0
    3. Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 0
    4. Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1
    5. Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1
    6. Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1
    7. Jun 27 17:51:21 roadrunner vdr: [22511] device 1 receiver thread started (pid=22467, tid=22511, prio=high)
    8. Jun 27 17:51:21 roadrunner vdr: [22467] creating directory /var/cache/vdr/vtx/S19.2E-1-1010-11150
    9. Jun 27 17:51:21 roadrunner vdr: [22512] device 1 TS buffer thread started (pid=22467, tid=22512, prio=high)
    10. Jun 27 17:51:21 roadrunner vdr: [22513] osdteletext-receiver thread started (pid=22467, tid=22513, prio=high)


    und vermutlich die Live-Ausgabe per vaapidevice:


    Es läuft ein streamdev-server, aber der belegt erst, wenn in Betrieb.


    Plugins:

    Ohne Aufnahmen kommt:

    roadrunner vdr: [22467] markad debug: 2 receiver(s) runnning on device 0 vielfach

    roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1 einfach

    Pause - Repeat.


    Mit 1x Aufnahme(n) ist größtenteils, mit Aufnahmen auf beiden Karten völlige Ruhe.


    Device 0 = DVB-S (Eingang 1 einer Karte)

    Device 1 = DVB-S (Eingang 2 einer Karte)

    Device 2 = vaapidevice (Ausgabe, primär)


    Aufnahmeprogramm:


    Log dann anschließend.

    So... läuft:

    Und die Gewitter sind auch pünktlich eingetroffen. Grrr... :-/


    Edit: Zum Aufnahmestart (FTA 3sat) hat es noch gereicht, das Wetter.

    Lief ja auch seit ziemlich exakt 5 Minuten ... :-)


    Na gut, nochmal...


    Edit:

    Hunk failed...


    sieht bei mir jetzt so aus - hoffe äquivalent:


    Stefan

    Jetzt wissen wir wenigstens, dass der Patch von HelmutB nicht die Ursache ist.

    Die einzige Unterbrechung ist ja gleich nach dem Restart wegen dem epg2vdr Crash (da solltest du auch mal nach der Ursache suchen, normal ist das nicht, ich nutze das Plugin auch und habe nie einen Crash).

    Das epg2vdr läuft hier mit der MariaDB-Nonblocking-API. Die Probleme kamen mit dem vorletzten MairaDB Update vor ein paar Tagen, gestern gab es noch ein Update, vielleicht ein externes Problem. Wird sich dann zeigen, beim Recompile.

    Verdacht: Aufnahme auf Device 0 bricht ab, wird auf dem gleichen Device wieder gestartet (macht ja auch Sinn, weil das Device schon auf den Channel getuned ist). Die abgebrochene Aufnahme wird aber nie aufgeräumt und somit bleibt immer eine laufende Aufnahme auf dem Device. Solange die erste Aufnahme (oder jede andere Aufnahme auf dem gleichen Transponder) noch läuft, sieht alles gut aus, ist es aber nicht. Das Problem wird erst sichtbar, wenn die letzte Aufnahme zu Ende ist. Reine Theorie ...

    Sieht mir - derzeit - eher so aus, als wenn beim PID-Update, das jeweils den MarkAd-Prozess killed, was schief läuft. Nach Neustart (um 19:21) war noch alles exakt wie zuvor. Das ändert sich mit dem direkt anschließenden PID-Update.


    Poste mal bitte noch das vollständige Log ab Restart bis 19:23, vielleicht sieht man da was.

    Das Wesentliche anbei... (und noch ein weiteres PID-Update des Nachts am Ende einer Aufnahme)

    Neuer Versuch, der Ursache für den falschen Status vom VDR näher zu kommen:

    Dieser Branch für markad und zusätzlich der Patch in Anhang für den vdr.

    Damit müssten aus dem VDR folgende zusätzliche Debug Meldungen kommen (nicht verwirren lassen, sind vdr debug Meldungen, ich habe nur wegen dem einfacherem grep "markad debug" davor gestellt:

    Code
    1. Jun 27 10:57:16 VDR-2004-Dev vdr: [50862] markad debug: 2 receiver(s) runnning on device 0
    2. Jun 27 10:57:20 VDR-2004-Dev vdr: [50858] markad debug: 0 receiver(s) runnning on device 1

    Spannend ist dann der Zeitpunkt (bitte gleich vollständiges syslog), wo die Summe der laufenden Aufnahmen nicht mehr mit der Summe der Receiver von allen Devicen zusammen passt.

    Vorsicht: das schreibt intensiv ins syslog, den VDR Patch nach dem Test wieder entfernen.

    Mach ich, sobald möglich. Das Syslog ist egal, das läuft zunächst ins reichliche vorhandene RAM ...


    Stefan

    Leider gibt es das Problem noch. Es gab zwar einen epg2vdr gpf in der ersten von drei sich überschneidenden Aufnahmen, danach war die Zählung aber noch korrekt (meine ich).


    (#0) XX:XX --- / ---

    (#1) 18:05 Rec 1, Card A / --

    (#2) 20:00 Rec 1, Card A / Rec 2, Card B

    (#1) 20:30 --- / Rec 2, Card B

    (#2) 21:40 Rec 3, Card A / Rec 2, Card B

    (#1) 22:30 Rec 3, Card A / --- <--- Aufnahmezähler bleibt auf 2

    (#0) 00:05 --- / --- <--- Aufnahmezähler bleibt auf 1


    Log anbei.


    Stefan

    Korrekt. Zumindest, soweit es ein VDR im reinen Aufnahmebetrieb ist.


    Ansonsten stehen Aufnahmen mit dicken (Gewitter-) Wolken schonmal dem Wunsch entgegen, eine ältere Aufnahme abzuspielen. Und ja, die Technik bleibt hier an: die Lösung ist rot, vor dem Zähler angeklemmt und macht ein fröhliches, aber bestimmtes, Schlafende weckendes "Klong" im Falle des "Betriebs".


    Stefan

    Nicht wirklich. Der VDSB erwirkt den Neustart. Das habe ich bei mir aus (Setup -> Notaustieg -> nein), damit, falls das Modul keine Lust zur Zweitdekodierung hat, nicht gleich beide Aufnahmen toast sind.


    Stefan

    Eine einzelne Aufnahme ohne PID-Update bedingte Unterbrechung lief sauber durch:



    Stefan