epg2vdr - deadlocks

  • Das ist der epg2vdr vom Server und der epgd, der vermutlich auch auf dem Server läuft. Das ist nur unterschiedlich, wenn epgd auf einem eigenen Host läuft.

  • Ja, der EPGD läuft auch auf diesem Server. Wieso trägt der sich in vdrs ein?

  • Die Frage muss horchi beantworten, aber ich vermute mal, weil ihm der Name vdrs_und_epgd als Tabellenname zu lang war. ;)

    Einmal editiert, zuletzt von kfb77 ()

  • Hier aber habe ich Einträge mit derselben IP drin, von denen einer einen leeren Port hat:

    ja das eine ist der epgd da wird das nicht benötigt.
    Sieht alles gut aus und erklärt nicht die locks.

  • die Deadlocks kommen jedenfalls aus dem EPG Handler. Du verwendest das epg2vdr 1:1 aus dem git ohne weitere Patches wie z.B. den VPS Patch?

    Wie oft hast du die Deadlocks?


    Hast du diese Meldungen?

    Code
    Feb 21 09:28:44 gate vdr: epg2vdr: Got epgd state 'busy (match)' (4)
    Feb 21 09:29:09 gate vdr: epg2vdr: Got epgd state 'standby' (1)

    Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.


    Ich habe hier keinen einzigen Deadlock in der gesamten log Historie:

  • Ich habe mal meine (wegen VPS absichtlich) unzulässige Konfiguration mit zwei Master korrigiert. Seit dem habe ich keine Deadlocks mehr. Somit ist klar, bei mir kommen die davon und es ist kein grundsätzliches Problem. Da ich den Verdacht eh schon hatte, habe ich das auch nie als Problem gepostet. Vielleicht hilft euch die Info zur weiteren Eingrenzung in euren Systemen.

  • es steht zwar bereits im README des Plugins ich habe die Formulierung jetzt noch ein klein wenig angepasst:


    Code
    Update DVB EPG Database
    Master/Slave Mode (one client should be master, e.g. 24/7 Server, all others slave)
    - auto: Normally first VDR will be master - the master transfers the DVB events to the mariadb Server
    - yes: Master mode on
    - no: Master mode off
    Make sure that only one VDR will be master or you run into DB performance issues or deadlocks.

    kommt aber erst mit der nächsten Version ins git.

  • Ich habe nur einen VDR mit lokaler DB

  • Mir gehts gleich wie MegaV0lt: lokaler VDR mit lokaler DB und trotzdem immer mal wieder Deadlock-Meldungen im syslog.

    Stört offenbar inhaltlich nicht, aber wollte ich hier kundtun.

    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

  • Wie oft hast du die Deadlocks?

    Wie geschrieben 5x seit 5.02.


    Zitat

    Hast du diese Meldungen?

    Code
    Feb 21 09:28:44 gate vdr: epg2vdr: Got epgd state 'busy (match)' (4)
    Feb 21 09:29:09 gate vdr: epg2vdr: Got epgd state 'standby' (1)

    Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.

    Nein, hab ich nicht. Trotzdem mal hier das Drumherum um den letzten Deadlock:

  • Nein, hab ich nicht. Trotzdem mal hier das Drumherum um den letzten Deadlock:

    wenn du in deinem log keine Got epgd state Meldungen des epg2vdr Plugins findest ist das die Ursache für die Deadlocks.
    Diese Meldungen kommen mit log level 1, also wenn du den auf 1 oder größer hast und die Meldungen ausbleiben müssen wir nur noch herausfinden warum des Plugin den Status des epgd nicht mitbekommt.

  • wenn du in deinem log keine Got epgd state Meldungen des epg2vdr Plugins findest ist das die Ursache für die Deadlocks.
    Diese Meldungen kommen mit log level 1, also wenn du den auf 1 oder größer hast und die Meldungen ausbleiben müssen wir nur noch herausfinden warum des Plugin den Status des epgd nicht mitbekommt.

    Sry, man sollte nicht so spät nachts noch Protokolle wälzen 8-<

    Doch ja, ich habe die von dir genannten Meldungen gefunden.

    Also alles gut.

  • Zitat

    Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.

  • Du meinst hier auch die "got epgd state" Meldungen?
    Siehe Anhang.

    Dateien

  • der Deadlock passiert im Handler (das Statement wird nur von Handler ausgeführt, der Handler ist auch (wie man im Log sieht) schon wieder 'active'. Das ist auch richtig da der epgd zwar noch 'busy' ist dies aber nur noch mit den images.
    Aus deinem Log:

    Code
    #> egrep "(Got epgd state|Deadlock|handler)" server.log.txt
    Feb 20 10:05:52 server vdr[22142]: epg2vdr: Got epgd state 'busy (images)' (6)
    Feb 20 10:05:52 server vdr[22142]: epg2vdr: Change handler state to 'active'
    Feb 20 10:05:56 server vdr[22142]: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock ...
    Feb 20 10:06:09 server vdr[22142]: epg2vdr: Got epgd state 'busy (scraping)' (5)

    In dieser Situation hatte ich hier noch nie einen Deadlock und kann es mir erst mal nicht erklären.
    CKone kennst du eine maria/mysql Server Einstellung welche das Lock Verhalten dementsprechend beeinflussen könnte? Mir fällt gerade nichts ein.

    Einmal editiert, zuletzt von horchi ()

Jetzt mitmachen!

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