Posts by theonlychriss

    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

    Hallo zusammen,


    nach Update auf Kubuntu 2404 noble numbat und neu-Kompilierung vom aktuellen git Code Stand (https://github.com/horchi/vdr-epg-daemon) startet der epghttpd Daemon momentan mit dieser Meldung im syslog, bzw. stürzt dabei ab:



    Hat dazu jemand eine Idee?


    Viele Grüße,

    Chriss

    Hi blueink,


    da ich gerade selber einen ähnlichen Fall hatte, kleiner Tip, falls du es noch nicht ausprobiert hattest:

    Der Watchdog Timer schlägt hier sehr wahrscheinlich zu, weil das "Schneide-Script" (s. Zeile 12 aus deinem Log-Snippet) vermutlich nicht so gestartet wird, dass es in den Hintergrund geschickt wird, sondern der VDR auf das Ende des Prozesses wartet. Bei größeren Aufnahmen dauert's halt länger als eine Minute und dann beendet der Watchdog den VDR. Versuch' daher mal, das Script irgendwie non-modal zu starten ...


    Bei mir war es sehr ähnlich, nur mit markad, das ich halt falsch (nämlich blockierend, nicht als Hintergrundprozess) als "after" Aktion aufgerufen hatte.

    Hoffe, dir hilft's.


    Viele Grüße,

    Chriss

    Hi Inj, 447377 - and of course all others,


    thx a million for this really simple solution:

    Just calling the plugin via its parameter "-v va-api-glx" instead of "-v va-api" already did the trick with the OSD!


    Cool - you made my day :].


    Then, only 720p channels stayed black (no picture, sound ok). 1080i (Servus-tTV) and SD channels worked just fine.

    Replacing the drivers as suggested by 447377 solved also that issue - even without re-compiling the plugin.

    But I'll do this later on anyway - just wanted to let you know the exact way I followed :*


    All the best!

    Chriss

    Hallo zusammen,


    habe am WE von KUbuntu 19.10 auf 20.10 aktualisiert und hänge nun am Endgegner ...

    Leider verzweifle ich seitdem daran, dass kein OSD im VDR gezeigt wird.


    Ich habe nun schon gefühlt alle Plugin-Forks, die sich compilieren ließen (vaapidevice, softhddevice - mit und ohne Jojo61) durchprobiert, auch egal, ob der VDR mit oder ohne skindesigner gestartet wird.

    Alle zeigen dasselbe Verhalten: kein OSD.


    Damit der VDR überhaupt ein Bild zeigt und nicht abstürzt, musste ich nach dem Update auf die non-free Variante der intel-Treiber wechseln (entscheidender Tip für die richtige Richtung hier im Forum, danke dafür):

    intel-media-va-driver-non-free


    Seitdem gehen Bild und Ton, jedoch kein OSD.


    Aktuell verwende ich dieses softhddevice:

    https://github.com/ua0lnj/vdr-plugin-softhddevice.git


    Die Meldungen mit "video/vaapi: no osd subpicture yet" und/oder "video/vaapi: can't find a supported subpicture format" müssten die ausschlaggebenden sein, jedoch habe ich keine Ahnung, wieso dies jetzt so ist. VOR dem Update gab es dieses Problem nicht.
    Im Anhang ein entsprechender Auszug aus /var/log/syslog (syslog.txt).


    Weitere Infos:



    Ich weiß einfach nicht mehr weiter, wo ich jetzt noch ansetzen sollte. Es müsste ja ein "grundsätzliches" Problem sein, wenn es sich nicht nur auf eine Plugin-Variante beschränkt.


    Hat hier jemand eine Idee, wie ich es wieder zum Funnktionieren bekomme?


    Viele Grüße,

    Chriss