[epgd] Ständig "SQL-Error in 'execute(stmt_execute)' - Division by 0 (1365) 'Division by 0' [call mergeepg]"

    Ich habe ständig mit dem Fehler

    Code
    SQL-Error in 'execute(stmt_execute)' - Division by 0 (1365) 'Division by 0' [call mergeepg]

    zu kämpfen. Manchmal geht es ein paar Tage, bis der Fehler auftaucht. Manchmal verschwindet er sogar nach ein ode rzwe Tagen wieder nur um kurz darauf wieder aufzutauchen.


    Wenn der Fehler da ist, wird das EPG nicht mehr aktualisiert:

    Code
    Updated changes since '23.07.2019 09:52:41'; 83 channels, 0 events (0 deletions) in 49 ms

    Habe die Datenbank erst heute morgen (7:30 Uhr) komplett erneuert (epgd-tool del-db/new-db)

    Und nun das:


    Verstehe nicht, was hier schief läuft. Bei allen anderen Nutzern scheint es doch zu funktionieren...

    Kann es an der Quelle liegen?


    Hier mal meine epgd-Konfiguration: https://www.dropbox.com/sh/wp1…TVwtu9CzwcyBj1uxbKGa?dl=0

    die Konfigurationsdateien helfen da nicht - wäre es was generelles hätten alle das Problem


    kannst du mal den 3306 nach außen legen dann schau ich mal nach den Daten ob da was auffällt

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    OK, mach ich... PN folgt

    Vielen Dank CKone

    Da sind wohl 0 Sekunden Events von BR schuld gewesen.

    Zumindest schon mal ein Ansatz.

    Jetzt muss nur noch eplists gehen, damit meine 300 auf unter 100 Timer schrumpfen

    Ja, ich habe den Fehler auch regelmäßig. Hatte bisher kein Idee, was ich da tun kann.

    Danke für den Tipp mit der Dauer der Sendung. Ich ändere jetzt einfach die Dauer auf 1.

    Code
    update events set duration=1 where duration=0;

    Danach läuft der merge wieder durch.

    Wundert mich nur, dass das sonst keiner hat. Aktuell habe ich wieder 9 Einträge drin, wenn ich nach Dauer 0 suche.

    Code
    mysql -u epg2vdr -pepg -Depg2vdr -e 'select * from events where duration=0;' > envents-duration0.txt

    Habe das mal in eine Datei umgeleitet und hier in den Anhang gepackt.

    Fünf davon sind bei Arte. Beispiel siehe Anhang.

    Kommen da falsche Daten von TVM oder wird das bei mir nur falsch ausgewertet.

    Hat jemand eine Idee, wo ich weiter suchen kann?


    Gruß

    nasenbär

    Willkommen im "Warum bin ich der Einzige, der den Fehler hat"-Club!


    Spaß beiseite. Mir wurde geholfen von CKone , da ich mit den Datenbank-Kram nichts anfangen kann. Man konn wohl ein "userexit.sql" in den Ordner legen, das die Events mit "0" auf eine Sekunde dauer ändert.


    CKone

    Kann ich die Datei hier anhängen, oder ist das nicht erwünscht?

    Ich hänge mal hier den Link zu der userexit.sql an:

    https://www.dropbox.com/s/jxxib7h05fk2ntt/userexit.sql?dl=0


    Damit werden die Events, die 0 Sekunden lang sind und von tvm stammen auf 1 Sekunde geändert.

    Vielen Dank für die schnelle Hilfe!

    Habe userexit.sql nach /etc/epgd kopiert, sieht gut aus.

    Code
    grep -i userexit /var/log/syslog
Sep  2 16:20:53 senshi epgd: Creating procedure 'userexit'
Sep  2 16:21:15 senshi epgd: Calling 'userexit'
Sep  2 16:21:18 senshi epgd: 'userexit' suceeded

    VDR-Server: Gigabyte B75M-D3H, i3-3220, TT S2-4200, TT S2-3200
    e-tobi VDR 2.4.1
    VDR-Client: Antec Micro Fusion Remote, Asus M4N78-VM, AMD Athlon II X2 235e,
    TT S2-1600
    yavdr 0.7

    hab letztens auch mal eins von tvsp gesehen:

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Gefällt mir 3

    Danke! Habe es bei mir mal angepasst.

    werde da im Winter mal nach schauen, auf die Schnelle konnte ich letztens die Stelle an der eine Division durch Null möglich ist nicht finden, und reproduzieren konnte ich es leider auch nicht.


    Interessieren würde mich jedoch warum das nur bei einigen zum Tragen kommt, möglicherweise hängt es auch mit der Version der verwendeten DB zusammen. - also ich nutze hier diese Pakete auf meinem Xenial Server:


    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Hallo zusammen,


    falls es bei der Fehlersuche hilft.

    Events mit Duration = 0 habe ich auch, siehe Anhang, aber es gibt keine SQL Fehler.

    envents-duration0.txt

    Für arte nutze ich nur epgdata dort habe ich nichts mit Duration = 0.

    System: Bionic

    VDR User: 2127
    YaVDR-focal , Case: HFX Classic, Mainboard: ASUS H97M-E, CPU: Intel Celeron CPU G1840T, GPU: GeForce GT 1030, DVB-S: 2x Digital Devices Cine S2 V6, VDR 2.6.6
    YaVDR-focal (24/7), Case: Akasa, Mainboard: NUC D34010WYB, DVB-S: Sundtek SkyTV Ultimate Dual, Miscellaneous: epgd, pihole, VDR 2.6.6

    YaVDR-focal (headless), System: HP 260 G2 DM, DVB-S: Sundtek SkyTV Ultimate Dual, VDR 2.6.6

    Ich habe auch 0-events, aber keine divide-by-zero-Meldungen. Wobei die 0-Events ganz sicher von keinem Suchtimer erfaßt werden.

    Have tvm und tvsp als Datenquellen.

    Dateien

    envents-duration0.txt 24,61 kB – 197 Downloads

    Die Versionen sind doch egal. Eine "duration" von Null sollte meiner Meinung nach so oder so nie in der Datenbank landen. Außerdem kann man doch Null-Werte abfangen.

    https://www.w3schools.com/sql/sql_isnull.asp

    Dann muss halt NULL (Steht wohl für Leer?) auch abgefangen werden

    Gleiche Problem hier; userexit.sql war auch hier erfolgreich:


    Code
    Oct  8 13:49:32 vaio epgd: Creating procedure 'userexit'
Oct  8 13:49:32 vaio epgd: Executing 'CREATE PROCEDURE userexit ()$BEGIN$/*$* fix tvm/tvsp duration = 0$*/$update$ events$set$ duration = 1$where$ source in('tvm','tvsp') and$ duration = 0;$END$'
Oct  8 13:49:32 vaio epgd: Storing 'userexit.md5' for 'epgd' with value 'fb7857650fa524b7aa60a1abb0515dff'
Oct  8 13:49:54 vaio epgd: Calling 'userexit'
Oct  8 13:49:54 vaio epgd: 'userexit' suceeded

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden