Der Patch http://ftp.tvdr.de/Developer/P….0-34-fix-repeat-kbd.diff verbessert die Repeat-Funktion für Tastaturen als Fernbedienung.
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 ;-).
-
Der Patch http://ftp.tvdr.de/Developer/P…sert-free-disk-space.diff sorgt dafür, dass bei voller Platte die Meldung "Low disk space!" nur dann kommt, wenn auch wirklich ein lokaler Timer aufnimmt und den Plattenplatz benötigt.
-
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?
-
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.
-
gibt dir keine Mühe, Klaus hat da seinen eigenen Weg ..irgendwann nach Patch 47849 kommt auch VDR 4.1
-
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 ...
-
-
PS.: Kann jeder ein GIT Repository dazu pflegen, ist aber vmtl. witzlos wenn im Prinzip keine eigenen Code-Beiträge liefern kann ...
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.
-
Sorry, ist mir durchgerutscht.
Hab's aus dem Patch gelöscht.
-
Der Patch http://ftp.tvdr.de/Developer/P…38-chg-playerbufsize.diff vergrößert den Frame-Puffer bei der Wiedergabe (siehe hier).
-
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:
ZitatObjekt 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
Apache
-
Das hier ist der korrekte Link:
-
Hab's gefixt.
-
Der Patch http://ftp.tvdr.de/Developer/P…-wrong-variable-name.diff korrigiert einen falschen Variablennamen in cFileName::cFileName() (siehe hier).
-
Der Patch http://ftp.tvdr.de/Developer/P…ins-message-to-queue.diff sorgt dafür, dass ein Aufruf von cSkins::Message() aus einem Hintergrundthread heraus automatisch an QueueMessage() weitergeleitet wird, falls der Type nicht mtStatus ist.
-
Der Patch http://ftp.tvdr.de/Developer/P…s-compatibility-mode.diff korrigiert die Behandlung des S2SatelliteDeliverySystemDescriptors für Transponders die im "backwards compatibility mode" senden.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!