Seltsame Sortierreihenfolge der Aufnahmen (gcc 8.2 ?)

  • Hallo zusammen,


    nachdem ich die VDR + Pluginsammlung gestern mal neu mittels gcc 8.2 übersetzt habe, sortiert mein VDR die Aufnahmen eigenwillig. Im Live-Plugin ist es noch normal. Siehe hier:


    Das VDR'li fängt - aus unbekannten Grunde - mit "B" an, dann Zahlen, aber nicht alle, dann gehts mit C weiter...


    Das einzige, was der Compiler zu Thema bewarnt, war:



    Aber... das kann es ja eigentlich nicht sein, oder?

    Stefan

  • Das Verhalten kann ich bestätigen. Ob es am GCC (Bei mir im Moment auch 8.2.1) liegt, kann ich jetzt so nicht sagen. Auf jeden Fall ist es bei mir schon länger so, und ich habe es auch nur durch Zufall gemerkt, da ich meist nach Zeit sortiere.

    Es tritt auch schon mit VDR-2.2.0 auf und auch beim ungepatchten VDR.

    Seltsam ist schon, das es nur beim VDR auftritt, kein anderes Programm zeigt diesen Effekt.

    kls Vielleicht hast Du ja eine Idee dazu.


    Grüsse

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Denke schon, daß es der Compiler ist..

    Das epgsearch hat es dann auch mit erlegt:

    Code
    Dec 18 22:06:38 roadrunner vdr: [10054] EPGSearch: search timer update finished
    Dec 18 22:06:38 roadrunner vdr: [10054] EPGSearch: check for timer conflicts
    Dec 18 22:06:38 roadrunner kernel: [23469.908546] traps: EPGSearch: sear[10054] general protection ip:7f512c6451de sp:7f5129179b10 error:0 in libvdr-epgsearch.so.2.4.0[7f512c62e000+92000]
    Dec 18 22:06:38 roadrunner lircd-0.10.1[2248]: Info: removed client
    Dec 18 22:06:38 roadrunner lircd-0.10.1[2248]: Info: closing '/dev/input/event16'
    Dec 18 22:06:38 roadrunner runvdr: restarting VDR



    So ganz langsam reicht mir die "Kaputt-Verbesserei" aka deprecated :-/

    Stefan

  • Zu den Warnungen in recording.c:


    Zeile 2901 sieht bei mir in VDR 2.4.0 so aus:

    FileName::~cFileName()

    also handelt es sich wohl um eine gepatchte Version.


    Die memcpy()-Stelle hat nur mit dem Index zu tun, kann also an der falschen Sortierreihenfolge nicht schuld sein.


    Ich glaube zwar nicht, dass die strncpy()-Stelle etwas damit zu tun hat, aber um das auszuschließen wäre es zunächst interessant zu wissen, ob beim Start von VDR die Option --dirnames oder --vfat angegeben wurde.


    Am besten baut ihr mal in der Funktion cRecording::SortName() (in recording.c) ein paar Debug-Ausgaben ein um zu sehen, welche Namen da für die Sortierung erzeugt werden.


    Klaus

  • Hallo Klaus,


    ja, ist gepatched. Ist aber auch ohne Patche (bis auf Deine) kein Unterschied - sonst wäre es ja zu einfach.


    Dirname ist "--dirnames=4095,255,1"
    Vfat macht ja die letzte 1.

    Bis vor ein paar Tagen - mit noch nicht gcc 8.2 - paßte es ja immer. Und da das hier über die Paketverwaltung läuft, sollte sich da auch sonst nichts geändert haben.


    Zum Bild oben: By the Sea, danach 10.000 BC



    Sieht erstmal gut aus -- 0Spielfilme11 sollte kleiner als 0Spielfilme1B sein.

    Aber die strxfmt Länge scheint eigenartig, oder?


    Stefan

    3 Mal editiert, zuletzt von Fourty2 () aus folgendem Grund: Debug-Infos (mit Problem?)

  • Hallo Klaus,


    mit diesem Patch - also locale = "C" funktioniert es wieder. Es ist also vermutlich ein de_DE.UTF-8 Problem, das irgendwo schlummert...




    Stefan

  • Also bei mir sieht das so aus:

    Hier noch die Anzeige dazu:




    Verzeichnisse sind auch betroffen:





    -dirnames habe ich nicht gesetzt, ist also default und Locale ist de_DE.UTF-8


    Ich habe das Verhalten auch nochmal mit dem alten extrecmenu-plugin (das bringt eine eigene Sortierfunktion mit) getestet, und das verhält sich jetzt auch so.

    Also möglicherweise doch gcc.


    Fourty2 :

    EPGSearch macht bei mir keine Probleme mit dem neuen gcc.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Das hat sich wohl gerade überschnitten.


    Ich habe das setlocale(LC_COLLATE, "C"); jetzt auch mal eingebaut und es sieht schon Anders aus, aber immer noch nicht 100% richtig.




    Wie man sieht tauchen die geschnittenen Aufnahmen dann ganz unten auf, vorher waren sie einsortiert.

    Und das mit dem AE gehört eigentlich auch eher zum A und nicht ans Ende.


    Grüße

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Sicher, dass das an gcc statt an der glibc 2.28 hängt?

    https://postgresql.verite.pro/…/08/27/glibc-upgrade.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • kamel5:

    Ist jetzt halt "C" Sortierung. Es ging auch nur um den Urheber der Probleme.

    Du siehst ja, daß das, was aus der strxfrm Funktion rausfällt, nicht paßt:
    0Spielfilme1By_the_Sea_#7CSD02017-08-18.09.54.105-0.rec
    Gʼn̵~Ð^uµÐå~H^ƏŘª~ʼn~QNiʼnrGIGHNGOHOGPLKHGLGĬ~i#001#002...<Unsinn>


    0Spielfilme110.000_BC_#7CHL02018-11-19.09.10.109-0.rec

    Gʼn̵~Ð^uµÐå~HHGGGG^iNiªÐGIGHOHHHPGPHGHGPGĬ~i#001#002


    => 0Spielfilme1 = Gʼn̵~Ð^uµÐå~H .... 0.rec = GĬ~i


    Aber ^ = 0x5E (für B), H = 0x48 (für 1) paßt nicht, da 0x5e nicht kleiner 0x48...

    Und schon ist's durcheinander...

    Stefan

  • @seahawk1986:

    Das hatte ich auch schon gefunden.

    Dabei war es wohl:


    Start-Date: 2018-12-16 11:47:35

    Commandline: apt upgrade

    Install:

    [..]

    cpp-8:amd64 (8.2.0-9, 8.2.0-12),

    gcc-8-base:amd64 (8.2.0-9, 8.2.0-12),

    libc6:amd64 (2.27-8, 2.28-2),

    libc-l10n:amd64 (2.27-8, 2.28-2),

    locales:amd64 (2.27-8, 2.28-2)
    [..]


    Stefan

  • Ist jetzt halt "C" Sortierung. Es ging auch nur um den Urheber der Probleme.

    Schon klar, wollte halt nur zeigen, wie es sich hier auswirkt.



    Bei mir ist übrigens glibc 2.28-26.fc29 aktiv.

    Da ich das Problem allerdings schon vor einigen Monaten mal bemerkt habe, ohne das weiter zu verfolgen, stellt sich die Frage, ob es tatsächlich daran liegen kann.

    Ich weiß allerdings nicht mehr wann Fedora, das ich hier nutze, glibc 2.28 ausgeliefert hat.


    Grüße

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • OK, das war ja noch zu Fedora 28 Zeiten.

    Obwohl ich immer noch denke, das ich das schon vorher mal beobachtet habe.

    Aber egal, das lässt sich wohl jetzt nicht mehr ohne größeren Aufwand reproduzieren.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • 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

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

    Code
    int cRecording::Compare(const cListObject &ListObject) const
    {
    cRecording *r = (cRecording *)&ListObject;
    if (Setup.RecSortingDirection == rsdAscending)
    return strcasecmp(SortName(), r->SortName());
    else
    return strcasecmp(r->SortName(), SortName());
    }


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

  • 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

  • Ich habe den strcasecmp jetzt auch mal gegen strcmp getauscht. Damit sieht die Sortierung sehr viel besser aus.

    Es gibt damit keinen erkennbaren Unterschied bei der Sortierung in anderen Bereichen des Alphabets, auch nicht bei einzelnen Differenzen hinsichtlich Groß/Kleinschreibung im Namen. Einzig die Sortierung der Zahlen und der Buchstaben A-C passt jetzt wieder. Also so, wie man es erwarten würde.


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

    Bei mir wird ä nach dem a einsortiert und #9 steht auch an der richtigen Stelle.


    Warum bei dieser Sortierung strcasecmp benutzt werden müsste, möglicherweise wegen der Option -vfat oder wegen anderer locale , kann sicher nur kls sagen.


    Ich werde das auf jeden Fall jetzt erst einmal so lassen und beobachten, ob sich damit irgendwelche Probleme bei mir zeigen.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich würde mal sagen, strcasecmp() durch strcmp() zu ersetzen ist richtig.

    Mit strxfrm() werden die Namen ja schon Locale-abhängig zur Sortierung vorbereitet, und zum Locale gehört auch, ob Groß-/Kleinschreibung beim Sortieren ignoriert wird.


    Klaus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!