[ANNOUNCE] VDR developer version 1.7.30

Zitat

... dann verbaut man sich alle nachträglichen Korrekturmöglichkeiten.

???

Versteh ich nicht. Lücken sind doch kein Problem. Nur wenn der Überlauf nicht passt, dann laufen Bild und Ton auseinander.
Wenn nach dem Schnitt was standardkonformes rauskommt, können alle Tuhls damit umgehen.
Was willst Du Meer?

Zitat

Das Problem ist einfach das es keine vernünftigen MPEG4 Tools gibt.

Janz jenau.

Wegen SD mach ich mir nicht die Mühe, hier zu schreiben.
Dort habe ich eine funktionierende Tuhltschain, die saubere Ergebnisse liefert. Selbstredend lasse ich kein SD mit Werbeunterbrechung vom VDR schneiden.

Zitat

(Man könnte ja *.ts direkt verlustfrei nach *.mkv/BluRay remuxen) wenn man das doch so einfach in den VDR einbauen könnte

Das ist jetzt aba nimmer nach den Sternen greifen, sondern gleich nach anderen Galaxien.
Nee, also das recodieren muss nicht in den VDR rein.
Dafür gibt es ja ffmpeg, handbrake und Co. Die machen ja auch einen ordentlichen Job, nur sind sie halt ziemlich zickig, was die saubere Quelle angeht.
Letztlich ist es ja x264, welches von beiden verwendet wird.

Weiß nicht, meine Devise ist, am Eingang tolerant zu sein und am Ausgang exakt auf Standards zu achten.
Dann klappt es auch mit den Nachbarn

Gruß Gero

Zitat von Keine_Ahnung

Das Problem ist einfach das es keine vernünftigen MPEG4 Tools gibt.

Ich habe (mittlerweile) mit dem TSDoctor ganz gute Erfahrungen gemacht. Die aktuelle Version ist stabil und schnell.

Zitat von r371769

Ich habe (mittlerweile) mit dem TSDoctor ganz gute Erfahrungen gemacht. Die aktuelle Version ist stabil und schnell.

Nun ja, für Windows gibt es da viele gute Tools.
Ich verwende VideoReDo TV Suite H.264

Zitat von geronimo

???

Versteh ich nicht. Lücken sind doch kein Problem.

Du willst also nach dem Schnitt neu nummerieren. Was machst du denn z.B. wenn mittendrin nen Bild fehlt? So ganz konkret?

Zitat von geronimo

Wenn nach dem Schnitt was standardkonformes rauskommt, können alle Tuhls damit umgehen.
Was willst Du Meer?

Die Frage bleibt, wenn es so einfach wäre das da nach dem Schnitt was standardkonformes rauskommt, warum gibt es dann noch kein Kommandozeilenprogramm welches aus ner VDR Aufnahme was standardkonformes macht? Ich meine da warten alle seit Jahren drauf. Warum hat das noch keiner erstellt wenn man da nur einige Pakete umnummerieren muss?

Das meine: Ich glaube einfach nicht das das alles so einfach ist. Also würde ich es begrüßen wenn der VDR da nicht halbherzig dran rumfummelt im Versuch nen bisschen was hinzufummeln.

Zitat von geronimo

Das ist jetzt aba nimmer nach den Sternen greifen, sondern gleich nach anderen Galaxien.
Nee, also das recodieren muss nicht in den VDR rein.

Nein, nicht recodieren sonder remuxen.

Bei SD MPEG2 kann man durch das simple umsortieren der Bytes aus ner TV Aufnahme verlustfrei ne standardkonforme DVD-Video machen.
Bei einer HD MPEG4 Aufnahme könnte man genauso einfach aus jeder VDR Aufnahme verlustfrei eine standardkonforme BluRay machen.

Das was ja jetzt passiert (Handbrake drüberjagen) ist Murks. Denn das Programm ist für fehlerfreie Streams ausgelegt und nicht für Broadcast Material (wo eben diese "Fehler" normal sind). Genau das selbe Problem haben mencoder und co.
BTW: Mit SD MPEG2 haben sie das selbe Problem, deswegen schickt man ja vorher ProjektX drüber. Das macht aus Broadcast Material fehlerfreie Streams.

Zitat von geronimo

Dafür gibt es ja ffmpeg, handbrake und Co. Die machen ja auch einen ordentlichen Job, nur sind sie halt ziemlich zickig, was die saubere Quelle angeht.

Eben, das sind Schönwetterprogramme und für TV Material absolut ungeeignet. Es fehlt hier einfach so was wie ProjektX für MPEG4 *).

