Seltsame Sortierreihenfolge der Aufnahmen (gcc 8.2 ?)

Fourty2 · Dec 17th 2018

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:

Code

recording.c: In member function ‘void cIndexFile::ConvertToPes(tIndexTs*, int)’:
recording.c:2901:52: warning: ‘void* memcpy(void*, const void*, size_t)’ copying an object of non-trivial type ‘struct tIndexTs’ from an array of ‘struct tIndexPes’ [-Wclass-memaccess]
memcpy(IndexTs, &IndexPes, sizeof(*IndexTs));
^
recording.c:2766:8: note: ‘struct tIndexTs’ declared here
struct tIndexTs {
^~~~~~~~
recording.c: In function ‘char* ExchangeChars(char*, bool)’:
recording.c:607:37: warning: ‘char* strncpy(char*, const char*, size_t)’ output may be truncated copying 3 bytes from a string of length 3 [-Wstringop-truncation]
strncpy(p, buf, 3);
~~~~~~~^~~~~~~~~~~

Display More

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

Stefan

kamel5 · Dec 18th 2018

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

Fourty2 · Dec 18th 2018

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

kls · Dec 18th 2018

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

Fourty2 · Dec 18th 2018

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

Code

vdr: [2874] Sort - In  : /Spielfilme/By_the_Sea_#7CSD/2017-08-18.09.54.105-0.rec
vdr: [2874] Sort - Stp : /Spielfilme1By_the_Sea_#7CSD/2017-08-18.09.54.105-0.rec
vdr: [2874] Sort - Rpl : 0Spielfilme1By_the_Sea_#7CSD02017-08-18.09.54.105-0.rec
vdr: [2874] Sort - xf-L: 359
vdr: [2874] Sort - Out : GŉĚµ~Ð^uµÐå~H^ƏŘª~ŉ~QNiŉrGIGHNGOHOGPLKHGLGĬ~i#001#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#001#002#007#002#002#002#002#002#002#002#002#002#002#007#002#002#002#002#007#002#002#002#007#007#007#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#001#001ₛ#001 #001⢇#001⛘#001◿#001❪#001♍#001⛘#001❪#001➮#001◿#001⃤#001⬎#001⩆#001Ǫ#001⥓#001⚣#001◿#001Ǫ#001 #001◿#001┒#001Ǫ#001Ǔ#001⏶#001⬪#001 #001⭋#001ₛ#001↢#001ₛ#001⃤#001⏶#001ǜ#001ₛ#001 #001ǜ#001⃤#001 #001ǝ#001ₛ#001⒴#001ǝ#001⌧#001⊯#001ǝ#001⃤#001ₛ#001⌧#001ǜ#001ₛ#001ǝ#001⣏#001◿#001▒


vdr: [2874] Sort - In  : /Spielfilme/10.000_BC_#7CHL/2018-11-19.09.10.109-0.rec
vdr: [2874] Sort - Stp : /Spielfilme110.000_BC_#7CHL/2018-11-19.09.10.109-0.rec
vdr: [2874] Sort - Rpl : 0Spielfilme110.000_BC_#7CHL02018-11-19.09.10.109-0.rec
vdr: [2874] Sort - xf-L: 349
vdr: [2874] Sort - Out : GŉĚµ~Ð^uµÐå~HHGGGG^iNiªÐGIGHOHHHPGPHGHGPGĬ~i#001#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#001#002#007#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#007#007#002#007#007#007#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#002#001#001ₛ#001 #001⢇#001⛘#001◿#001❪#001♍#001⛘#001❪#001➮#001◿#001⃤#001⃤#001ₛ#001ǝ#001ₛ#001ₛ#001ₛ#001Ǫ#001⬎#001⬪#001Ǫ#001Ǔ#001⏶#001⬪#001⯡#001ⱨ#001ₛ#001↢#001ₛ#001⃤#001 #001ǜ#001⃤#001⃤#001ǜ#001⃤#001⒴#001ǝ#001ₛ#001⒴#001ǝ#001⃤#001ₛ#001ǝ#001⃤#001ₛ#001⒴#001ǜ#001ₛ#001ǝ#001⣏#001◿#001▒

Display More

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

Aber die strxfmt Länge scheint eigenartig, oder?

Stefan

Fourty2 · Dec 19th 2018

Hallo Klaus,

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

Diff

--- a/recording.c
+++ b/recording.c
@@ -30,6 +30,7 @@
#include "svdrp.h"
#include "tools.h"
#include "videodir.h"
+#include <locale.h>


#define SUMMARYFALLBACK


@@ -989,6 +990,8 @@
char *cRecording::SortName(void) const
{
char **sb = (RecordingsSortMode == rsmName) ? &sortBufferName : &sortBufferTime;
+  setlocale(LC_COLLATE, "C");
+
if (!*sb) {
if (RecordingsSortMode == rsmTime && !Setup.RecordingDirs) {
char buf[32];

Display More

Stefan

kamel5 · Dec 19th 2018

Also bei mir sieht das so aus:

Code

[18911] recording.c SortName /Video/video1/Blade/2018-11-28.01.58.100-0.rec
[18911] recording.c SortName /Blade/2018-11-28.01.58.100-0.rec
[18911] recording.c SortName 0Blade12018-11-28.01.58.100-0.rec
[18911] recording.c SortName 209

[18911] recording.c SortName /Video/video1/Æon_Flux_-_Blicke_der_Zukunft_ins_Auge/2018-12-07.22.03.94-0.rec
[18911] recording.c SortName /Æon_Flux_-_Blicke_der_Zukunft_ins_Auge/2018-12-07.22.03.94-0.rec
[18911] recording.c SortName 0Æon_Flux_-_Blicke_der_Zukunft_ins_Auge12018-12-07.22.03.94-0.rec
[18911] recording.c SortName 428

[18911] recording.c SortName /Video/video1/Avengers_Grimm:_Time_Wars/2018-07-26.20.13.99-0.rec
[18911] recording.c SortName /Avengers_Grimm:_Time_Wars/2018-07-26.20.13.99-0.rec
[18911] recording.c SortName 0Avengers_Grimm:_Time_Wars12018-07-26.20.13.99-0.rec
[18911] recording.c SortName 341

Display More

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

kamel5 · Dec 19th 2018

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

seahawk1986 · Dec 19th 2018

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

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

Fourty2 · Dec 19th 2018

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ŉĚµ~Ð^uµÐå~H^ƏŘª~ŉ~QNiŉrGIGHNGOHOGPLKHGLGĬ~i#001#002...<Unsinn>

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

GŉĚµ~Ð^uµÐå~HHGGGG^iNiªÐGIGHOHHHPGPHGHGPGĬ~i#001#002

=> 0Spielfilme1 = GŉĚµ~Ð^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

Fourty2 · Dec 19th 2018

@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

kamel5 · Dec 19th 2018

Quote from Fourty2

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

mini73 · Dec 19th 2018

Im Artikel steht, dass Fedora glibc am 30.10.2018 aktualisiert hat.

Heftige Änderung...

Lars

kamel5 · Dec 19th 2018

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.

Fourty2 · Dec 19th 2018

Ach, ich hatte Tomaten auf den Augen :
0Spielfilme1B = GŉĚµ~Ð^uµÐå~H^

0Spielfilme11 = GŉĚµ~Ð^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

Fourty2 · Dec 19th 2018

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.

Fourty2 · Dec 19th 2018

Offenbar ist strcasecmp nicht UTF-8 fähig.

Diff

--- a/recording.c
+++ b/recording.c
@@ -1035,9 +1043,9 @@
{
cRecording *r = (cRecording *)&ListObject;
if (Setup.RecSortingDirection == rsdAscending)
-     return strcasecmp(SortName(), r->SortName());
+     return strcmp(SortName(), r->SortName());
else
-     return strcasecmp(r->SortName(), SortName());
+     return strcmp(r->SortName(), SortName());
}


bool cRecording::IsInPath(const char *Path) const

Display More

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

kamel5 · Dec 20th 2018

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.

Quote from Fourty2

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

Fourty2 · Dec 20th 2018

Vielleicht hat die debian buster Geschmacksrichtung der locales auch einen Bug.

Stefan

kls · Mar 17th 2019

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

Seltsame Sortierreihenfolge der Aufnahmen (gcc 8.2 ?)

Participate now!

Share