Patches für VDR 2.4

    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 ;-).

    wäre es nicht allmählich mal Zeit für eine 2.4.1 - auch wenn das vielleicht erstmal nur ein Zwischenstand ist und noch weitere Fixes in Arbeit sind?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Gerade diejenigen, die alles in einem Verzeichnis bauen und nicht paketieren könnten aktuell prinzipiell stark davon profitieren den Sourcecode einfach aus dem GIT auszuchecken:


    https://github.com/VDR4Arch/vdr


    Einziger Nachteil ist, dass der eben nicht von Klaus direkt gepflegt wird.


    Sein aktueller "Workflow" würde im Prinzip echt perfekt zu GIT passen. Statt der Patches, die ja auch immer sauber benannt und abgelegt werden müssen, einfach GIT-Commits draus machen und das dann regelmäßig via "git push" der Öffentlichkeit zur Verfügung stellen.


    Wer es wirklich als Patch braucht kann sich die Commits dann ja auch als Patch aus so gut wie jedem gängigen GIT-Webinterface runterladen.


    Für mich ist es, dank Helper-Script, nurnoch Aufwand von wenigen Sekunden um einen Patch zu committen. Allerdings bin ich halt nicht ständig am Rechner und automatisieren will ich das nicht. Ist schon besser da noch einen Blick drauf zu haben.


    Allerdings muss ich schon sagen, dass, trotz des nicht unerheblichen Aufwands für alle, die mehrere Dutzend Patches manuell patchen, mir das so allemal besser gefällt als immer fertige "Releases" die dann zig Änderungen beinhalten. Durch die kleinen Schritte kann man im Fall des Falles tatsächlich über den GIT-Mirror ein bisecting hinbekommen um den Patch zu finden der einen Bug ausgelöst hat.

    Bitte beim Thema bleiben, geht um VDR Patches die Klaus' in seinem Thread hier ankündigt.


    Wie Klaus' arbeitet ist alleine Sache und bedarf nicht bei jeder Gelegenheit irgendeinen unsinnigen Kommentar dazu. Ich bin jedenfalls äusserst froh um seinen Einsatz und schätze VDR bis heute sehr, vielen Dank dafür!


    Gruß

    Frank


    PS.: Kann jeder ein GIT Repository dazu pflegen, ist aber vmtl. witzlos wenn im Prinzip keine eigenen Code-Beiträge liefern kann ... :evil:

    HowTo: APT pinning

    fnu auch ich schätze die Arbeit von Klaus sehr, sonst wäre ich nicht so lange dabei.

    Und der VDR ist wirklich ein tolles Stück Software, was seines gleichen sucht.

    Trotzdem , ein kleines Späßchen muss schon mal sein....

    Oder wie ein Freund von mir mal sagte " Das ist nicht langsam, das ist STOP" ;D

    Zitat von fnu

    PS.: Kann jeder ein GIT Repository dazu pflegen, ist aber vmtl. witzlos wenn im Prinzip keine eigenen Code-Beiträge liefern kann ... :evil:

    Stimmt so nicht. Jeder kann nach belieben auf "Fork" klicken und sich seine eigene schreibbare Kopie ziehen. Und sei es nur um eigene Anpassungen zu testen und später ggf. wieder in Form eines Patches an Klaus zu mailen.

    Der Patch http://ftp.tvdr.de/Developer/P…-chg-max-pixmap-size.diff ändert den Defaultwert für die maximale Größe einer cPixmap auf den maximal möglichen Wert von INT_MAX. Damit können Skins, die Pixmaps anlegen wollen, welche wesentlich größer sind als das OSD, dies auch tun, wenn sie MaxPixmapSize() abfragen. Das funktioniert aber nur so lange, wie das verwendete OSD nicht einen kleineren Wert zurückliefert, weil es (z.B. wegen Speicherlimits) einfach keine größeren Pixmaps anlegen kann.

    Wenn man den letzten Patch (vdr-2.4.0-37-chg-max-pixmap-size.diff) auf den "Stapel" der anderen Patches patchen will, dann gibt es ein Reject, weil der Patch eine Änderung an der "HISTORY" durchführen will.


    Für den GIT-Mirror habe ich diese Änderung (HISTORY) weggelassen. Kommt mit dem finalen Release dann wohl sowieso rein.

    Der Patch http://ftp.tvdr.de/Developer/P…dex-vs-device-number.diff behebt inkonsistentes Verhalten bei Verwendung der Option '-D' um nur bestimmte Devices auszuwählen. In einem solchen Fall stimmten z.B. die im "Edit channel" Menü unter CA eingegebenen Nummern für die feste Zuweisung eines Kanals an ein Device nicht mit den im Hauptmenü und der Kanalanzeige (bei der LCARS-Skin) angezeigten Device-Nummern überein. Auch bei Log-Meldungen gab es einige Irritationen, welches Device denn nun gemeint war. Ich habe das jetzt so geändert, dass der bisher an vielen Stellen verwendete CardIndex() durch DeviceNumber() ersetzt wurde. CardIndex() wird jetzt nur noch im Zusammenhang mit der Option '-D' verwendet. Wann immer ansonsten von einer "Device Nummer" die Rede ist, ist es eine Nummer von 1...N, wie sie im LCARS-Hauptmenü angezeigt werden.


    Genau genommen ist der Returnwert der Funktion cDevice::DeviceNumber() unlogisch, denn "Nummern" sollten immer von 1 losgehen. Wenn etwas bei 0 startet, ist es eher ein Index. Da aber vermutlich etliche Plugins diese Funktion so wie bisher definiert verwenden, kann ich das schlecht ändern. Ich werde daher wohl später eine neue Funktion cDevice::DeviceNum() (oder vielleicht einfach cDevice::Number()) einführen, die direkt die Nummer des Devices (ab '1') liefert, so dass an allen Aufrufstellen das '+ 1' entfallen kann.

    Der Link zum Patch 39 führt zu folgendem Error:

    Zitat

    Objekt nicht gefunden!

    Der angeforderte URL konnte auf dem Server nicht gefunden werden. Sofern Sie den URL manuell eingegeben haben, überprüfen Sie bitte die Schreibweise und versuchen Sie es erneut.

    Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.

    Error 404

    ftp.tvdr.de

    Apache

    Gruß utiltiy



    VDR Projekte VDR Projects

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden