[markad] überarbeiteter Decoder

  • kfb77

    Hatte ich schon gestern abend erledigt, da die (offenbar unnötigen) Umschaltungen eher mehr Probleme erzeugten, als behoben ( = ab und an kommt per CI kein Bild).


    Ob dies das Markad Problem löst, denn die PID-Update/Retune/Aufnahme Stop+Resume macht ja auch VDR ja auch ungepatcht, wird sich zeigen. Ansonsten muß ich da mal selbst nachsehen - oder wieder auf "live" stellen.


    Stefan

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



    Stefan

  • Das war auf jeden Fall zu erwarten, weil das kann ich ja testen. Nur Unterbrechungen kann ich nicht testen, da keine SAT Karte, ich nutze das SAT IP Plugin.

    Wichtig ist der Log Eintrag:

    Code
    Jun 26 15:35:00 roadrunner vdr: [11060] markad: cStatusMarkAd::RunningRecording(): 0 running recordings

    Wenn der kommt, folgt auch der resume.

    Spannend wird sein, was macht der ungepatche VDR nach einer Unterbrechung.

  • Kann man "Unterbrechung" nicht einfach simulieren, in dem man das SAT-Kabel abzieht und wieder ansteckt?

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Isch habe kein Auto ähhh SAT Kabel am Test VDR.

    Und wenn ich das SAT Kabel am OctopusNet abziehe brauche ich irgendwo Asyl, da hängen alle Fernseher, Tablets, Laptops und der produktive VDR im Hause dran. Den Stress willst du nicht haben ...

  • Und wenn Du das LAN-Kabel am Test-VDR kurz abziehst?


    Stefan

  • Nicht mal das geht so einfach, weil der Test VDR keine physikalische Maschine sondern nur ein virtueller Container auf dem Homeserver ist, auf dem auch der produktive VDR (und einiges anderes) läuft, Und selbst dann wäre das Verhalten nicht mir dem Problem bei Fourty2 vergleichbar.

  • Nachtrag: Danke für den Ansatz, es gibt keine Idee, die es nicht wert ist zu versuchen. Ich habe mal das virtuelle Kabel gezogen, also das virtuelle Interface im Container disabled:

    Code
    Jun 26 21:10:47 VDR-2004-Dev systemd-networkd[123]: eth1: Link DOWN
    Jun 26 21:10:48 VDR-2004-Dev systemd-networkd[123]: eth1: Lost carrier
    Jun 26 21:10:49 VDR-2004-Dev vdr: [29611] curl_easy_perform() [rtsp.c,369] failed: Timeout was reached (28)
    Jun 26 21:10:49 VDR-2004-Dev vdr: [29611] SATIP-ERROR: Detected invalid status code 0: rtsp://10.1.10.216/ [device 0]
    Jun 26 21:10:49 VDR-2004-Dev vdr: [29611] SATIP-ERROR: Pid update failed - retuning [device 0]
    Jun 26 21:10:54 VDR-2004-Dev vdr: [29611] SATIP-ERROR: Connection timeout - retuning [device 0]
    Jun 26 21:11:14 VDR-2004-Dev vdr: message repeated 4 times: [ [29611] SATIP-ERROR: Connection timeout - retuning [device 0]]
    Jun 26 21:11:17 VDR-2004-Dev vdr: [38835] ERROR: video data stream broken
    Jun 26 21:11:17 VDR-2004-Dev vdr: [38835] initiating emergency exit
    Jun 26 21:11:17 VDR-2004-Dev vdr: [29607] emergency exit requested - shutting down

    Wie vermutet ist das Verhalten komplett anders, der VDR ist gleich komplett beleidigt und startet neu.

  • Ich habe es bei mir an, weil es ja nicht von Problemen mit der SAT Karte ausgelöst werden kann, sondern eigentlich nur von Netzproblemen. Und dann ist eh alles weg.

  • 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

  • Ja, reiner Aufnahmeserver, Wiedergabe über DNLA und SmartTV Client vom Fernseher oder über NFS und Kodi. Auf dem Aufnahmeserver läuft so wenig wie möglich und dann läuft er auch absolut stabil. Ja, Stromverbrauch ist natürlich da, aber ein Hobby kostet eben Geld ...

  • 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

  • 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).

    Die Log Meldung "running recording on device 0" werde ich mal für den nächsten Update ändern, die ist nicht ganz korrekt. Genauer gesagt bedeutet dies, dass mindestens eine Aufnahme auf dem Device läuft.

    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 ...


    Ich versuche mal eine Version zu bauen, die dem VDR entlockt, welche Aufnahmen seiner Meinung nach noch laufen.

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

  • 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
    Jun 27 10:57:16 VDR-2004-Dev vdr: [50862] markad debug: 2 receiver(s) runnning on device 0
    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.

  • 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
    Jun 27 10:57:16 VDR-2004-Dev vdr: [50862] markad debug: 2 receiver(s) runnning on device 0
    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

  • Sieht mir - derzeit - eher so aus, als wenn beim PID-Update, das jeweils den MarkAd-Prozess killed, was schief läuft.

    Der Kill vom markad Prozess ist gewollt, da der Neustart der Aufnahme einen neuen markad Prozess auf die gleiche Aufnahme erzeugt. Sonst hätten wir zwei Prozesse auf die gleiche Aufnahme. Aber die Stelle habe ich auch im Verdacht. Die genaue Stelle werden wir aber (hoffentlich) mit den nochmals erweiterten Logs sehen.

    Kannst du bitte auch mal mit FTA Sendern testen, vielleicht entsteht das Problem auch in der Ecke nach dem PID-Update.


    Edit:

    Code
    UpdateChannels = 0

    Wäre auch noch einen Versuch wert.

    2 Mal editiert, zuletzt von kfb77 ()

  • Ich habe jetzt den Code im VDR gefunden, der die Receivers zurücksetzt. Ich habe die Debugs nochmal erweitert um den Aufruf zusehen (oder zu sehen, was genau fehlt). So müsste es nach dem PID Update aussehen wenn es funktioniert:

    Code
    Jun 27 16:18:58 VDR-2004-Dev vdr: [57897] markad debug: cRecordControl::Stop called
    Jun 27 16:18:58 VDR-2004-Dev vdr: [57897] markad debug: cRecorder destructor called
    Jun 27 16:18:58 VDR-2004-Dev vdr: [57897] markad debug: cReceiver::Detach() called
    Jun 27 16:18:58 VDR-2004-Dev vdr: [57897] markad debug: cDevice::Detach called
    Jun 27 16:18:58 VDR-2004-Dev vdr: [57897] markad debug: cDevice::Detach delete receiver 0

    Der Diff in der Anlage gegen den VDR anwenden.

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


    Na gut, nochmal...


    Edit:

    Hunk failed...


    sieht bei mir jetzt so aus - hoffe äquivalent:


    Stefan

Jetzt mitmachen!

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