Posts by kamel5

Bei mir liefen seit gestern mit dem Patch -v3 auch einige Suchtimer. Diese wurden soweit ohne Auffälligkeiten und Abstürze durchgeführt.

Ich werde das die nächsten Tage weiter beobachten.

Grüße

kamel5

MarkusE wrote:

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

Bei mir ließ sich der letzte Patch problemlos einspielen, auf letzten git-Stand.

Ich habe den VDR gerade aktualisiert, mal sehen, was mit der nächsten Aufnahme passiert.

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

jojo61 wrote:

Ich habe skindesigner Version 1.2.7

Im Bereich Videoskalierung hat sich beim skindesigner seit dem nichts geändert.

Grüße

kamel5

Taipan wrote:

Komisch das es dann nur den Bereich vaapi betrifft. Sollten wir jojo61 mal einschalten?

Wenn es nur die eine Variante betrifft, wäre es auf jeden Fall sinnvoll.

Grüße

kamel5

ofenheizer wrote:

Ich meine, dass es mit der Umstellung auf softhdvaapi als Ausgabeplugin auftrat.

Das sieht dann auch so aus, das es ein Problem des Ausgabe-Devices ist. Bitte trotzdem bei Gelegenheit nochmal prüfen, ob es sich mit estuary4vdr genauso verhält, um auszuschließen, das es am Skin liegt.

Grüße

kamel5

Taipan ,

OK, dann liegt es wohl doch eher am Ausgabe-Device. Der skindesigner übergibt nur die entsprechenden Koordinaten für das Video-Fenster. Wenn die falsch wären, müsste es ja bei allen Ausgabe-Devices nicht passen (auch nicht bei einer Bildschirmkopie).

Grüße

kamel5

Hallo,

Taipan wrote:

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

ofenheizer wrote:

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

kls wrote:

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

Fourty2 wrote:

Bisher kein Lock Error.

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

Fourty2 wrote:

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:

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

Fourty2 wrote:

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

Fourty2 ,

in dem Bereich hat sich zwar schon länger nichts geändert...

OK, ich muss mal sehen, ob ich das reproduzieren kann.

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.

TomJoad wrote:

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

TomJoad wrote:

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:

Grüße

kamel5

nvertigo wrote:

Ich wollte nur sagen, dass ich dieses Verhalten (Aufnahme nicht in epgsearchdone.data eingetragen) von <=2.4.8 nur kenne, wenn die Aufnahme Fehler hatte.

Ja, so kenne ich das auch. Erst ab 2.5.x klappt das bei mir nicht mehr.

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:

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

Na mal sehen.

Grüße

kamel5