Posts by kls

    Das wurde in dem genannten Thread lang und breit diskutiert.

    Eine Pixmap ist eine Resource, die u. U. hard- oder softwaremäßigen Beschränkungen unterliegt.

    Eine "unendlich große" Pixmap kann es daher sinnvoll nicht geben.

    Es bringt auch nichts, die Größe zu erhöhen, nur weil eine Skin nicht damit zurecht kommt, etwas scrollbar anzuzeigen, das größer als der Bildschirm ist. Wenn wir die Größe so weit erhöhen, dass es für diesen Fall reicht, was ist dann, wenn es beim nächsten Fall nicht mehr reicht?


    Du kannst natürlich in VDR/osd.c die Zeile


    cSize cOsd::maxPixmapSize(2048, 2048);


    deinen Bedürfnissen anpassen, oder in SkinFlatPlus die Funktion MaxPixmapSize implementieren und einen beliebigen Wert, der für deine Zwecke groß genug ist, zurückgeben. Eine allgemeine Lösung ist aber beides nicht.


    Der einzige Punkt, über den man sich vielleicht Gedanken machen sollte, ist der Defaultwert von 2048x2048. In Zeiten von HD mit einer maximalen OSD-Größe von 1920x1080 reichte das locker, um eine bildschirmfüllende Pixmap anzulegen. Mit UHD und seinen 3840x2160 Pixeln wäre dies schon nicht mehr möglich. Für die Default-OSD-Implementierung in VDR wäre es wohl kein Problem, z.B. auf 4096x4096 zu gehen. Ein UHD-fähiges Ausgabedevice, welches ein high-level OSD implementiert, dürfte wohl auch in der Lage sein, bildschirmfüllende Pixmaps anzulegen. Aber selbst dann sollte eine Skin, die scrollen will, nicht davon ausgehen, dass eine Pixmap "unendlich" groß sein kann.

    Der Patch http://www.tvdr.de/ftp/Develop…5-add-workaround-rst.diff behebt ein Problem mit VPS-Aufnahmen für den Fall, dass der Sender den "running status" eines Events auf '1' ("not running") setzt, nachdem dieser vorher bereits auf '2' ("starts in a few seconds") bzw. '3' ("pausing") gesetzt worden war. Für VDR bedeutete dies, dass die Sendung vorbei ist und das Device freigegeben werden konnte. Bei einem wiederholenden Timer schaltete dieser dann auf den nächsten passenden Event und beobachtete nicht mehr den gerade zu Ende gegangenen. Wenn dann der Status später erneut auf '4' ("running") wechselte, konnte es sein, dass VDR dies nicht mitbekam, weil z.B. durch den EPG-Scan alle Devices auf andere Transponder getunt waren. Erst wenn ein Device wieder auf diesen Transponder geschaltet hat, wurde der Status '4' gesehen und die Aufnahme (verspätet) fortgesetzt oder überhaupt erst begonnen, wodurch dann Teile fehlten.


    Wie ich im Zuge dieser Untersuchungen gesehen habe, beruhte das bisherige Verhalten, dass bei manchen Vorabendserien der ARD, welche den Status '3' während einer Werbepause benutzen, die Werbung tatsächlich bei der Aufnahme weggelassen wurde, darauf, dass kurz nach dem Status '3' auf '1' gewechselt wurde, und VDR somit die Aufnahme einfach komplett beendete. Solange noch ein Device auf den ARD-Transponder getunt war (oder rechtzeitig wieder getunt wurde) war das kein Problem, da der spätere Statuswechsel nach '4' dann erkannt und die Aufnahme fortgesetzt wurde. War dies nicht der Fall, so konnte nach der Werbepause ein Teil der Sendung in der Aufnahme fehlen. Mit diesem Patch wird nun auch bei Status '3' weiter aufgenommen. Eine aktive Auswertung des "pausing" Status werde ich mir in Version 2.5.x anschauen. Vorerst ist es wichtiger, dass nichts fehlt ;-).

    Die Anzahl der continuity Fehler der Aufnahme. Sehr hilfreich, wenn man Aufnahmen manchmal erst viel später anschaut, um gleich zu wissen, ob sie OK sind.

    Dass er das unter 'R' ablegt hat halt zur Folge, dass u.U. eine falsche Altersfreigabe angezeigt wird.

    Generell sollten Patches/Plugins hier keine eigenen Zeichen verwenden, da diese möglicherweise in künftigen VDR-Versionen für andere Dinge vergeben werden können.

    Das wäre aber wünschenswert, dass das erhalten bleibt.

    Was hat man sonst davon?

    Wenn es schon eigens diesen Tag gibt, ist das doch unerwartet.

    Das '#' ist, wie in allen anderen Dateien, ein Kommentarzeichen und solche Zeilen werden bereits beim Einlesen ignoriert.

    Für "externe" Informationen, die überdauern sollen, gibt es das '@' Tag. Dieser String wird von VDR beim Einlesen gespeichert und ggf. unverändert wieder rausgeschrieben (wobei es nur einen solchen geben kann, kommt '@' mehrmals vor, gilt der Letzte).

    Das heißt dann also, es klappt, wenn du es wie unter "Also gut" machst.


    Hinweis:

    - Ich weiß nicht, was der checkts-Patch da meint unter 'R' reinschreiben zu wollen, aber dieses Tag steht offiziell für "parental rating".

    - Alles, was mit '#' in der info-Datei steht geht bei einem eventuellen Neu-Schreiben der Datei (z.B., wenn der Benutzer die Priorität oder Lebensdauer der Aufnahme verändert) verloren.

    Wenn ich Tags wie # oder @ verwende (wie in vdr.5 angegeben), hilft das auch nicht.

    Poste doch mal eine 'info'-Datei in in den zwei Versionen "vorher/nachher" bzw. "geht/geht nicht".

    Der Patch http://ftp.tvdr.de/Developer/P…01-add-remote-repeat.diff implementiert die Repeat-Funktion in vaapidevice für das X11-Keyboard.


    Damit das "cSoftRemote" auch beim Anlernen der FB-Codes mitspielt, habe ich es so geändert, dass dieses nicht erst in FeedKeyPress() angelegt wird, sondern wie "normale" cRemote-Objekte auch beim Start des Plugins. Wie das dann mit dem mit "TODO" markierten Code funktioniert muss erst noch geklärt werden. Für eine "normale" TV-Fernbedienung über X11 (direkt über die Tastatur der Konsole oder so etwas wie FLIRC) funktioniert es schon recht gut.

    Ich habe etwas Seltsames beobachtet:

    Wenn ich den X-Server mit der Option '-ar2 N' starte, dann beträgt die Zeit zwischen zwei generierten Repeat-Tastendruck-Events (bei gedrückt gehaltener Taste) nur dann immer N Millisekunden, wenn N 20, 40, 60 oder 80 ist. Für Werte von 10, 30, 50, 70 oder 90 sind die Abstände immer abwechselnd N+10 und N-10. Also z.B. für N=30 sind die Zeiten 20, 40, 20, 40, 20, 40...

    Im Mittel also schon 30, aber warum dieses Alternieren?

    Ist das normal? Das sieht irgendwie nach Bug aus...

    Ich bin gerade dabei, in der Ecke was zu fixen. Probleme können auftreten, wenn das Wiederhol-Intervall der Tastatur kleiner ist als die in cKbdRemote::ReadKey() fest verdrahteten 50ms, und eine durch einen langen Tastendruck ausgelöste Aktion (z.B. Scrollen im EPG-Menü mit "All events - all channels") etwas länger dauert. Es wird die Tage einen Fix dafür geben.


    Das vaapidevice-Plugin liefert immer nur "normale" Tastendrücke, weder Repeat noch Release. Auch dafür wird es bald einen Patch geben.


    Klaus

    Code
    1. 2018-03-18: Version 2.3.9
    2. ...
    3. - Fixed handling VPS events outside the LingerLimit, which could cause recordings to
    4. stop prematurely (thanks to Johann Friedrichs).

    Was interessant wäre sind die Zeilen vor 22:27:01, bei denen dem Timer 7 Events zugewiesen wurden. Möglicherweise ist der Timer am falschen Event "hängengeblieben". Warum, weiß ich allerdings auch nicht.