Posts by kamel5

    Wegen dem roten Kreis: Tatsächlich sind kleine Fehlerzahlen häufig, und auch nicht praxisrelevant.

    Wir könnten z.B. bei 0-50 Fehlern einen grünen Kreis mit Rufezeichen anzeigen.

    Ich nutze Live zwar nicht, habe aber die Fehleranzeige in Skins auch eingebaut.


    Man sollte hier bedenken, das es egal ist, wie viele Fehler auftreten, den auch 1 Fehler kann mitten in einer Aufnahme deutliche Bildstörungen hervorrufen.

    Wenn man dann die Aufnahme einmalig schaut und dann löscht, ist das sicher OK. Wenn man eine Aufnahme archivieren will, kann auch schon 1 Fehler zu viel sein.


    Grüße

    kamel5

    Den Crash kann ich bestätigen:

    Allerdings trat das bei mir nur manchmal auf. Bisher konnte ich das nur reproduzieren, wenn ich während einer bereits laufenden SuchTimer-Aufnahme die Endezeit vorgezogen habe (im Bereich des Timernachlaufs). Ein Löschen von SuchTimern habe ich noch nicht probiert.


    Grüße

    kamel5

    Ich hatte auch Probleme mit dem Einspielen des Patches. Ein reject in recdone_thread.c (erster Patch-Teil).

    Nach händischer Auflösung und kurzem Test muss ich leider feststellen, das es bisher nicht wie erwartet funktioniert hat, trotz ordnungsgemäßer Aufnahme.

    Weitere Tests kann ich erst in den nächsten Tagen machen.


    Grüße

    kamel5

    Schon seltsam. Wenn aber die Bildschirmkopie im Gegensatz zum Live-Bild anders aussieht, kann es nicht am skindesigner liegen, den der gibt nur die Koordinaten des Videobildes aus und kann nicht unterscheiden, ob es als Live-Bild ausgegeben oder als Bildschirmkopie abgespeichert wird.


    Grüße

    kamel5

    Hallo,

    aber auf dem TV ist das Bild unpassend mit einem schwarzem Balken ins Menü eingefasst...

    ist die Anzeige der Poster in der Übersicht Aufnahmen, die sind etwas zu groß und werden daher unten abgeschnitten.

    bei mir sehen beide Skins so aus, wie man das erwarten würde, sowohl bei shady, als auch bei shady_kiss (TT6400-Ausgabe).

    Welche skindesigner-Version nutzt ihr, die letzte ist 2.1.17.


    Grundsätzlich stellt der skindesigner nur Tokens zur Verfügung. Die eigentliche Positionierung wird über den Skin definiert.

    Ihr könnt auch mal den Skin estuary4vdr probieren, ob es sich da genauso verhält. Wenn nicht, liegt es am benutzten Skin.


    Taipan , das scheint mir ein angepasster shady skin zu sein. Wenn Du den hier mal zur Verfügung stellen könntest, würde ich das bei mir testen.


    ofenheizer , diesen Effekt habe ich auch schon mal gesehen, sollte aber in der aktuellen Version nicht mehr auftreten.


    Grüße

    kamel5

    Ich gehe also davon aus, dass diese Änderung richtig und wichtig ist und auch auf allen Devices positiv wirken dürfte.

    Für die TT6400 kann ich bestätigen das sich diese Änderung positiv auswirkt.


    Grüße

    kamel5

    Bisher kein Lock Error.

    Sehr schön, dann werde ich das so übernehmen.

    PS:

    Hatte auch die Fehleranzeige (aus 4c4cdb98e662c69d..) probiert, leider sieht man die Fehler nicht, weil die zwei Zeitdauern bereits zuviel Platz brauchen, wenn man das Menü nach goldenem Schnitt teilt.

    Habe mir dies daher zur Aufnahmezeit (wie im Original) verschoben, da paßt es besser.

    Klar, irgendwann reicht der Platz nicht mehr. Ich muss mal sehen, ob mir da eine flexiblere Lösung einfällt.


    Grüße

    kamel5

    Fourty2 ,


    ich habe Deine Skin-Einstellungen mal getestet und konnte es auch damit im normalen Betrieb nicht nachvollziehen.

    Es liegt also nicht an den Einstellungen.


    Vielleicht ist daran auch ein plugin beteiligt. Denn dieser Aufruf:

    Code
    1. Jan 8 14:17:48 vdr: [2868] /usr/bin/vdr cMenuRecording::RefreshRecording() calling ?? at ??:0

    wird bei Anzeige der Aufnahme-Info sekündlich aufgerufen und macht normalerweise nichts. Hier wäre interessant, wodurch das "RefreshRecording()" bei Dir mit Aktualisierung der Anzeige ausgelöst wurde. Nachdem ich diese Aktualisierung der Anzeige erzwungen habe, konnte ich auch den Report nachvollziehen.


    Aber egal, es ist auf jeden Fall problematisch, in SetRecording() im Skin ein höherwertiges Lock zu machen. Das sollte nur in der Funktion Flush() stattfinden.

    Ich habe das jetzt entsprechend geändert.


    Es wäre schön, wenn Du den Branch devel (aktuell letzter commit) bei Dir mal nutzen und beobachten könntest. Damit sollte dieser "invalid lock sequence report" nicht mehr auftreten.


    Viele Grüße

    kamel5

    Das langsame Ausblenden des OSD arbeitet wieder (weiß garnicht mehr, wann das zuletzt funktionierte),

    Dann ist es Version 1.1.9. Das Ausblenden dürfte noch nie funktioniert haben, das habe ich mit eingebaut:).

    Auch das Einblenden ist vorher noch nie richtig gegangen, jetzt sollten alle OSD-Elemente berücksichtigt werden...


    Aber zurück zum Thema:

    Ich konnte bisher den "invalid lock sequence report" bei mir nicht nachvollziehen.

    Ich habe dazu zwar eine Idee, es wäre aber hilfreich wenn ich das hier testen könnte.

    Schicke mir deshalb mal Deine Skin-Einstellungen, möglicherweise gibt da einen Parameter, der das provoziert.

    Und dann noch die Frage, ob es bei Dir reproduzierbar ist, oder nur ein Einzelfall, dann wird es schwieriger zu finden.

    Lässt Du das Aufzeichnungsmenü ersetzen?


    Grüße

    kamel5

    Ich habe mal hier etwas weiter experimentiert, auch weil ich nicht abschätzen kann, wie umfangreich eine Anpassung in epgsearch werden könnte.

    Hängt aber wahrscheinlich wirklich mit 2.5/2.6 zusammen und mit dem commit:

    Author: Klaus Schmidinger <vdr@tvdr.de>

    Date: Tue Apr 20 13:22:37 2021 +0200
    Deleting expired timers is now triggered immediately after the timers are modified

    Ob dieser commit funktional bedingt war, kann sicher nur kls mit Bestimmtheit sagen.


    Ich habe deshalb testhalber die Funktion "bool cTimers::DeleteExpired(bool Force)" auch für den Fall "Forced" mit einer Verzögerung von 1s versehen, um das nicht unnötig lange zu verzögern. Dadurch hat epgsearch genügend Zeit, um den recdone thread abzuarbeiten. Auch damit funktioniert es problemlos.

    Siehe Anhang: cTimers.DeleteExpired.diff.gz


    Bei dieser Gelegenheit (und weil es zu "Vermeide Wiederholung" passt) habe ich den "recdone_thread" um die Prüfung der fehlerfreien Aufnahme erweitert.

    Siehe Anhang: 0001-Add-check-errors-to-recdone_thread.c.patch.gz

    Damit wird eine Aufnahme nur dann als "erledigt" markiert, wenn keine Fehler vorhanden sind.:)

    TomJoad , vielleicht kannst Du das so oder ähnlich mit in epgsearch aufnehmen.


    Grüße

    kamel5

    Hängt aber wahrscheinlich wirklich mit 2.5/2.6 zusammen und mit dem commit:

    Author: Klaus Schmidinger <vdr@tvdr.de>

    Date: Tue Apr 20 13:22:37 2021 +0200
    Deleting expired timers is now triggered immediately after the timers are modified

    Das ist das verantwortliche commit. Ich habe das mal reverted und siehe da, es funktioniert wieder:

    Code
    1. Fr. 07.01.2022 13:12:00: started recdone_thread
    2. Fr. 07.01.2022 13:12:00: recdone_thread processing /Video/video0/Serien/Castle/Dem_Dreifachmörder_auf_der_Spur/2022-01-07.12.23.57-0.rec
    3. Fr. 07.01.2022 13:12:00: finished: 'Serien~Castle~Dem Dreifachmörder auf der Spur'; search timer: 'Castle'; VPS used: No
    4. Fr. 07.01.2022 13:12:00: added rec done for 'Castle~Dem Dreifachmörder auf der Spur';Castle
    5. Fr. 07.01.2022 13:12:00: recdone_thread ended

    Grüße

    kamel5

    Das ist durchaus möglich, da hat sich bestimmt das Timer-Handling etwas geändert.


    Vor einiger Zeit hatte ich mal ein paar Debug-Meldungen in epgsearch recdone_thread.c eingebaut. Da ist auffällig, das der betrachtete Timer bereits gelöscht war, bevor dieser thread aktiv wurde und es dadurch keinen Fall positiv gab:

    Code
    1. Jan 06 17:02:00 vdr[510457]: [510457] timer 21 (3 1609-1702 'Serien~Die Rosenheim-Cops~Ausgebacken') set to no event
    2. Jan 06 17:02:00 vdr[510457]: [510457] deleting timer 21 (3 1609-1702 'Serien~Die Rosenheim-Cops~Ausgebacken')
    3. Jan 06 17:02:00 vdr[510457]: [602284] recdone_thread.c Action 80 - started recdone_thread
    4. Jan 06 17:02:00 vdr[510457]: [602284] recdone_thread.c Action 90 processing /Video/video0/Serien/Die_Rosenheim-Cops/Ausgebacken/2022-01-06.16.09.3-0.rec

    Ich weiß aber nicht, wie das vorher war und weiter verfolgt habe ich es bisher nicht.


    Na mal sehen.


    Grüße

    kamel5