Zitat von geronimo

Weiß nicht, meine Devise ist, am Eingang tolerant zu sein und am Ausgang exakt auf Standards zu achten.

Genau, der Eingang ist die VDR Aufnahme der Ausgang ist BluRay/MKV Also sei beim VDR Format tolerant
Die VDR Aufnahmen sind per Definition nicht fehlerfrei (und zwar immer dann wenn UNC kurzfristig über 0 ist oder wenn der Sender mal Müll baut). Und daran ändert das durchnummerieren an Schnittstellen auch nix. Sie bleiben trotzdem potentiell fehlerhaft. Und üblicherweise reagieren Handbrake und Co. darauf mit weglaufenden Ton.

cu

*) Das es so was für Windows/GUI gibt hilft nix. Wer hat schon Lust wegen nem simplen Export in BluRay/MKV mit der Maus rumzufummeln?

Hallo ..
mal so schnell gefragt ..bei compilieren wirft er mit das Live-Plugin und das Extrecmenu Plugin raus !
Habe den Patch fürs Live Plugin drin, klappt aber nicht habe die ...Git Version !
Und gibts auch schon was für Extrecmenu Plugin ??
Hmm helft bitte einem Dummen
Gruss
speed

Zitat von kls

@so:ren: Anbei eine überarbeitete Version des Patches. Bitte teste mal, ob damit deine Probleme immer noch behoben sind.

Klaus

Habe heute abend zwar nicht ausfuehrlich testen koennen, sieht aber soweit gut aus.
Ich denke, es waere eine gute Idee, das so nach 1.7.31 zu uebernehmen. Ich teste natuerlich weiter, erwarte aber keine Probleme. Falls wider Erwarten doch irgendwas nicht klappt, melde ich mich nochmal...

Vielen Dank,
S:oren

Zitat

Nun ja, für Windows gibt es da viele gute Tools.

Das mag wohl stimmen.
Da ich aber sicher nicht der einzige bin, für den Windows nimmer auf die Kiste kommt, bleibt einfach Handlungsbedarf.

Zitat

Du willst also nach dem Schnitt neu nummerieren.

Nö, da hast Du mich falsch verstanden.
Ich möchte, dass der Schnitt was produziert, was zumindest der Ausgangsqualität entspricht.
Was jetzt gemacht wird ist Murks.

Neu nummerieren ist "per se" nicht notwendig, denn die "Schönwetter"-Tuhls kommen sehr wohl mit Lücken zurecht.

Wo man eingreifen müsste und sollte, ist dort, wo im Geschnittenen ein Überlauf des Zeitstempels erfolgt.
Dazu müsste *imho* reichen, dass man prüft, ob der Zeitstempel nach dem Schnitt kleiner ist, als der Zeitstempel vor dem Schnitt.
Nur dann besteht Handlungsbedarf.

Davon abgesehen ist die Korrektur der Zeitstempel nur ein Punkt von mehreren.

Zitat

Was machst du denn z.B. wenn mittendrin nen Bild fehlt? So ganz konkret?

Garnix, wieso?
Damit hat doch niemand ein Problem?!?
Audio und Video haben jeweils einen Zeitstempel, sodass man den Versatz bestimmen und zusammen gehörende Pakete infizieren kann.
Wenn der Fall vorkommen sollte, dass ein Bild fehlt und die Audiospur komplett wäre, dann schlägt sich das ja in den Zeitstempeln wieder.
Ich sehe kein Problem, das nicht deterministisch gelöst werden könnte.

Bei ffplay (dem Beispielplayer von ffmpeg) ist ein gutes Beispiel für das Sychronisieren von Streams. Auch wenn mplayer und Co davon abstammen, haben die Entwickler die Synchronisierung wohl für Overkill gehalten und was einfacheres/eigenes gestrickt.
Anders kann ich es mir nicht erklären, dass das einfache Beispielproggy der einzige Player ist, der in meiner HW-Konstellation alle möglichen Materialien korrekt abspielt.
Im Gegensatz zu den etablierten Größen kommt es bei ffplay auch beim fehlerhaften Schnitt des VDR nicht zum Auseinanderdriften von Ton und Bild.

Zitat

Die Frage bleibt, wenn es so einfach wäre das da nach dem Schnitt was standardkonformes rauskommt ...

Ich habe nie behauptet, dass es einfach wäre.
Ich habe nur eine Vermutung geäußert, dass der VDR bereits alle möglichen Probleme gelöst hat.
Die Lösungen werden zwar an anderen Ecken eingesetzt, nicht jedoch beim Schnitt.

