epg2vdr: syslog-Meldung: Closing mysql connection and calling mysql_thread_end

    Nach einem dist-upgrade gestern schreibt mein Client yaVDR das Syslog mit folgender Meldung zu:


    Code
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1917)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)


    Zugriff über
    mysql -u epg2vdr -pepg -Depg2vdr -h <server-IP> gelingt.


    Wie stelle ich das ab. Weshalb versucht der Client im Millisekundentakt auf den Server zuzugreifen?


    zur Info: nach dem dist-upgrade habe ich folgendes Resetting am Server vorgenommen:
    epgd-tool -del-all
    epgd-tool -new-db
    epgd-tool -new-u


    stop epgd
    start epgd (bzw. reboot)


    epgd-tool -show-stats (auf dem Server) sieht m.E. gut aus.


    Code
    root@yaVDR6:~# epgd-tool -show-stats
+------------------------------------------+--------+--------------+----------+--------------------------+--------------------------+--------------------------+
| version                                  | master | ip           | state    | last touch               | last download            | next download            |
+------------------------------------------+--------+--------------+----------+--------------------------+--------------------------+--------------------------+
| vdr 2.2.0 epg2vdr 1.1.52-GIT (2103.2017) | n      | 192.168.9.73 | attached | 23rd March 2017 12:44:11 | 23rd March 2017 12:29:26 | NULL                     |
| vdr 2.2.0 epg2vdr 1.1.52-GIT (2103.2017) | y      | 192.168.9.71 | attached | 23rd March 2017 12:44:07 | 23rd March 2017 12:29:26 | 22nd March 2017 21:08:38 |
| epgd 1.1.113-GIT (20.03.2017)            | -      | 192.168.9.73 | standby  | 23rd March 2017 12:43:11 | 23rd March 2017 12:30:10 | 24th March 2017 00:30:10 |
+------------------------------------------+--------+--------------+----------+--------------------------+--------------------------+--------------------------+

    Einmal editiert, zuletzt von CyberHogo ()

    Schau mal folgenden Beitrag an:
    http://www.vdr-portal.de/board…Cr-die-yavdr-stable-ppas/

    Gruß
    Frodo

    mmmh, wenn ich jedesmal die komplette Datenbank neu aufsetzen muss ist das Plugin möglicherweise nichts für mich.


    Nicht böse gemeint, aber es ist schon recht mühsam sich durch all die Threads zu arbeiten.
    Offensichtlich sind die älteren How To´s auch nicht mehr - so ohne weiteres -brauchbar.


    Leider habe ich momentan nicht die Zeit. Mal sehen, ob ich das Projekt nochmal relaunche.


    Wie ist dass denn mit den Paketen momentan -gibt es kein Testing mehr?
    Habe den Eindruck, dass ich diese Phase gerade im Stable habe.


    However: NEVER GIVE UP :mua

    Ich kann das Problem mit meinen VDRs, die die testing-Pakete nutzen und in meiner VM für stable nicht nachvollziehen. Die Datenbank muss nur einmalig nach dem Versionssprung auf die aktuellen epgd-Pakete neu aufgebaut werden - und zwar idealerweise in einer konzertierten Aktion (also alle VDRs stoppen, Datenbank vorbereiten, upgraden und wieder alles starten), wie im verlinkten Thread beschrieben. Dazu kommt (wie ebenfalls in Announcement-Post verlinkt) dass man die MySQL-UDF für epglv aktualisieren muss.


    Wenn du nicht aktiv mit liest, musst du halt damit leben, dass es Überraschungen gibt. Und testing findet umso mehr Fehler, je mehr Leute es nutzen... auf stable sitzen und dann motzen gilt nicht :P

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von CyberHogo


    Wie ist dass denn mit den Paketen momentan -gibt es kein Testing mehr?
    Habe den Eindruck, dass ich diese Phase gerade im Stable habe.


    So ist das mit Open Source, solange es im testing ist testet keiner und wenns dann nach fast einem Jahr ins stable geht wird lamentiert. ;(


    Uns/Mir wäre es auch lieber wenn alles was entwickelt wird immer problemlos aktualisiert werden kann bzw. funktioniert. Leider ist das gerade in letzter Zeit gar nicht so einfach.


    Der epgd Daemon wurde zwischen 0.3x und 1.0 komplett überarbeitet, deshalb muss man nun einmal die Datenbank wegwerfen und neu aufbauen lassen.
    Ausserdem sollte man sich die epgd.conf etwas genauer anschauen. Das dies nun durch ein update erzwungen wird, ist ärgerlich, aber durch yaVDR nicht abfangbar.


    Was würdest Du aber sagen wenn es keine Updates gäbe und über kurz oder lang nichts mehr funktioniert? Im speziellen beim EPG-Daemon gibt es ständig Änderungen bei den Quellen, ohne Anpassungen sind die EPG Daten irgendwann unbrauchbar.


    Wer keine Veränderung mag muß ja auch kein dist-upgrade machen, schon gar nicht wenn man keine Zeit hat und noch alles funktioniert.


    Ausserdem wäre es hilfreich bevor man einen neuen Beitrag auf macht, erst einmal zu schauen ob man zu seinen Problemen bereits was findet. Gerade zum EPGd wurde in den letzten Monaten sehr viel geschrieben.


    Das mußte ich mal loswerden.
    :prost2

    Gruß
    Frodo

    ich habe das gleiche Problem...


    Ic habe die komplette Db gedroppt und neu angelegt ... selber Fehler ?! hmm


    Ideen?

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5

    Interessant, ich kann die Meldungen u.a. provozieren, wenn ich das Timer-Menü öffne oder auf das live-Plugin zugreife.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    horchi vermutet, dass es Broadcast Calls für den ChildLockService sein könnten, auf die epg2vdr fälschlicherweise reagiert. Wenn das Git aktualisiert wurde (voraussichtlich im Laufe des Nachmittags), baue ich neue Pakete.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    stimme seahawk zu; die Meldungen beginnen, nachdem ich per life-plugin auf den VDR zugreife.
    Schließe ich das Browserfernster hören die Meldung sofort auf. Möglicherweise also ein Zusammenhang mit epgsearch?


    Vieleicht kann jemand die Vermutung prüfen und reproduzieren.


    Zusatzfrage: Was hat es mit der Einstellung im VDR-Menü-Plugins-Einstellungen-epg2vdr SVDRP Interface zu tun.


    Hier gibt es die Optionen a) lokal (127.0.0.1) und b) eth0 (eigene IP des Clients). Kommt das nicht aufs gleiche raus?
    Oder hab ich die Einstellungen irgendwo verstellt.

    Nachtrag: der vorherige Post bezog sich auf meinen Server-VDR.
    Auf dem Client laufen die syslog-Meldungen munter weiter, egal ob auf Life zugegriffen wird oder nicht.

    Zitat von CyberHogo

    Hier gibt es die Optionen a) lokal (127.0.0.1) und b) eth0 (eigene IP des Clients). Kommt das nicht aufs gleiche raus?

    Nein, das sind zwei unterschiedliche Netzwerkgeräte, lo ist normalerweise schneller.


    Zitat von CyberHogo

    Auf dem Client laufen die syslog-Meldungen munter weiter, egal ob auf Life zugegriffen wird oder nicht.

    Was sind da für Plugins aktiv?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Installierte Plugins:

    installiert heißt ja nicht aktiv

    Code
    vdr --showargs

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    hast ja Recht ...


    Außer dem bösen Plugin, burn, iptv, graphtlcd und remotetimers sieht das bei mir ähnlich aus - die letzteren beiden wären Kandidaten, die auf Events und Timer des VDR zugreifen - wenn man es genau wissen will, kann man die ja mal testweise deaktivieren, aber ich hoffe, dass horchi da später noch etwas ins Git bringt, das die Ursache behebt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Fix für die dauernden DB Connects ist im GIT (war der Service Call)


    Grüße Jörg

    Ich hoffe mal, dass die neuere libtinyxml2 nichts kaputt macht, aber ansonsten kommen die aktualisierten Pakete bald auch für trusty :)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Was ich noch anmerken wollte: bitte epgd auch aktualisieren (und neu starten!), damit die Felder in der Datenbank zum Plugin passen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden