Beiträge von Fourty2

    Hallo zusammen,


    seit einem Update der MariaDB in debian buster bekommen ich beim epg2vdr compilieren folgenden Fehler:



    Einfach mit "suggested alternative" ersetzen, oder ist da Nacharbeit erforderlich?


    Stefan

    Hallo zusammen,


    hab da noch einen Segfault im epg2vdr, wenn man beim Starten ein paar Tasten zuviel drückt:



    Ideen?


    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

    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

    seahawk1986

    Ja, war definitiv das udev, was wohl im "noch nicht so ganz bereiten" Zustand angesprochen wurde.

    Downgrade auf 239 oder ein Delay im Init-Script behebt das Problem (bei mir).


    Kernel kann ich ausschließen ... wird hier selbst aus dem GIT gebacken und aus eigenem Repository installiert.


    Dies hier halt:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917247


    System ist ein Intel J3160 mit TT-budget S2-4200 Twin - also alles im Kernel 4.19.13.


    Und als aplay -lL "keine Audio Geräte" mehr meldete, war klar, was schief lief.

    Die hätte man sonst vorher aus dem Chipsatz meißeln müssen.


    VDR-Log:



    Stefan

    Hallo zusammen,


    irgendwann lerne ich es noch, das VDR-System nicht mehr zu aktualisieren ... ;-/


    Das Update auf udev 2.40 hat wohl das System zerlegt. In /dev fehlt eigentlich seit Neustart alles, was ein VDR so braucht. Ganz toll.


    Weiß jemand, wo ich mal suchen und reparieren könnte?


    Stefan


    Edit:
    Nach etwas suchen:
    - Das udev startet (bei sysv-init) jetzt per start-stop-manager (aber viel zu früh)
    - Patch gibt es da: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908796

    TomJoad :


    Das muß dem jüngsten Buster glib oder gcc-8.2 Update zusammen hängen. Davor lief epgsearch auch mit 2.4. problemlos. Hab schon bis auf eine Objektkopie alle Warnungen beseitigt, aber das Problem ist mir unklar...


    Macht man die vier Zeilen raus, läuft der Konflikcheck wieder. Mit bekomme ich den VDR nicht mehr hoch.


    Für gcc 8.2.12 hab ich derzeit folgendes drin:


    Sowie:


    Und:



    Die Warnung muß noch:


    Code
    1. blacklist.c: In member function 'cBlacklist& cBlacklist::operator=(const cBlacklist&)':
    2. blacklist.c:105:43: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class cBlacklist' with no trivial copy-assignment; use copy-assignment instead [-Wclass-memaccess]
    3. memcpy(this, &Blacklist, sizeof(*this));
    4. ^
    5. In file included from blacklist.c:26:
    6. blacklist.h:32:7: note: 'class cBlacklist' declared here
    7. class cBlacklist : public cListObject
    8. ^~~~~~~~~~


    Half alles nix -> GPF


    Nur abschalten



    Hilft.


    Kann Dir gerne reincompilieren, was Du an Debug-Ausgaben brauchst...


    Stefan

    Ach sieh an ... den hab ich auch (im Aufnahmen-Sortier-Thread gcc 8.2 / glibc 2.28 kurz erwähnt):

    Backtrace dazu wäre:



    Läuft derzeit auf Custom Kernel 4.19.9, gleich .11 ;)


    Programstelle wäre:

    VDR-Log (Absturz beim Start):

    Code
    1. vdr: [29291] timer 0 (115 1340-1515 'Westworld') set to event Di. 01.01.2019 13:55-15:00 'Westworld'
    2. vdr: [29291] EPGSearch: search timer update finished
    3. vdr: [29291] EPGSearch: check for timer conflicts
    4. <segfault>
    5. vdr: [29337] VDR version 2.4.0 started


    Stefan

    Offenbar ist strcasecmp nicht UTF-8 fähig.




    Mit diesem Patch läufts halbwegs korrekt:


    Auch wenn ich "Mädchen" nicht vor "Mad Max" sortiert hätte, und #9 etwas deplaziert erscheint.


    Für die orginale Vergleichsfunktion müßte man vermutlich zunächst nach wchar konvertieren und dann wcsncasecmp verwenden... wer Lust hat ;)


    Edit:
    Meint http://demo.icu-project.org/ic…ocexp?_=de_DE&d_=de&x=col auch:

    Collated

    04: #9 (0a 8f 24 0)

    03: 22 Jump Street (16 16 04 3b 51 41 47 04 4d 4f 4b 31 31 4f 00)

    02: Mad Max (41 29 2f 04 41 29 57 0)

    01: Mädchen (41 29 2f 2d 37 31 43 00)


    Edit 2:

    Das könnte an den Unterstrichen statt Leerzeichen in den Dateinamen liegen, die müßte man vorher tauschen.



    Stefan

    Oder das hier, namentlich strcasecmp mag mit den komischen Zeichenketten nicht.

    Code
    1. int cRecording::Compare(const cListObject &ListObject) const
    2. {
    3. cRecording *r = (cRecording *)&ListObject;
    4. if (Setup.RecSortingDirection == rsdAscending)
    5. return strcasecmp(SortName(), r->SortName());
    6. else
    7. return strcasecmp(r->SortName(), SortName());
    8. }


    Ich probiere nachher mal strcmp, wenn die Aufnahme durch ist.

    Ach, ich hatte Tomaten auf den Augen ;) :
    0Spielfilme1B = Gʼn̵~Ð^uµÐå~H^

    0Spielfilme11 = Gʼn̵~Ð^uµÐå~HH


    ^ ist 0x5E (für B),

    H ist 0x48 (für 1),

    da ist der Ersatz für "1" offensichtlich kleiner als der Ersatz für "B".


    Da B aber vor 1 landet, muß der Fehler dann danach im VDR auftreten. Mal gucken...

    Stefan