Zitat

Nein, nicht recodieren sonder remuxen.

Wie gesagt, es geht nicht darum, nur neu zu nummerieren. Die Korrektur der Zeitstempel ist nur ein Punkt.

Was ich als richtig ansehe ist die Betrachtung der Container und Streams als das was sie sind.
Beim Schnitt müsste jeder Stream getrennt betrachtet und behandelt werden, was zu einer "diffusen" Schnittmarke führen würde.
Denn jede Tonspur ist sicher an einer anderen Position zu schneiden, wie Bilder und sonstiges Streams.

Der Ansatz des VDR, vom Bild auszugehen ist völlig richtig.
Nur sollte man an der Schnittmarke nach beiden Seiten übern Tellerrand schauen, um die passenden Pakete zu diesem Bild zu finden.

Der Versatz der jeweiligen Streams dürfte bei der zweiten Schnittmarke ja ähnlich liegen, sodass Lücken wieder aufgefüllt werden könnten. Damit wäre ein remuxen des Materials zwischen den Werbepausen nicht erforderlich und der remux-Aufwand reduziert sich auf eine gezielte Betrachtung rund um die Schnittmarken.
Das wäre jedenfalls mein Ziel. Evtl. ist der Einsatz von Nalu-Paketen notwendig - aber das gibt der Standard ja auch her.

Was dann noch dazu käme, wäre die Betrachtung der Zeitstempel.
Wenn der Zeitstempel nach dem Schnitt über dem Zeitstempel vor dem Schnitt liegt - ist ja alles gut - und es gibt keinen Handlungsbedarf.
Andernfalls müssten die Streams neu "nummeriert" werden.

Ich würde dazu die Differenz der Bilder als Maßzahl nehmen und alle Pakete um diese Maßzahl korrigieren. Damit würden alle möglichen Lücken gleich mit behandelt werden.
Das gilt bis zur nächsten Schnittmarke. Dann muss die Differenz entsprechend angepasst werden.

Zitat

Genau, der Eingang ist die VDR Aufnahme der Ausgang ist BluRay/MKV

Lach - ja das wäre ein Traum.
Aber da müssen wir noch ein paar Rechnergenerationen warten.

Denn BluRay/MKV bedeutet nicht nur einen anderen Container zu produzieren, sondern evtl. auch die Streams recodieren.
Das ist ein Job, den ich nicht beim VDR sehe.
Aber ok, es gibt ja auch viele Anwender, die das DVD-Plugin verwenden.
Ist für mich auch keine Aufgabe, die der VDR bewältigen muss.

Nein, TS-Container sind ein Standard, genau wie die darin enthaltenen PES-Ströme.
Wenn nach dem Schnitt das Ergebnis wieder dem gleichen Standard entspricht, dann wäre ich glücklich und zufrieden.
Ich muss nicht Äpfel mit Birnen vergleichen.

Zitat

Und daran ändert das durchnummerieren an Schnittstellen auch nix. Sie bleiben trotzdem potentiell fehlerhaft. Und üblicherweise reagieren Handbrake und Co. darauf mit weglaufenden Ton.

Hm, das kann ich jetzt so nicht bestätigen.
Dann wäre es ja auch nicht möglich, die ungeschnittene Aufnahme zu verarbeiten - was aber durchaus funktioniert.
Soweit ich beobachten konnte, sind die völligen Fehlverhalten anderer Tuhls immer auf die Schnittmarke zurück zu führen.
Was nicht heißen soll, dass es nicht noch andere Fehlerquellen gibt.

Gruß Gero

Zitat von kls

Kann schon sein, daß das unsägliche UTF-8 da wieder Quatsch macht.
Werd's mir anschauen.

Also ganz so einfach geht's wohl nicht. Das mit dem 'z' funktioniert nur so lange, wie kein Verzeichnis mit einem Umlaut oder einem anderen Nicht-ASCII-Zeichen beginnt. Im Falle von UTF-8 muß wohl statt eines einfachen 0xFF das größtmögliche UTF-8-Zeichen "\xF7\xBF\xBF\xBF" eingefügt werden.
Ich könnte mir das so vorstellen:

