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:
kamel5
Hallo,
da hier schon mehrfach über Probleme mit dem Undelete-plugin berichtet wurde, will ich doch mal einen Patch für den Core-VDR bereitstellen, der die Undelete-Funktion direkt im Aufzeichnungsmenü bereitstellt und den ich schon seit einiger Zeit bei mir ohne Probleme benutze.
Wie funktioniert das:
Solange keine gelöschten Aufnahmen vorliegen, ändert sich im Aufzeichnungsmenü nichts.
Sobald gelöschte Aufnahmen vorliegen, übernimmt die sowieso schon mit mehrfacher Funktion belegte rote Taste das Umschalten in den Undelete-Modus.
Zurück aus dem Undelete-Modus kommt man wieder mit der roten Taste (auch aus jedem Unterordner sofort) oder ganz normal wie aus jedem Unterordner mit der Zurück-Taste.
Im Undelete-Modus stehen die Funktionen Undelete, Löschen (entgültiges Löschen) und Info zur Verfügung.
kamel5
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
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.
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
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
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
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
Für VDR 2.4.0 braucht es keinen Patch fürs DVD-Plugin.
Bei mir sind die letzten Änderungen schon länger her und es lässt sich mit VDR-2.4.0 immer noch benutzen.
Ich verwende Device-Bonding und als Mieter habe ich keine Möglichkeit auf Unicable umzustellen.
Ist hier bei mir genau so.
Device-Bonding würde ich ganz stark vermissen.
Wenn ich following = NULL; im constructor von cNopacityView einfüge ist das Problem behoben.
Das hatte ich wohl vergessen.
Ich habe die Initialisierung jetzt mal in cNopacityDisplayChannel untergebracht, wo auch present = NULL; steht.
Anbei ein aktueller Gesamtpatch bezogen auf den letzten Git-Stand. Alle anderen Patches bitte ignorieren.
Gruß
kamel5
Sehr seltsam, das Ganze. Und Du bist Dir auch sicher, das Du das richtige vdr-Binary benutzt?
Was machst Du genau, wenn dieser Report kommt?
Normalerweise wird dieser Code ja nur benutzt bei der Kanalanzeige. Also beim Drücken der OK-Taste bei Live-TV, oder beim Kanalumschalten. Tritt es dann immer auf?
Ich habe diese Meldung nur ohne den Patch von Klaus. Mit Patch kann ich das nicht nachvollziehen.
Gruß
kamel5
...cDisplayChannel::ProcessKey(eKeys) at menu.c:4902 ist bei Dir im Code die Zeile 30.
Zeile 4902 entspricht Zeile 30. Das wäre soweit OK.
Wenn Du aber in Deiner Meldung das folgende anschaust:
May 22 19:23:31 matrix-vdr vdr: [456] /usr/lib/vdr/plugins/libvdr-skinnopacity.so.2.4.0 cNopacityDisplayChannel::Flush() at displaychannel.c:140
May 22 19:23:31 matrix-vdr vdr: [456] /usr/bin/vdr cDisplayChannel::ProcessKey(eKeys) at menu.c:4902
bedeutet das, das cNopacityDisplayChannel::Flush() in menu.c:4902 aufgerufen wird, und das kann eigentlich nicht sein, denn das displayChannel->Flush() in menu.c steht in Zeile 4901. Da passt irgendwie was nicht zusammen.
Ich habe mal die gepatchte menu.c hier angehängt, Du kannst mal vergleichen, ob Deine damit identisch ist.
Gruss
kamel5
Nur für den Fall - hier die Reihenfolge:
Ja, so war es gedacht.
Die Fehlermeldung ist auch eine andere, als wie im Post1
Ja, das ist die erwartete Fehlermeldung ohne den Patch von Klaus.
Was mich wundert ist:
May 22 19:23:31 matrix-vdr vdr: [456] /usr/bin/vdr cDisplayChannel::ProcessKey(eKeys) at menu.c:4902
Das sollte eigentlich Zeile 4901 sein...
Die Funktion an der gepatchten Stelle muss so aussehen:
Bitte nochmal prüfen, sonst habe ich da auch keine Idee mehr dazu.
Gruss
kamel5
Bekommt das noch jemand?
Genau dieser "invalid lock sequence report" sollte mit dem letzten Patch von Klaus Geschichte sein.
Also, nochmal prüfen, ob alles richtig gepatcht, übersetzt und neu installiert wurde.
Fehlt jetzt noch der Patch von Klaus (den es vielleicht noch nicht gibt) oder habe ich etwas übersehen?
Hier:
gibt es diesen Patch.
Alle Anderen in dem Thread sollten aber auch angewendet werden.
Gruss
kamel5
Ich habe die Anzeige des "Rec"-Symbols am Event noch etwas optimiert. Das Symbol sollte ja eigentlich nur angezeigt werden, wenn der Timer zum Event gehört und nicht wenn der folgende Event in die Nachlaufzeit eines Timers fällt.
Den beigefügten Patch bitte zusätzlich zu den Anderen anwenden.
Gruss
kamel5
Mit diesem Patch (skinnopacity-timer.diff) baut er nicht unter Arch,
Was wäre denn die Fehlermeldung?
OK, das mit den Patches ist wohl etwas unübersichtlich, hier also nochmal ein Gesamtpatch bezogen auf den letzten Stand von hier:
Mit beigefügtem Patch und dem von Klaus angekündigten Patch bezüglich Flush sollten die oben genannten "invalid lock sequence report" behoben sein.
Ausserdem wird mit Patch das "Rec"-Symbol bei den Events nur noch angezeigt, wenn ein Timer aktiv ist.
Dieser Patch ist zusätzlich zu den Anderen anzuwenden.
So, noch eine Anpassung:
Da es Fedora wie üblich nicht schafft, das Source-Paket zeitlich passend zum Kernel-Update im Repo bereit zu stellen,
z.B. anstatt:
dnf download --source kernel-4.16.3-200.fc27.src.rpm
das
koji download-build --arch=src kernel-4.16.3-200.fc27
benutzen.
Gruss
kamel5
