Posts by theonlychriss

    Was hast du denn noch an Plugins bzw. an Patchen?

    Bewusst nur den einen Patch - bei 2.6.6 muss ich genauer hinschauen.

    Bei VDR-2.7.3 definitiv nur den für libcap fürs statusleds-plugin, hatte die VDR-Version direkt via git ausgecheckt und den Patch angewendet.

    Habe es als Anlass genommen, meine Signatur auf Stand zu bringen ...

    Plugins: epg2vdr, lcdproc, markad, skindesigner, softhddevice, statusleds, streamdev-server, svdrpservice, vnsiserver

    Ab welcher vdr Version passiert das bei dir (bisect zwischen 2.6.6 und 2.7.3 = 3 Tests)?

    Sehr gute Idee, bin dran, wird aber etwas dauern.

    Danke jrie!

    Interessant wird's leider nun umso mehr. In Ubuntu ist die v2.66 von libcap schon seit 23.10 enthalten (wenn die Infos von cap_from_text stimmen), davor war's 2.44. Bin auch die Änderungen zwischen 2.63 und 2.66 einzeln durchgegangen und habe dabei für meine Augen nichts auch nur annähernd Verdächtiges gefunden.

    Musste mein System auf kUbuntu 24.04 zurückrollen (Backup der Platte von vorher eingespielt), weil Ubuntu in 24.10 Wayland als default eingestellt hat.

    Da softhddevice kein Fenster mit Wayland geöffnet bekommt ... und ich es ums Verrecken nicht hinbekommen habe, X11 wieder zu reaktivieren, ohne mich dazu jedes Mal manuell anmelden und dabei X11 auswählen zu müssen, habe ich die Rolle rückwärts gemacht.

    Trotzdem habe ich dann von vdr-2.6.6 auf vdr-2.7.3 aktualisiert (ich compiliere immer alles rund um den VDR selber) und da ist das Verhalten haargenau gleich.

    Mit Patch kommt: cap_from_text failed: Invalid argument, ohne Patch: natürlich kein blinkendes LED; weshalb ich momentan noch "meine" Version von statusleds weiterbenutze, die den blinkd nutzt.

    Bin also erst einmal noch ratloser als vorher, aber ggf. hilft dies dem einen oder anderen Mitleser, sich ein Update auf (k)Ubuntu in ähnlichem Szenario wie meinem, reiflich zu überlegen oder für sich schneller Ursachen eingrenzen zu können.

    Viele Grüße,

    Chriss

    Hallo zusammen,

    habe heute von kUbuntu 24.04 auf 24.10 aktualisiert, den VDR (2.7.3) und Plugins neu kompiliert und nun logged das statusleds-plugin:

    2024-11-14T17:19:33.008777+01:00 HTPC vdr[92982]: vdr: cap_from_text failed: Invalid argument

    2024-11-14T17:19:33.009450+01:00 HTPC systemd[1]: vdr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

    2024-11-14T17:19:33.009506+01:00 HTPC systemd[1]: vdr.service: Failed with result 'exit-code'.

    wenn der VDR mit dem folgenden Patch versehen wurde (aus "patch_for_vdr.diff" aus dem neuen Plugin Sourcecode:

    Code
    cap_sys_tty_config=ep

    Wenn ich dies entferne, startet der VDR normal, aber kann "natürlich" die Keyboard LED bei einer Aufnahme nicht blinken lassen.
    VDR logged dann beim Start:

    2024-11-14T18:20:47.695110+01:00 HTPC vdr: [103227] Status LED's: Thread started (pid=103204)

    2024-11-14T18:20:47.695143+01:00 HTPC vdr: [103227] ERROR: Status LED's: Can't open console /dev/tty

    2024-11-14T18:20:47.695165+01:00 HTPC vdr: [103227] Status LED's: Thread ended (pid=103204)

    Habe ich auch hier gemeldet, vielleicht kennt jemand ja eine Lösung oder hat eine Idee dazu ...

    Viele Grüße,

    Chriss

    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:

    https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1975865

    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-plu…b/python.c#L172 ff. - d.h. ohne dass epgd/epghttpd den Python-Interpreter startet und ihm das Modul unterschiebt (https://github.com/horchi/vdr-plu…b/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.