[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update

  • Hab noch einen neuen Segfault (nach Auskommentieren des letzten Fehlers oben):



    Backtrace vom "laufenden Betrieb" der plötzlich (Re-)Startenden Kiste...


    Log endet da:


    Stefan

  • Wenn ich das richtig verstehe, bleibt nach einem Erase lediglich das Start-Element der Iteration gültig.

    Ein for() Loop ist demnach eher ungünstig, wenn man alle Elemente löscht.


    Hab das jetzt mal so gepachted - so läuft es erstmal und scheint noch zu funktionieren.



    Stefan

  • Fourty2

    Der Patch scheint zu funktionieren. Bei mir trat der Seqfault nur auf wenn tatsächlich ein Timerkonflikt vorlag und das geht jetzt wieder. Timerkonflikte werden also wieder angezeigt.


    Allerdings scheint es im Patch einen Fehler zu geben. Die Zeilen 33 und 40 sehen bei mir so aus:


    Code
    1. LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->timer->Channel()), DAYDATETIME(checkTime->evaltime), device + 1);


    kamel5

    VDR 2.4.1: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 30 Kernel 5.3 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Wenn keine negativen Rückmeldungen mehr kommen, werde ich den Patch von Fourty2 ins git übernehmen, da er im Gegensatz zu den bisherigen Vorschlägen auch mit älten clib-Versionen kompiliert.

    vdr-2.4.1
    softhddevice, chanman, cdplayer, dbus2vdr, dvd, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vnsiserver

    ubuntu bionic, linux-4.15.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-ansible als Basis mit vielen Änderungen

  • Sieht auch für mich vernünftig aus

    vdr-2.4.1
    softhddevice, chanman, cdplayer, dbus2vdr, dvd, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, vnsiserver

    ubuntu bionic, linux-4.15.0 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-ansible als Basis mit vielen Änderungen

  • Gibt es schon ein Repository mit dem Patch von maazl?

    Falls nicht, wo finde ich denn ein Repository mit dem letzten Stand von epgsearch (also auch Anpassungen an VDR 2.4., ...)?

    VDR1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 18.04, VDR 2.4x
    VDR2: ASUS P4B533, Celeron 2.4G, FF 1.5, Ubuntu 10.10, VDR 1.6 (SS2 Rev 2.6B)
    VDR Server: sheeva-plug

  • Hier Debian Testing (gefreezed - {tolles Wort}) . Hab ich 'ne Chance, dass in absehbarer Zeit der Patch ankommt oder sollte ich mich auf den Weg eines selbstkompilierten VDR machen? Habe taeglich 10 - 30 Aufnahmen und ohne epgsearch ist das ein muehseliges Unterfangen.


    Dank und Gruss

    klak

  • Hier Debian Testing (gefreezed - {tolles Wort}) . Hab ich 'ne Chance, dass in absehbarer Zeit der Patch ankommt oder sollte ich mich auf den Weg eines selbstkompilierten VDR machen? Habe taeglich 10 - 30 Aufnahmen und ohne epgsearch ist das ein muehseliges Unterfangen.

    Es genügt, wenn du dir die aktuelle Version von epgsearch baust, den VDR (und die anderen von dir genutzten Plugins) musst du deswegen nicht selber bauen. Wenn du das als Debian-Paket haben willst, kannst du das Quellpaket aus dem yavdr-PPA nehmen:

    Code
    1. sudo apt install vdr-dev build-essential devscripts pkg-config
    2. sudo apt build-dep vdr-plugin-epgsearch
    3. dget -xu https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190116-1-49ba796-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190116-1-49ba796-0yavdr0~bionic.dsc
    4. cd vdr-plugin-epgsearch*
    5. dpkg-buildpackage -us -uc
    6. sudo apt install ../vdr-plugin-epgsearch*.deb

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Gibt es schon ein Repository mit dem Patch von maazl?

    Falls nicht, wo finde ich denn ein Repository mit dem letzten Stand von epgsearch (also auch Anpassungen an VDR 2.4., ...)?

    https://projects.vdr-developer…f0ebba68a25ddfc92d3d70aad

    https://launchpad.net/~yavdr/+…e/ubuntu/experimental-vdr

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich habe den Überblick verloren und stehe hier grad total aufm Schlauch. Ich konnte anhand der Logfiles des VDR das vdr-plugin-epgsearch als Segmentaion fault verursachendes Plugin Identifizieren. Aber jetzt geht der Mist wieder los ( Debian 10 / vdr 2.4.0 aus main Repos )


    Nachgelesen = o.g. Plugin hat im Programmcode eine Fehler in einem Loop => selbst kompilieren


    Dann bin ich nach o.g. Anweisungen vorgegangen ( dget -xu https://launchpad.net/~yavdr/+…9ba796-0yavdr0~bionic.dsc ) => Datei Offline


    Dann habe ich auf GIT Hub nach e-Tobis code gesucht, in der Repoliste steht eien gepachte version drin, aber ich diese nicht herunterladen.


    Als auch das nicht erfolgreich war habe ich nach einer Debian 10 Quelle für das EPG search Plugin gesucht : (https://packages.e-tobi.net/vd…ch/binary/vdr-multipatch/


    Wie fast immer bei den verfluchten VDR Kompilations Horror lief auch das nicht wirklich.


    Es ist jede mal der gleich Mist : Beim VDR Update läuft danach erstmal nichts stabil und richtig.


    Hier auch : https://salsa.debian.org/vdr-team/vdr-plugin-epgsearch: lt VDR version läuft alles auf vdr 2.4.0.. Die Kopilation endet dann wieder mit :

    Code
    1. dpkg-buildpackage -us -uc
    2. dpkg-buildpackage: Information: Quellpaket vdr-plugin-epgsearch
    3. dpkg-buildpackage: Information: Quellversion 2.4.0+git20190507-2
    4. dpkg-buildpackage: Information: Quelldistribution unstable
    5. dpkg-buildpackage: Information: Quelle geändert durch Tobias Grimm <etobi@debian.org>
    6. dpkg-buildpackage: Information: Host-Architektur amd64
    7. dpkg-source --before-build .
    8. dpkg-checkbuilddeps: Fehler: Nicht erfüllte Bauabhängigkeiten: vdr-dev (>= 2.4.1)
    9. dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch
    10. dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)


    Warum wird vdr-dev 2.4.1 verlangt wenn doch 2.4.0 als Code Grundlage genutzt wird ?



    Es wäre nett wenn mir helfen könnte, wie ich das vdr-plugin-live kompilieren kann, was ich außer den Standartkpompilertools noch brauche und wo ich welche Software herbekomme, was ich genau an Paketen installieren muss.


    Gibt es keine Möglichkeit, das System anhand des installierten VDR kompilierbereit zu machen ( apt install "alles was zum kompilieren von $(dpgk -l | grep vdr ) nötig ist ) , dann den aktuellen passenden Plugin Quellcode von "keine was wozu wie passt" laden und kompilieren. Was bei viele anderen Programmen recht Problemlos klappt endet beim VDR jedes mal in Tagelangen Read-Compile-Frustration Horror.


    EDIT : lt. :

    Code
    1. dpkg -l | grep epg
    2. ii vdr-plugin-epgsearch 2.2.0+git20170817-2 amd64 VDR plugin that provides extensive EPG searching capabilities

    ist jetzt eine 2te Version des Plugins installiert worden. Ist das EPG Search Confict Programmteil deaktiviert worden ? Der VDR läuft zwat jetzt ( stabil ??? ) auch mit dem epg search plugin, meldet nur keine Timerkonflikte mehr. Wäre für mich akzeptabe solange der vdr denn endlich stabil läuft und die Suchtimer laufen.

    Grad getestet : In Version :

    Code
    1. show_sources vdr vdr-plugin-epgsearch
    2. vdr | 2.4.0-1+b1 | http://deb.debian.org/debian buster/main amd64 Packages
    3. vdr | 2.4.0-1 | http://deb.debian.org/debian buster/main Sources
    4. vdr-plugin-epgsearch | 2.2.0+git20170817-2 | http://deb.debian.org/debian buster/main amd64 Packages
    5. vdr-plugin-epgsearch | 2.2.0+git20170817-2 | http://deb.debian.org/debian buster/main Sources

    wurde der epg conflict check deaktiviert. Der VDR läuft stabil, Timer etc läuft alles, Timerkonflikte werden ignoriert. Frei nach dem Prinzip " Wer zuerst kommt mahlt zuerst" werden die Timer abgearbeitet.

    Bin mal gespannt ob der VDR länger 1-2 Stunden läuft ....


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 240 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430
    |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info |

    The post was edited 8 times, last by speefak ().

  • Hallo,


    Dann bin ich nach o.g. Anweisungen vorgegangen ( dget -xu https://launchpad.net/~yavdr/+…9ba796-0yavdr0~bionic.dsc )

    => Datei Offline

    da musst du das aktuelle Paket mit "dget -xu" holen.

    Code
    1. https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190919-8-84811de-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic.dsc


    Gruss

    Wolfgang

  • Zum Kompilieren von Plugins benötigst du die Header-Dateien (und pkgbuild-Informationen) der installierten VDR-Version. Die stecken bei den Debian-Paketen seit jeher im Paket vdr-dev, das bei deinem Paketbauversuch auch als fehlend angemeckert wurde.


    Um die Bau-Abhängigkeiten eines Paketes aufzulösen, kannst du entweder einen Blick in debian/control des Quellpakets werfen oder mk-build-deps -i (aus dem devscripts Paket) aufrufen (vgl. https://manpages.debian.org/st…s/mk-build-deps.1.en.html ), das dir ein Paket baut, das die benötigten Build-Dependencies als Abhängigkeiten hat und das Paket zusammen mit diesen installiert.


    Dann solltest du vermeiden die Versionen des VDR und von Plugins durcheinander zu werfen. Wenn epgsearch die Version 2.4.0 hat und der VDR die Version 2.4.1 stört das nicht, solange die API des VDR auf Quellcodeebene noch passt.


    Das virtuelle Paket vdr-abi-<VERSION> ist an das VDR-Paket gebunden (wird über debian/abi-version im Quellpaket für den VDR und https://salsa.debian.org/vdr-t…b/master/debian/rules#L38 f. festgelegt) und Pakete für Plugins, die dagegen gebaut wurden, werden auf exakt diese ABI-Version festgelegt, weil alles andere nicht sicher binärkompatibel wäre. Das hat den (beabsichtigten) Effekt, dass man nicht wahllos Plugins aus anderen Paketquellen installieren kann, sondern sie im Zweifelsfall neu aus den Sourcen bauen muss.

    Intern hängt die ABI aber vor allem von der VDR-Version und den zusätzlich auf den VDR-Quellcode angewendeten Patches ab, daher sollte man die ABI-Version immer ändern, wenn man das VDR-Paket mit ABI-brechenden Änderungen neu baut.


    Ich kann dir nur empfehlen endlich mal die verfügbare Debian-Dokumentation zum Paketbau zu lesen und mit dem Wissen nachzuvollziehen, was in den Quellpaketen für den VDR und der Plugins passiert, statt sich jahrelang immer wieder zu wundern, warum es nicht funktioniert, wenn man versucht Probleme mit blindem Aktionismus zu lösen statt die Problemstellung mal ordentlich durchzuarbeiten und zu verstehen wie das ganze funktioniert.


    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • wie bist du an den Link gekommen ? Unter "https://launchpad.net/~yavdr" fand ich nichts ?!


    funktioniert :

    Code
    1. sudo apt install vdr-dev build-essential devscripts pkg-config libpcre3-dev
    2. sudo apt build-dep vdr-plugin-epgsearch
    3. dget -xu https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190919-8-84811de-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic.dsc
    4. cd vdr-plugin-epgsearch*
    5. dpkg-buildpackage -us -uc
    6. dpkg -i ../vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic_amd64.deb


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 240 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430
    |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info |

  • Zum Kompilieren von Plugins benötigst du die Header-Dateien (und pkgbuild-Informationen) der installierten VDR-Version. Die stecken bei den Debian-Paketen seit jeher im Paket vdr-dev, das bei deinem Paketbauversuch auch als fehlend angemeckert wurde.

    Um die Bau-Abhängigkeiten eines Paketes aufzulösen, kannst du entweder einen Blick in debian/control des Quellpakets werfen oder mk-build-deps -i (aus dem devscripts Paket) aufrufen (vgl. https://manpages.debian.org/st…s/mk-build-deps.1.en.html ), das dir ein Paket baut, das die benötigten Build-Dependencies als Abhängigkeiten hat und das Paket zusammen mit diesen installiert.

    Danke für die Info: mk-build-deps -i <packetname>. Die Installation von vdr-dev als Sourcecodebasis habe ich erfolgreich vorgenommen ( und die der anderen Kompilertools )

    Dann solltest du vermeiden die Versionen des VDR und von Plugins durcheinander zu werfen. Wenn epgsearch die Version 2.4.0 hat und der VDR die Version 2.4.1 stört das nicht, solange die API des VDR auf Quellcodeebene noch passt.

    Das ist mir seit dem letzten Umsteig von Debian 8 auf 9 klar geworden. Darum wunderte ich mich ja über die Angabe des vdr-plugin-epgsearch Quellcodes aus den o.g. Quellen auf Basis des VDR 2.4.0 und dann wurde vdr-dev 2.4.1 statt 2.4.0 verlangt. 2.4.1 ist aber nicht in den Repos verfügbar und bevor ich mein System wieder mit zig Quellen überlade dachte ich mir es muss auch mit vdr-dev 2.4.0 gehen ( was es mit dem Quellcode link von wolfi-m auch tat. ).


    Die Suche nach dem Passenden Quellcode war nicht so einfach.

    Das virtuelle Paket vdr-abi-<VERSION> ist an das VDR-Paket gebunden (wird über debian/abi-version im Quellpaket für den VDR und https://salsa.debian.org/vdr-t…b/master/debian/rules#L38 f. festgelegt) und Pakete für Plugins, die dagegen gebaut wurden, werden auf exakt diese ABI-Version festgelegt, weil alles andere nicht sicher binärkompatibel wäre. Das hat den (beabsichtigten) Effekt, dass man nicht wahllos Plugins aus anderen Paketquellen installieren kann, sondern sie im Zweifelsfall neu aus den Sourcen bauen muss.

    Intern hängt die ABI aber vor allem von der VDR-Version und den zusätzlich auf den VDR-Quellcode angewendeten Patches ab, daher sollte man die ABI-Version immer ändern, wenn man das VDR-Paket mit ABI-brechenden Änderungen neu baut.

    Darum suchte ich ja eine gepachte vdr-plugin-epgsearch Version die kompatibel zum vdr-dev 2.4.0 ist. Und daran scheiterte es dann. Die VDR ABI zu ändern habe ich seit dem letzten update gelernt möglichst zu vermeiden, da in Folge dessen noch mehr Fehler auftraten.

    Ich kann dir nur empfehlen endlich mal die verfügbare Debian-Dokumentation zum Paketbau zu lesen und mit dem Wissen nachzuvollziehen, was in den Quellpaketen für den VDR und der Plugins passiert, statt sich jahrelang immer wieder zu wundern, warum es nicht funktioniert, wenn man versucht Probleme mit blindem Aktionismus zu lösen statt die Problemstellung mal ordentlich durchzuarbeiten und zu verstehen wie das ganze funktioniert.


    Nimm es mir nicht übel aber das habe ich vor knapp 3 Jahren schon einmal gemacht und es klappte auch alles wunderbar - Nur leider ist mein Hirn kein USB Stick oder Kristallspeicher und verliert daher die ein oder andere Information in Abhängigkeit des Faktors Zeit. Analytisch bin vorgegangen, einfach nach dem "Try and Error" Prinzip vorzugehen endet beim Kompilieren meist in Chaos.


    In dem Sinn Danke für Infos.


    EDIT : Ein Test Ergab gerade Folgendes Szenario :


    EPG Konflikte werden genau 1 mal im Live Plugin angezeigt, aktualisiert man den Browser nach der Anzeige wird kein Konflikt mehr angezeigt - Timerkonflikt besteht allerdings weiterhin.


    Klickt man im Live Plugin auf den Timerkonflikt wird dieser nicht angezeigt. DAS fenster und der Header der Liste wird angezeigt, aber nicht der Timerkonflikt selbst.


    Solange der Rest stabil läuft kann ich damit leben.


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver G1610T | 8 GB EEC DDR 1600 | 1 x EVO Pro 240GB, 2x6TB HGST, 2x3 TB WD Red | TBS 6981
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 240 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 9 + Kodi 18 (deb.multimedia Quellen) on | Lenovo T430
    |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info |

    The post was edited 1 time, last by speefak ().