Beiträge von kamel5

    Fourty2

    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:


    Code
    1. LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->timer->Channel()), DAYDATETIME(checkTime->evaltime), device + 1);


    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

    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

    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

    Dateien

    • menu.c.gz

      (40,39 kB, 14 Mal heruntergeladen, zuletzt: )

    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

    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:

    https://projects.vdr-developer.org/git/skin-nopacity.git/

    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.