[markad] überarbeiteter Decoder

    Ja, passt. Mein VDR basiert auf yavdr und da kommt der Teil, den du nicht finden kannst, aus dem dynamite Patch. Sorry, daran habe ich nicht gedacht.

    So... läuft:

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


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

    Da sehe ich mal schon den ersten Unterschied zu mir, so oft kommt die Meldung bei mir nicht, nur so alle 2 Sekunden pro Device.

    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.

    Zitat von Fourty2

    Jun 27 17:54:51 roadrunner vdr: [22467] markad debug: 2 receiver(s) runnning on device 0

    Wo kommen denn die 2 Receiver von Device 0 her, bevor die erste Aufnahme startet ???

    Hast du streamdev-server oder vnsi Plugin drauf ? Zeige mal das Log vom Start, vielleicht sieht man, wer sie sich holt.


    Edit: Ich habe das bei mir nochmals überprüft, bei mir kommt auf allen Devices 0 Receiver ohne Aufnahme. Wir nähern uns dem Problem ...

    Einmal editiert, zuletzt von kfb77 ()

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

    Code
    Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 0
Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 0
Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 0
Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1
Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1
Jun 27 17:51:21 roadrunner vdr: [22467] markad debug: 0 receiver(s) runnning on device 1
Jun 27 17:51:21 roadrunner vdr: [22511] device 1 receiver thread started (pid=22467, tid=22511, prio=high)
Jun 27 17:51:21 roadrunner vdr: [22467] creating directory /var/cache/vdr/vtx/S19.2E-1-1010-11150
Jun 27 17:51:21 roadrunner vdr: [22512] device 1 TS buffer thread started (pid=22467, tid=22512, prio=high)
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:

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

    und wieder zurück


    OK, verstanden, wo das Problem ist: Es gibt Plugins, die zurecht einen Receiver aufsetzen, aber keine Aufnahme sind. Ich habe auf meinem Test VDR osdtelext installiert und kann damit dein Problem reproduzieren.

    Also kann ich in markad so nicht prüfen ob eine Aufnahme läuft und muss mir was anderes einfallen lassen, oder die Funktion raus nehmen.

    Erstaunlich ist, dass das schon immer so war und es keiner gemerkt hat. Ich habe mir mal die Mühe gemacht, den commit zu suchen, mit dem die Funktion eingeführt wurde, der ist von 2010 ! Du gräbst hier einen 11 Jahre alten Bug aus ;)

    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.

    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

    Genau das ist aber das, was nicht geht: Ob das Device frei oder belegt ist, sagt nicht aus, ob eine Aufnahme läuft. Es kann ja, wie wir jetzt wissen, auch durch was anderes belegt sein.

    Ich habe aber schon eine Lösungsidee: Ich muss über die Timer gehen. Darüber bekomme ich auch den RunningStatus. Hoffentlich passt das mit dem Timing, dass der Timer Status früh genug aktualisiert wird, so dass ich das am Ende der Aufnahme schon prüfen kann.

    Meine Idee hat bei mir im Test funktioniert mit osdteletext. Test bitte mal mit diesem commit testen. Den VDR Patch kannst du wieder rausnehmen, ich teste jetzt über die Timer, nicht mehr über die Devices, somit sind die Receiver egal.

    Gefällt mir 1

    Wunderbar!


    Funktioniert hier auch:


    Danke,

    Stefan

    Vielen Dank für das Finden des Bugs und die unendliche Geduld beim Eingrenzen des Fehlers.

    Patch wird in die nächste Version übernommen.

    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.


    Mal wieder einen Segfault ???

    Ich teste mit ca. 2000 Aufnahmen von ca. 70 verschiedenen Sendern und hatte auf einer getaggten Version noch nie einen Segfault. Bei dir ist wohl einiges besonderes. ;)

    Kann ich mir die Aufnahme (tar auf das Aufnahmeverzeichnis, damit ich auch die Timestamps bekomme) runter laden ? Zugangsdaten dann per PM.

    Und bitte auch noch Infos zum OS und ffmpeg Version.

    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

    Auslöser des Segfaults war der gleichzeitige Wechsel der Anzahl der Tonspuren mit dem TS File Wechsel.

    Fix ist im git im Branch V03.

    Aber damit ist das Thema mit dem Sender noch nicht erledigt: Die Marken stimmen ja mal gar nicht, da funktioniert die Erkennung der horizontalen Balken nicht. Der Sender muss hier was anders machen, als die FTA Sender die ich kenne. Ich schaue mir das an, der Fix dafür wird es aber nicht mehr in die nächste Version schaffen, weil ich gerade im Abnahme Massentest bin und dann nur noch Fixe für schwere Bugs für die nächste Version mit aufgenommen werden.

    Die Version 3.0.6 ist auf vdr-plugin-markad verfügbar.

    Folgende Fehler beseitigt:

    - vermeide doppelten Start von markad nach Aufnahmeunterbrechung (thx Fourty2 )

    - Fix Segfault bei gleichzeitiger Änderung der Anzahl Tonspuren und TS File Wechsel (thx Fourty2 )

    - Funktion zur Erkennung laufender Aufnahmen neu geschrieben (thx Fourty2 )

    Und wie immer: viele kleine Fehlerbereinigungen und Optimierungen.

    Gefällt mir 5

    Fourty2

    Bei der o.g. Aufnahme sind die Balken schmäler als normal und werden damit nicht erkannt. Das habe ich bei meinen Aufnahmen noch nie so gesehen. Vermutlich ist das originale Format 1;85:1 und normalerweise wird dies von den Sendern auf 1,78:1 (=16:9) beschnitten und ohne Balken gesendet.

    Ich müsste aber grundsätzlich auch mit dem schmaleren Bereich zur Erkennung der Balken klar kommen. Das muss ich aber noch ausgiebig testen, darum auch der Fix nicht mehr in der aktuellen Version, sondern im Branch V03. Aber der ist ja bei dir eh schon Standard ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden