Posts by theonlychriss

    Ok, also irgendwas beim Update des EPG ist definitiv kaputt.

    Wenn man alles von Grund auf neu aufbauen lässt, ist vor und auch nach dem ersten Schreiben der Daten ins EPG die EPGD-Datenbank völlig in Ordnung, im EPG des VDR dagegen ist vor dem ersten Schreiben noch alles in Ordnung, danach sind alle Sendungen doppelt vorhanden (einmal mit, einmal ohne Daten von TVSP/TVM).

    Dreimal getestet - dreimal dasselbe Ergebnis.


    Was nun?

    Hast du mal bei horchi angeklopft? Vielleicht hat er eine spontane Idee.

    Lt. der Tabelle vdrs gab es auch noch keinen merge - falls der Eintrag da was zu bedeuten hat.

    Dafür habe ich jetzt jeden Eintrag bereits dreimal - jeder davon sieht etwas anders aus 8-(

    Kann es sein, dass der Merge kaputt ist?

    Hast du ggfs. mehrere epgd-Instanzen in der Tabelle vdrs stehen, die auf unterschiedlichen Interfaces horchen und somit zu unterschiedlichen Timestamps den Merge machen sollten? Das Problem hatte ich letzte Woche, bis ich mal gecheckt hatte, dass "lastmerge" bei dem "richtigen" vdr-Eintrag NULL gewesen war. Wie auch immer es dazu gekommen war.

    Hast du was an der channelmap.conf geändert ?


    Irgendwie sieht es fast so aus, als würde EPGD die VDR-Events nicht mit denen aus TVM/TVSP matchen können, weil auch keinerlei Daten aus TVM/TVSP im EPG zu sehen sind.

    Ich bin echt ratlos 8-<

    Wie sehen denn die Einträge (bzw. der Eintrag) in der channelmap.conf aus (jetzt mal nur konkret für den Eureka-Fall?). Vielleicht ist ja schon dort irgendetwas erkennbar?
    Habe dies aber auch öfters - wenn ich mich nicht irre, nur bei Sendern, die gemerged werden sollen, also wo VDR-EPG und das Externe eigentlich zusammenkommen sollen ...

    Hallo nobanzai,


    wenn ich das richtig interpretiere, was epgd mit meinen Timern so tut, wenn es solche Meldungen liefert, dann ist es so:
    Es gab mal das Event (also einen EPG-Eintrag) dafür, es wurde ein Timer angelegt.
    Jetzt ist das Event nicht mehr vorhanden Event (62899) '' of timer (frag' mich nicht, wieso) und dann entfernt epgd auch den Timer dazu.

    Wenn ich das falsch interpretiere, möge man mich bitte korrigieren.

    Du kannst ja mal nach dem Rockpalast suchen, den er hier eigentlich mal gemeint hat. Dürfte dann nichts zurückkommen, wenn ich mir das richtig zusammenreime.


    Viele Grüße,

    Chriss

    Hi Hopsi,


    hast du auch schonmal versucht, epghttpd so zu bauen, wie horchi hier in Beitrag #23 segfault von epghttpd beim Speichern von Timern vorgeschlagen hat?

    Denk' dabei dann direkt hier dran ;) :

    Jup (muss ich eigentlich -fno-stack-protector -O0 aus dem ifdef DEBUG Block auch noch entfernen, weil sich sonst das -O2 und -O0 bzw. die unterschiedlichen stack-protection Optionen beißen?):

    Viele Grüße,

    Chriss

    beim make solltest du dann sehen das die Optionen verwendet werden

    Jup (muss ich eigentlich -fno-stack-protector -O0 aus dem ifdef DEBUG Block auch noch entfernen, weil sich sonst das -O2 und -O0 bzw. die unterschiedlichen stack-protection Optionen beißen?):

    Code
    ...
    Compile main ..
    g++ -c -I/usr/include/mariadb -I/usr/include/mariadb/mysql -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fstack-clash-protection -fstack-protector-strong -Wl,-z,nodlopen -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fcf-protection=full -Wtrampolines -O2 -I/usr/include/python3.12 -I/usr/include/python3.12 -ggdb -fno-stack-protector -O0 -std=c++17 -D__STDC_FORMAT_MACROS -fPIC -Wall -Wreturn-type -Wformat -Wextra -Wparentheses -pedantic -Werror=format-security -Wunused-variable -Wunused-label -Wunused-value -Wunused-function -Wunused-local-typedefs -Wno-unused-parameter -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DBINDEST='"/usr/local/bin"' -DTARGET='"epgd"' -DLOG_PREFIX='""' -DPLGDIR='"/usr/local/lib/epgd/plugins"' -DUSEUUID -DUSEMD5 -DUSELIBXML -DUSELIBARCHIVE -DUSEJSON -DUSEGUNZIP -DSYSDWDIFO -DUSESYSD -I/usr/include/libxml2  -I/usr/include/libxml2  -I/usr/include/python3.12 -I/usr/include/python3.12 -DGIT_REV='"544018b"' -o main.o main.c
    ...

    aber wie kommt man nun dem Problem besser auf die Spur?

    Sieht immer noch gleich aus für meine Augen:

    Ist übrigens auch immer noch nur der epghttpd inkl. der Änderungen aus https://www.vdr-portal.de/forum/index.php?thread/136271-segfault-von-epghttpd-beim-speichern-von-timern/&pageNo=2

    den ich nach dem Bauen an seinen Bestimmungsort kopiert und dann gestartet habe. Der epgd ist "der Alte", der läuft ja und erstellt auch Timer via Autotimer korrekt, selbst mit "Auto" Option ...

    Merci horchi!


    Habe epghttpd nach deiner Vorgabe neu gebaut und die Executable davon benutzt ...


    Hat für mich erkennbar nur eine Sache geändert, nämlich, dass die Zeile Initialize python script '/etc/epgd/recording.py' nur einmal kommt:


    Und dies habe ich bisher noch nicht gesehen, scheint mir aber eine ganz andere Baustelle und somit Zufallsfund zu sein:

    Code
    2024-06-10T18:40:38.003433+02:00 HTPC epghttpd: webif: TypeError: t.find(...)[0] is undefined$line: 1$column: 100433$error: loadData/<@http:/192.168.0.10:8888/epgd.js?1.3.24:1:100433$i@http://192.168.0.10:8888/common.js?1.3.24:2:27151$fireWith@http://192.168.0.10:8888/common.js?1.3.24:2:27914$z@http://192.168.0.10:8888/common.js?1.3.24:4:12120$send/c/<@http://192.168.0.10:8888/common.js?1.3.24:4:15680$


    Hier noch der bt von der gepatchten Version des epghttpd:

    Bin wieder und weiterhin ratlos.

    Hi horchi,


    danke vielmals für das mini-How-To. Resultat ist:

    Code
    $ ./pytst "tvm" "S19.2E-1-1107-17501" 191051494 1
    20:57:13,346  Info: Calling mysql_library_init()
    20:57:13,346  Calling mysql_init(14130)
    20:57:13,347  SQL client character now 'utf8mb3'
    20:57:13,347  Event 'Die Simpsons/Angst essen Seele auf' found
    20:57:13,347  Initialize python script '/etc/epgd/recording.py'
    20:57:13,367  Result of call: Die Simpsons~17x02 - 358. Angst essen Seele auf
    20:57:13,367  Info: The recording name calculated by 'recording.py' (with namingmode 1) is 'Die Simpsons~17x02 - 358. Angst essen Seele auf'
    20:57:13,370  Info: Released the last usage of mysql_lib, calling mysql_library_end() now
    20:57:13,370  Closing mysql connection and calling mysql_thread_end(14130)

    Weiß jetzt nur nicht, ob ich das gut oder schlecht finden soll :saint:


    Viele Grüße,

    Chriss

    So, heute ließ sich das Repository der debug-Symbole ansprechen und ich habe das einzige Paket, das ansatzweise danach aussieht, installiert:


    Der BT sieht nicht anders aus?!

    Dasselbe mit valgrind laufen lassen ergibt diesmal eine sehr lange Textdatei, s. Anhang valgrind.zip valgrind.zip.

    Ehrlich gesagt, verstehe ich nun nicht, warum darin kein bisschen von der libmicrohttp die Rede ist...


    Viele Grüße,

    Chriss

    Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?

    Bin bis dort kurz davor gekommen und laufe beim apt-get update in diesen issue und muss wohl warten, bis das behoben ist:

    Bug #1975865 “Hash and size mismatch with http://ddebs.ubuntu.co...” : Bugs : apt package : Ubuntu
    When adding the debug repos, I am getting: E: Failed to fetch http://ddebs.ubuntu.com/dists/bionic-updates/main/binary-amd64/Packages.gz File has unexpected…
    bugs.launchpad.net


    ganz blöde Frage, die Meldung Cannot find function ... hast du nicht im Log des epghttpd ?
    oder Failed to load ... ?

    Nein, nicht zu sehen.


    Bzw. welche Meldungen kommen bei Start nach Initialize python script?

    Habe mal den hoffentlich relevanten Part vom epgd-Start, sowie epghttpd-Start rausgesucht (bei epgd gibt es die Zeile einmal, bei epghttpd doppelt!?):


    Noch eine Frage:

    Verstehe ich es richtig, dass auch bei erfolgreichem "Durchschleusen" der event Datenstruktur aus dem C++ Kompilat ins python-Modul, keine .pyc erzeugt wird?


    Danke euch beiden fürs Dranbleiben und viele Grüße,

    Chriss

    Das event-Modul kommt aus dem C++ Code: https://github.com/horchi/vdr-…/master/lib/python.c#L172 ff. - d.h. ohne dass epgd/epghttpd den Python-Interpreter startet und ihm das Modul unterschiebt (https://github.com/horchi/vdr-…/master/lib/python.c#L223), wird man von außen nichts davon sehen.

    Habe mir schon gedacht, dass ich etwas übersehe. Danke für die Erklärung!


    Kannst du mal die Debug-Pakete für Python installieren (python3-dbg und libpython3-dbg und die Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?

    Mache ich, sobald ich wieder an den Rechner komme.

    Danke horchi!


    Seltsam, dachte es sei ein generelles Problem, weil ich die recording.py halt auch so nicht (on-the-fly) compiliert bekomme (gibt keine recording.pyc).

    Oder ich hab' ein Brett vor'm Kopf?!...

    Code
    chriss@HTPC:/etc/epgd$ python recording.py 
    Traceback (most recent call last):
      File "/etc/epgd/recording.py", line 27, in <module>
        import event
    ModuleNotFoundError: No module named 'event'


    Ich frage mich halt, woher das event kommen soll, wenn nichts im gleichen Verzeichnis liegt, oder auch sonst im Quellcode nicht:

    Code
    chriss@HTPC:/usr/local/src/vdr-git$ find ../vdr-epg-daemon-httpd.git/ -name "event*"
    ../vdr-epg-daemon-httpd.git/http/src/js/eventDetail.js
    ../vdr-epg-daemon-httpd.git/configs/eventsview-uti.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsviewplain-3po.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsviewplain.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-horchi.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-ck.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-3po.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview.sql
    ../vdr-epg-daemon-httpd.git/configs/eventsview-perlbo.sql


    Python ist 3.12.3-0ubuntu, s. Screenshots


    Vielleicht ist es ja schon etwas sehr Simples, was du daraus siehst.


    Oder hier die Ausgabe beim Crash mit valgrind:


    Viele Grüße,

    Chriss

    Hi Horchi,


    meinst du den Coredump?

    Sehr gerne, habe ein paar anzubieten und sie am Issue in github hochgeladen.

    Wegen der Dateinamensrestriktionen musst du vermutlich die eine umbennen (".zip entfernen"), um die beiden Zip-Teile entpacken zu können.


    VDR ist 2.6.7


    Danke schon bis hierher und viele Grüße,

    Chriss

    Ich antworte mir mal selber:

    Durch Zufall habe ich gerade bemerkt, dass Timer erfolgreich ohne Segfault gespeichert werden, wenn diese bei "Ermittlung des Dateinamens" den Wert "VDR" gesetzt haben. Alle anderen Werte führen zum Absturz.


    Sieht so aus, als sei dies tatsächlich auf den Aufruf der recording.py zurückzuführen... aus der Hilfe von epghttpd:

    Quote

    Der Dateinamen wird, mit Ausnahme des Mode 'VDR', über das Python Skript (/etc/epgd/recording.py) ermittelt, er kann bereits Pfadangaben erhalten.

    • 0 VDR: Keine Ermittlung des Dateinamens, die Bezeichnung der Aufnahme wird dem VDR überlassen lediglich das unten angegebene Verzeichnis wird vorangestellt.
    • 1 Auto: Automatische Auswahl des Mode Constable, Serie oder Kategorisiert
    • 2 Constable: Dateinamen basierend auf Daten von Constabel (Titel/Staffel/xTeil-Nummer/Untertitel) sofern verfügbar
    • 3 Serie: Serienaufnahme ohne Verwendung der Constabel Daten (Titel/Untertitel)
    • 4 Kategorisiert: Einorden der Aufnahmen entsprechend der Film-Kategorie (Kategorie/Titel)
    • 5 User: Hier kann man sich selbst im Python Skript verewigen
    • 6 Template: Der Dateiname wird in Eingabefeld unten definiert, hierbei können Platzhalter (%...%) verwendet werden. Bei Eingabe von % erscheint die Auswahl der Platzhalter

    recording.py macht ein import event, was wohl nicht funktioniert, da eine entsprechende Code-Datei nicht zu finden ist.

    Wie dies zu beheben ist, weiß ich zwar noch nicht, aber ich habe nun zumindest einen Workaround.

    Hallo zusammen,


    nachdem epghttpd nun startet (s. [Solved] epghttpd mit Problemen beim Start (Kubuntu 24.04)), ist das Speichern von Timern nicht möglich. Dabei ist es egal, ob neue Timer oder beim Ändern eines Timers.

    Ich bin jetzt erneut ratlos, ob dies an epghttpd liegt, oder an der libpython Version von Ubuntu 24.04. Konnte bisher nur so weit schauen, dass der Backtrace immer "gleich" aussieht, unabhängig davon, ob ein neuer Timer angelegt wird, wie viele Timer bereits existieren, ob ich einen bestehenden Timer ändere ... habe gedacht, dass ggfs. sonst der Paramter size bei _PyThreadState_PushFrame (tstate=tstate@entry=0x0, size=28) mal mit einem anderen Wert als 28 belegt sein würde ... size=28.

    Ein tstate=0x0 sieht auch nicht so richtig gesund aus?!

    Vielleicht hat jemand ähnliche Probleme (gehabt) oder sonst eine Idee, ob es wirklich ganz tief im System verbuddelt ist, oder "nur" an der Übergabe des Timers in die von epghttpd verwendeten Bibliotheken:



    Vielen Dank im Voraus und beste Grüße,

    Chriss

    Hallo rkp,


    bei mir sehen die Settings in der Config so aus:

    Code
    [softhddevice]
    -D -v va-api-egl -d :0.0 -a hw:0,3 -p hw:0,3

    wobei bei mir die Geräte so sind (der Verstärker ist RX-V6A und an HDMI-0, Gerät 3 angeschlossen):

    Du musst dies hoffentlich "nur noch" auf deine Begebenheiten anpassen und solltest dann Sound haben.

    Wobei es bei mir auch erst seit Ubuntu 23.10 und aktueller git-Version des Plugins geht.


    Viele Grüße,

    Chriss