--- recording.c 2012/09/17 08:54:00     2.62
+++ recording.c 2012/09/25 10:00:56
@@ -821,8 +821,32 @@
         }
   if (s1 && s2) {
      s1++;
-     memmove(s1, s2, t - s2 + 1);
-     *s1 = 0xFF; // sorts folders before plain recordings
+     if (cCharSetConv::SystemCharacterTable()) {
+        // single byte characters - life is good!
+        memmove(s1, s2, t - s2 + 1);
+        *s1 = 0xFF; // sorts folders before plain recordings
+        }
+     else {
+        // in case of UTF-8 we need to insert the highest possible UTF-8 character:
+        static const char *HighestUtf8Char = "\xF7\xBF\xBF\xBF";
+        static const int HighestUtf8CharLen = strlen(HighestUtf8Char);
+        int d = s2 - s1 + 1; // the available space
+        if (d < HighestUtf8CharLen) {
+           // we need more space:
+           if (char *p = (char *)realloc(s, strlen(s) + HighestUtf8CharLen - d + 1)) {
+              s1 = p + (s1 - s);
+              s2 = p + (s2 - s);
+              s = p;
+              memmove(s1 + HighestUtf8CharLen - 1, s2, strlen(s2) + 1);
+              s2 = s1 + HighestUtf8CharLen - 1;
+              }
+           else
+              return s; // just bail out
+           }
+        else if (d > HighestUtf8CharLen)
+           memmove(s1 + HighestUtf8CharLen - 1, s2, t - s2 + 1);
+        memcpy(s1, HighestUtf8Char, HighestUtf8CharLen); // sorts folders before plain recordings
+        }
      }
   return s;
 }

Da mein Filesystem kein UTF-8 verwendet kann ich das hier allerdings nicht testen.
Es müsste also bitte mal jemand mit UTF-8-Filesystem ausprobieren. Insbesondere mit Verzeichnissen, die z.B. mit Umlauten beginnen, und/oder kürzer/länger/gleich 4 Zeichen sind.
Es sind natürlich auch alle anderen eingeladen, den Patch korrekturzulesen, denn mit den ganzen +/-1 und so weiter kann man schon mal durcheinanderkommen Das Ganze ist, wie gesagt, bis auf den "single byte characters"-Zweig, völlig ungetestet. Also VORSICHT!

Klaus

Zitat von kls

Da mein Filesystem kein UTF-8 verwendet kann ich das hier allerdings nicht testen.
Es müsste also bitte mal jemand mit UTF-8-Filesystem ausprobieren. Insbesondere mit Verzeichnissen, die z.B. mit Umlauten beginnen, und/oder kürzer/länger/gleich 4 Zeichen sind.

Habs getestet, klappt so noch nicht.
Mit meiner 'z'-Variante werden alle Verzeichnisse richtig vor einfache Aufnahmen sortiert, auch welche, die mit Umlauten anfangen. Faengt es z.B. mit Ö an, wird es einfach bei O einsortiert, soweit schoen. Auch zwischen Klein- und Grossbuchstaben wird nicht unterschieden. Sonderzeichen wie + oder = am Anfang scheinen ignoriert zu werden, es wird nach den weiteren Zeichen sortiert. Heisst das Verzeichnis allerdings zz kommt es ganz ans Ende hinter einfache Aufnahmen, das ist natuerlich falsch.

Mit der aufwendigen max-utf-8-Variante landen alle Verzeichnisse am Ende hinter den einfachen Aufnahmen, ist also irgendwie ganz falsch.

Insbesondere weil Sonderzeichen komplett ignoriert werden, scheint hier mehr Magie als einfaches Sortieren am Werk zu sein...

Gruss,
S:oren

Zitat von S:oren

Insbesondere weil Sonderzeichen komplett ignoriert werden, scheint hier mehr Magie als einfaches Sortieren am Werk zu sein...

Da spielt LC_COLLATE mit rein ...

Zitat von S:oren

Habs getestet, klappt so noch nicht.
Mit meiner 'z'-Variante werden alle Verzeichnisse richtig vor einfache Aufnahmen sortiert, auch welche, die mit Umlauten anfangen. Faengt es z.B. mit Ö an, wird es einfach bei O einsortiert, soweit schoen. Auch zwischen Klein- und Grossbuchstaben wird nicht unterschieden. Sonderzeichen wie + oder = am Anfang scheinen ignoriert zu werden, es wird nach den weiteren Zeichen sortiert. Heisst das Verzeichnis allerdings zz kommt es ganz ans Ende hinter einfache Aufnahmen, das ist natuerlich falsch.

Mit der aufwendigen max-utf-8-Variante landen alle Verzeichnisse am Ende hinter den einfachen Aufnahmen, ist also irgendwie ganz falsch.

Kannst du es bitte mal mit

static const char *HighestUtf8Char = "\xEF\xBF\xBF";

probieren?

Klaus

Zitat von kls

Kannst du es bitte mal mit

static const char *HighestUtf8Char = "\xEF\xBF\xBF";

probieren?

Leider unveraendert, alle Verzeichnisse hinter normalen Aufnahmen.

Gruss,
S:oren

Warum überhaupt dieser "Zeichen-Hack"? Es sollte doch auch möglich sein, beim Sortieren einfach mit einzubeziehen ob es sich nun um ein Verzeichnis oder eine Aufnahme handelt. Bin kein C++-Profi, aber unter Perl habe ich genau das schon erfolgreich gemacht. Ich kann mir nicht vorstellen, dass sowas unter C++ nicht auch machbar ist.

Zitat von Mreimer

Warum überhaupt dieser "Zeichen-Hack"? Es sollte doch auch möglich sein, beim Sortieren einfach mit einzubeziehen ob es sich nun um ein Verzeichnis oder eine Aufnahme handelt. Bin kein C++-Profi, aber unter Perl habe ich genau das schon erfolgreich gemacht. Ich kann mir nicht vorstellen, dass sowas unter C++ nicht auch machbar ist.

Genau dafür war eigentlich das ursprüngliche 0xFF gedacht - und es funktioniert ja auch bei "single byte characters".
Wie hast du das denn unter Perl gemacht?

Klaus

Routine hänge ich gerne heute Abend hier an. Bin aktuell nicht an dem System, auf dem das entsprechende Script liegt.

In Perl funktioniert Sortieren mit einer "Callback-Funktion":

http://perldoc.perl.org/functions/sort.html

Perl ruft diese während des Sortierens wiederholt auf und übergibt die zwei Elemente, die gerade sortiert werden sollen. Die Funktion sagt dann sowas wie "A muss vor B", "A muss nach B" oder "kann so bleiben wie's ist".

In meinem Callback prüfe ich nun ob A und B von unterschiedlichem Typ sind (eines von beiden ist Verzeichnis und eines von beiden ist eine Datei). Wenn dem so ist, dann liefere ich, abhängig davon, wie ich sortieren will, an Perl zurück, dass die Datei entweder vor oder nach das Verzeichnis soll. Wenn beide vom gleichen Typ sind, dann mache ich einen "alphabetischen Vergleich" (cmp-Operator) um alphabetisch zu sortieren. Ergebnis ist, dass ohne Hacks und Tricks die Verzeichnisse und die Dateien gruppiert werden aber dennoch in jeder Gruppe eine alphabetische Reihenfolge herrscht.

Zitat von Mreimer

Routine hänge ich gerne heute Abend hier an. Bin aktuell nicht an dem System, auf dem das entsprechende Script liegt.

In Perl funktioniert Sortieren mit einer "Callback-Funktion":

http://perldoc.perl.org/functions/sort.html

Perl ruft diese während des Sortierens wiederholt auf und übergibt die zwei Elemente, die gerade sortiert werden sollen. Die Funktion sagt dann sowas wie "A muss vor B", "A muss nach B" oder "kann so bleiben wie's ist".

In meinem Callback prüfe ich nun ob A und B von unterschiedlichem Typ sind (eines von beiden ist Verzeichnis und eines von beiden ist eine Datei). Wenn dem so ist, dann liefere ich, abhängig davon, wie ich sortieren will, an Perl zurück, dass die Datei entweder vor oder nach das Verzeichnis soll. Wenn beide vom gleichen Typ sind, dann mache ich einen "alphabetischen Vergleich" (cmp-Operator) um alphabetisch zu sortieren. Ergebnis ist, dass ohne Hacks und Tricks die Verzeichnisse und die Dateien gruppiert werden aber dennoch in jeder Gruppe eine alphabetische Reihenfolge herrscht.

Alles anzeigen

OK, das ist mir schon klar. Das Problem ist halt, daß ich an dieser Stelle nur Strings habe, und das letztlich alles Verzeichnisse sind.
Wenn nach Zeit sortiert wird, dann wird aus den vollen Pfadnamen der Aufnahmen der Anteil des "Episodennamens" (also der letzte Verzeichnisname vor z.B. "2012-05-22.18.24.1-0.rec") entfernt. Somit wird z.B.

/Wissen/Irgendwas/2012-08-04.04.15.7-0.rec
/Wissen/Sammlung/Was_anderes/2012-09-10.01.40.6-0.rec

zu

/Wissen//2012-08-04.04.15.7-0.rec
/Wissen/Sammlung//2012-09-10.01.40.6-0.rec

Um nun sicherzustellen, daß die Einzelaufnahme "Irgendwas" nach dem Verzeichnis "Sammlung" einsortiert wird, habe ich die Slashes vor den eigentlichen Verzeichnisnamen durch 0xFF ersetzt, was schließlich zu

/Wissen/\xFF2012-08-04.04.15.7-0.rec
/Wissen/Sammlung/\xFF2012-09-10.01.40.6-0.rec

führt. Da '\xFF' größer als 'S' (und auch jedes andere Zeichen) ist, erfolgt die Sortierung wie gewünscht.
Mit UTF-8 funktioniert das aber anscheinend nicht, selbst wenn statt '\xFF' das größtmögliche UTF-8-Zeichen ('\xF7\xBF\xBF\xBF' oder \xEF\xBF\xBF) genommen wird.

Klaus

Ja, es sind nur Strings. Dennoch spricht aber doch nichts dagegen, dass ein "Such-Callback" hier etwas konkreter auf das eingeht, was zu sortieren ist.

Zitat

Um nun sicherzustellen, daß die Einzelaufnahme "Irgendwas" nach dem Verzeichnis "Sammlung" einsortiert wird, habe ich die Slashes vor den eigentlichen Verzeichnisnamen durch 0xFF ersetzt, was schließlich zu

/Wissen/\xFF2012-08-04.04.15.7-0.rec
/Wissen/Sammlung/\xFF2012-09-10.01.40.6-0.rec

Im Callback: "Wenn Verzeichnis nach meinem Basis-Verzeichnis nicht auf ".rec" endet, dann hochsortieren". Gerne auch irgendwie anders. Was ich ausdrücken will: Mit einem Callback könnte man konkrete Suchregeln umsetzen ohne vorher irgendwie die Strings zu verpfuschen, dass eine lineare "Sortiere nach Alphabet-Funktion" so arbeitet wie man das gedacht hat.

Auch das "Rauslassen des Episodennamens" kann dann entfallen, wenn man die Sortierregel nur konkret genug programmiert.

Im Idealfall wird die Aufnahmeliste dann immer durch ein und dasselbe Callback gewurstet und je nachdem was der Benutzer für Sortierregeln festgelegt hat, reagiert das Callback entsprechend.

Edit: Wenn du mir eine Liste Strings gibst und kurz dazuschreibst, wie du die sortiert haben willst, dann baue ich dir aber später gerne auch ein kleines Perl-Script, dass die Sortierung genau so über ein Callback der "sort"-Funktion durchführt.

Zitat von Mreimer

Ja, es sind nur Strings. Dennoch spricht aber doch nichts dagegen, dass ein "Such-Callback" hier etwas konkreter auf das eingeht, was zu sortieren ist.

Im Callback: "Wenn Verzeichnis nach meinem Basis-Verzeichnis nicht auf ".rec" endet, dann hochsortieren". Gerne auch irgendwie anders. Was ich ausdrücken will: Mit einem Callback könnte man konkrete Suchregeln umsetzen ohne vorher irgendwie die Strings zu verpfuschen, dass eine lineare "Sortiere nach Alphabet-Funktion" so arbeitet wie man das gedacht hat.

Ich würde es halt gerne vermeiden, in der Sort-Callback-Funktion (cRecording::Compare()) immer wieder die Strings abzusuchen. Die richtige Sortierreihenfolge ergibt sich völlig automatisch, wenn man an geeigneter Stelle ein "großes" Zeichen einfügt. Das sollte doch auch mit UTF-8 möglich sein...

Klaus

Zitat

Ich würde es halt gerne vermeiden, in der Sort-Callback-Funktion (cRecording::Compare()) immer wieder die Strings abzusuchen.

Wenn's nur darum geht, könntest Du den Verzeichnissen einfach ein Leerzeichen voran stellen.
Das sollte bei allen Codepages klappen.

Gruß Gero

int cRecording::Compare(const cListObject &ListObject) const
{
  cRecording *r = (cRecording *)&ListObject;
  return strcasecmp(SortName(), r->SortName());
}

Ist aber eine normale ASCII String Compare Funktion.
Bei signed chars ist aber 0x7f das größte Zeichen und nicht 0xff.
Vielleicht sollte man strcoll nehmen, arbeitet mit der akutellen Locale.
Wobei ich auf die Schnelle auch nichts über Unicode gefunden haben.

Johnss