Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate.

  • Hi,


    ich habe ein (weiteres) Problem mit dem Seriestimer auf dem Server (Siehe Sig). Anscheinend wird eine beim Suchtimerupdate eine so hohe Last erzeugt, dass es zu Bildaussertzern im VDR kommt. Bemerkt habe ich Bildstörungen alle 30 minuten, auf HD-Kanälen dauern die Bildstörungen ca. 10-20s, auf SD 2-10s. Dies gilt für Livebild als auch für die Aufnahmen. Ohne vdrseriestimer bestand das Problem nicht.


    Ich hatte zuerst gedacht, dass man das mit einem besseren Nice-Level für den vdrseriestimer beheben könnte, allerding musste ich dann feststellen, dass dies schon vom YAVDR-Team berücksichtigt wurde (Danke nochmal an die gute Arbeitd es YaVDR-Teams). Der VDR-Prozess läuft ja schon hoch priorisiert auf nice-10, und vdrseriestimer mit super niedrieger Priorität 19.


    Der Server läuft mit xinelibout,. Im normalen SD-Betrieb (frontend läuft nicht auf dem Server) liegt die CPU-Last des vdr-prozesses nach top bei 2-5%. Beim epgsearchtimerupdate


    Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate taucht erwartunggemäß der Prozess vdrseriestimer auf, mit einer CPU-Last von 1-5% über 3-5 Sekunden. In etwa gleichzeitig steigt die CPU-Last des VDR-Prozesse auf etwa 45-55% an und es kommt zu Bildfehlern.


    Am nice-Level und zuwenig CPU-Perfomance sollte es also wahrscheinlich nicht liegen?. Nur wieso führt ein Suchtimerupdate nun zu solchen Problemen. Ist da was bekannt. Eigentlich sollte das ja so nicht passieren. Haben andere ähnliche Probleme?

    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

  • Zu Konkretisierung:


    Die Bildaussetzer ergeben sich in den Aufnahmen (also Störung in der Aufnahme) als auch im Live-Bild. Beim Abspielen einer Aunahme gibt es keine Bildaussetzer beim Suchtimerupdate. Der Problematik muss also irgendwo im Signalweg des Eingangssignals liegen. Also entweder werden die Signalübertragung der DVB-S-karten gestört (sind per USB2 angekoppelt, S2-3600) oder die Verarbeitung des TS-Streams.


    BTW: CPUfreq läuft nicht, da ich mit nem Xen-Kernel arbeite...

    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

  • Also mich wundert das es sonst keinen wundert. Bei mir hatte ich auch immer diese Probleme (schwache CPU, Softdecoding und viele viele epgsearch Treffer). Deswegen hatte ich mir das gebastelt: Proof of Concept: vdrseriestimer aufgebohrt... (ist noch nicht wirklich relesereif) damit das Suchtimerergebnis im EPG gespeichert wird und der vdrseriestimer für jeden EPG Eintrag nur einmal aufgerufen wird.
    Das Perl starten scheint auf schwächerer Hardware viel zu ziehen, vorallem da die Aufrufe so kurz aufeinander folgen.


    cu

  • Ist den nen Celeron G1610 so eine schwache CPU. Zudem wird das Bild auf dem Server (soweit ich das verstanden hab) doch gar nicht dekodiert im xinelibplugin, sondern doch erst auf dem client mit vdr-sxfe, oder? Top sagt ja auch, dass nicht das serriestimer die CPU-Last zieht (5%), sondern der vdr-prozess (ca 50%). Ich vermute daher das da was anderes hängt. Vielleicht bei der Übergabe der Parameter an de VDR?


    Ansonsten ist dein Ansatz natürlich eleganter, direkt den EPG mit den Seriendaten aufzuwerten ....

    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

    Einmal editiert, zuletzt von Negge ()

  • So ich hab jetz mal alle vdrseriestimer %Serie"%in den Suchtimer deaktiviert. Die Bildstörungen treten nicht mehr auf. CPU-Last des VDR steigt beim Update (SD-Kanal im Hintergrund) von 2-5% auf 35-65% und nur sehr kurz (ist mit top kaum zu erfassen, da Updateintervall zu kurz).


    Wenn ich nur einen einzigen Timer mit seriestimers laufen lassen, kommt es zu Bildaussetzter bei epgserchupdate. Zwar kürzer als zuvor mit den etwa 15 Timern vdrseriestimern, aber immer noch deutlich auch mit nur einem einzigen.


    Wie kommuniziert den der Seriestimer mit dem VDR. Gibt es da irgendeinen Flaschenhals, der zu Problemen führen kann. vdrseriestimer ist zwar ein super addon, aber so natürlich im praktischen Einsatz unbrauchbar für mich... ;(

    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

  • Ist den nen Celeron G1610 so eine schwache CPU. Zudem wird das Bild auf dem Server (soweit ich das verstanden hab) doch gar nicht dekodiert im xinelibplugin, sondern doch erst auf dem client mit vdr-sxfe, oder? Top sagt ja auch, dass nicht das serriestimer die CPU-Last zieht (5%), sondern der vdr-prozess (ca 50%). Ich vermute daher das da was anderes hängt. Vielleicht bei der Übergabe der Parameter an de VDR?


    Naja, der serientimer läuft ja (auch nur sehr kurz, das wird man in top nicht sehen) vermutlich auch im VDR Kontext. Das ist ja ein direkter Unterprocess. Aber das nur als Theorie, ich kenne mich mit der Prozessverwaltung von Linux nicht so aus.
    Meine generelle Erfahrung ist nur das es rein praktisch immer besser ist Scripte aus dem VDR hinaus per "echo foo | at now" aufzurufen (das geht hier aber leider nicht) weil sie sonst /irgendwie/ auf die VDR Performance gehen.


    Evtl. nimmt sich der Thread der auf stdout/stderr der gestarteten Scripte wartet (selbstverständlich dank nice mit höchster Priorität ;) ) zuviel Zeit und die anderen Threads (Aufnahme) bekommen nicht mehr genug? D.h. evtl. ist einfach die VDR Fuktion zum Shellaufruf nicht für derartige Fälle gedacht (oder hat für diese Fälle bissher ungefundene Bugs)?
    Son seriestimer Aufruf dauert ja min. 1 Sekunde. Und ich denke nicht das Klaus diese Sache für Scripte geplant hat die so ewig lange laufen.


    Wie kommuniziert den der Seriestimer mit dem VDR. Gibt es da irgendeinen Flaschenhals, der zu Problemen führen kann.


    Der VDR (d.h. der Suchtimer Thread von epgsearch) ruft einfach nur das Perl Script mit den Korrekten Kommandozeilenparamern auf. Und alles was per stdout/stderr zurückkommt ist dann der neue Verzeichnisname.


    Ansonsten ist dein Ansatz natürlich eleganter, direkt den EPG mit den Seriendaten aufzuwerten ....


    Der Anzatz ist sogar noch ausbaufähig. Im Moent wird ja modepg immer noch direkt aufgerufen. Man kann es später (ist geplant) auch als Daemon laufen lassen und epgsearch fragt per TCP an.


    cu

  • Ich habe gerade mal einen neuen Suchtimer erzeugt (für "Nicht nachmachen!") und beim anschließenden Suchtimerupdate kam es auch zu einem ganz kurzen Ruckler im Liverbild (ZDF HD). Wobei kein Serietimer mehr aktiv ist. Der Ruckler war auch wesentlich kürzer als mit Seriestimern, aber vorhanden. Ich hab dann nochmal manuell ein weiteres Suchtimer-Update gestartet. Da gab es dann interessanterweise keinen Ruckler. Der Unterschied zwiscen den beiden Updates ist eigentlich nur, dass er beim ersten Aufruf 3 Timer für "Nicht nachmachen!" neu angelegt hat, bei den nachfolgenden nicht. Evtl. ist daher die Problematik die Übergabe der Informaionen an den VDR vom epgsearch geschuldet?!? Und das mit dem seriestimer-addon wesentlich mehr Daten übertragen 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

  • Jetzt wo du es sagst... Timer anlegen geht bei epgsearch per svdrp. Und svdrp blockiert den VDR.
    Könnte ein weiterer Faktor sein.


    Wobei sich die Datenmenge (fürs Timer anlegeen/ändern) nicht ändert wenn der serientimer hinzukommt.


    Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk 2

  • Weiss zwar nicht ob es nun SVDRP oder Perl war - aber seitdem ich vdrseriestimer abgeschafft habe und das Gleiche mit xmltv2vdr mache habe ich keinerlei Lastprobleme mehr.
    Ich verwendete vdrseriestimer/eplist um den Speicherort zu generieren, also aus Serienname/Episodenname -> Serienname/S03E04_204._Episodenname
    Nun lass ich xmltv2vdr die Staffel und Episodeninfo ins EPG eintragen und epgsearch baut die nur noch zusammen, ganz ohne Perl und externe Aufrufe...

  • Nun lass ich xmltv2vdr die Staffel und Episodeninfo ins EPG eintragen und epgsearch baut die nur noch zusammen, ganz ohne Perl und externe Aufrufe...


    Hallo Joe,


    wie machts Du das? Hatte bis gestern auch mal xmltv2vdr + Grabber für tvm im Einsatz. Da wurden mir keine Episodeninfos ins EPG eingetrage, obwohl in den Settings aktiviert.
    Ich kenne das nämlich genauso vom tvm2vdr-Plugin. Das arbeitet nämlich auch ohne vdrseriestimer und da stehen immer schön alle Informationen im EPG. tvm2vdr holt auch gleich die eplists ab.


    Viele Grüße.
    Markus

  • Seid Ihr Euch sicher das es am vdrseriestimer liegt? Ich nutze das Skript nicht und habe auch Aussetzer mit aktivierten epgsearch Suchtimern.
    Ich muss das mal nähers untersuchen ob mit deaktivierten Suchtimern die Bildstörungen behoben sind, ich hatte gestern in einem ersten Versuch die EPG Aktualisierung deaktiviert.

    Gruß
    Frodo

  • Also ich hatte noch NIE Aussetzer beim Suchtimerupdate, weder mit vdrseriestimer noch die gesamte Zeit ohne.
    Ich Schnitt sind bei mir immer so zwischen 20-30 Suchtimer aktiv.

  • Joe_D
    ...das würde mich aber auch brennend interessieren, wie man das über xmltv2vdr abarbeitet! Kannst Du das mal zusammenfassen - bitte?

  • so sieht bei mir ein epg-eintrag von tvm2vdr aus:
    https://www.dropbox.com/s/xcx7343mec4aaxe/tvm2vdrepg.jpg


    daraus wir mittels epgsearchcats & epgsearchuservars ohne vdrseriestimer ein passender serientimer benamt.


    mit xmltv2vdr habe ich die einträge staffel, episode & staffelfolge nicht ins epg bekommen.

  • Moin!


    Ich nutze auch xmltv2vdr mit tvm-Grabber.


    Meine epgsearchcats.conf:

    Code
    101|Staffel,%02i|Staffel ab||13
    201|Episode,%02i|Episode ab||13
    301|Folge,%03i|Folge ab||13


    Im Suchtimer (über live) im Feld "Verzeichnis" dann

    Code
    %title%~%folge% - S%staffel%E%episode% - %subtitle%


    eintragen. Außerdem aktiviere ich "ignoriere fehlende EPG Info", falls ich über "Verw. erweiterte EPG Info" auf bestimmte Staffeln usw. einschränke.


    Und in den xmltv2vdr-Einstellungen muss natürlich entsprechend eingestellt werden, dass er die Staffel-Infos übernehmen soll (ich glaube, pro Kanal "Staffel und Episode: ja").


    EPG sieht dann z.B. so aus:

    Code
    Mi, 24.07.13 15:34
    How I Met Your Mother
    Neu ist immer besser
    Ted hat Angst, dass der Neubau der GNB eine Nummer zu groß für ihn ist. Barney und Robin haben nun Sorge, dass sich Ted aus diesem Grund wieder mit Zoey versöhnt. Als sie erfahren, dass sich die beiden in Brooklyn auf einen Kaffee verabredet haben, machen sich Barney und Robin sofort auf den Weg, um das zu verhindern ... Lily hat sich scheinbar den Magen verdorben - ihr ist ständig übel. Marshall, der dasselbe gegessen hat, zeigt jedoch keine Symptome. Was steckt dahinter?
    Staffel: 6
    Episode: 24
    Folge: 136


    Lars.

  • ofenheizer
    genau darum gehts mir. Die Variablen für Staffel & Co. müßen sicherlich noch irgendwo konfiguriert werden... Als Textzuordnungen sind sie in xmltv2vdr bereits drin. (Staffel, Episode, Folge) Im EPG ist bei mir davon auch leider nichts zu sehen...

  • Danke Lars.
    Genau, dann ist es die epgsearchcats.conf ...


    Sollte man evtl. mal auf der Wiki-Seite des Plugins mit angeben, denn davon ist keine Rede und ich habe beim Testen natürlich meine, zu tvm2vdr passende, geleert, da ich dachte, die wird nicht gebraucht.


    Werde ich dann mal an meine Dateien anpassen.


  • Einfach mal ein bisschen die Quellen besser anschauen, ja?


    http://projects.vdr-developer.…/tree/dist/epgsearch.conf


    Danke. Da wird einiges klarer.
    Ich beziehe das Plugin aber aus dem yavdr-Repo als Paket und da waren die Dateien nicht enthalten :)


    Gruss.
    Markus

  • ...also ich bekomme ums verrecken keine Staffel/Folge - Infos ins EPG! :wand Kann das an meinem Grabber liegen? Wenn ja, hat jemand vielleicht einen aktuellen für mich?

Jetzt mitmachen!

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