Zitat von Klaus SchmidingerAlles anzeigenVDR developer version 2.1.1 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-2.1.1.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-2.0.0-2.1.1.diff
MD5 checksums:
b17f9838bb8ddee9620f838fea7a171d vdr-2.1.1.tar.bz2
8b8ca593885c380cd370e6d19a5b16a1 vdr-2.0.0-2.1.1.diff
WARNING:
========
This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.
The main focus of this version is on adding basic support for positioners
to control steerable satellite dishes. Manually controlling the dish position
and storing individual positions will follow later.
The fixes contained in this version will be released in a stable version 2.0.3
later, if there are no problems.
The changes since version 2.0.0:
CodeAlles anzeigen- Fixed initializing cDevice::keepTracks. - Fixed an endless loop in cTextWrapper::Set() in case the given Width is smaller than one character (reported by Stefan Braun). - Removed all "modified since version 1.6" markers from PLUGINS.html. - Added definitions for older DVB API versions, back until 5.0 (based on a patch from Udo Richter). - Changed cThread::SetIOPriority() from "best effort class" to "idle class" in order to improve overall performance when an editing process is running (thanks to Jochen Dolze). - Fixed handling '/' and '~' in recording file names in case DirectoryEncoding is used (thanks to Lars Hanisch). - Changed the sign of the satellite position value in cSource to reflect the standard of western values being negative. The new member function cSource::Position() can be used to retrieve the orbital position of a satellite. - Fixed multiple occurrences of the same directory in the recordings list in case there are directories that only differ in non-alphanumeric characters (was broken by "Fixed selecting the last replayed recording in the Recordings menu in case there are folders and plain recordings with names that differ only in non-alphanumeric characters" in version 1.7.36). - Fixed displaying the frame number when setting an editing mark (thanks to Thomas Günther). - Fixed no longer generating any editing marks if the edited recording results in just one single sequence (reported by Halim Sahin). - Fixed an error message when parsing SCR values in diseqc.conf. - Fixed an unexpected RCS version tag in the newplugin script. - Fixed an endless loop in the DrawEllipse() functions for very small ellipses (reported by Stefan Braun). - Fixed a crash in the LCARS skin's main menu in case there is no current channel (reported by Dominique Dumont). - Added basic support for positioners to control steerable satellite dishes (based on a patch from Seppo Ingalsuo and Ales Jurik). + Supports GotoN (aka "DiSEqC 1.2") and GotoX (aka "USALS"). + The new DiSEqC command code 'P' can be used to instruct a positioner to move the dish to the required satellite position. When a 'P' code is processed, further execution of the remaining DiSEqC sequence (if any) is postponed until the positioner has reached the new satellite position. + The new special source value of "S360E" can be used in diseqc.conf to indicate that an entry using a positioner can move the dish to any requested position within its range. Think of it as "full circle". + The devices a particular cDiseqc or cScr applies to are now stored directly in each cDiseqc or cScr, respectively. + A plugin can implement a custom positioner control (see PLUGINS.html, section "Positioners"). + The new function cSkinDisplayChannel::SetPositioner() can be implemented by skins to show the user a progress display when the dish is being moved. The default implementation calls SetMessage() with a string indicating the new position the dish is being moved to. The LCARS skin shows a progress bar indicating the movement of the dish. + The new parameters "Site latitude", "Site longitude", "Positioner speed", and "Positioner swing" in the "Setup/LNB" menu can be used to configure the necessary values for a steerable dish. + The cDvbTuner now has a new status tsPositioning, in which it waits until a steerable dish has reached its target position. Parsing SI data is paused until the target position has been reached. - The LCARS skin now shows the source value of the current channel in its channel display. - Fixed asserting free disk space in the cutter. - No longer trying to delete old recordings in AssertFreeDiskSpace() if the given Priority is less than 1. - Fixed handling LIRC events in case repeated events are lost. - Fixed a possible crash when shutting down VDR while subtitles are being displayed (reported by Ville Skyttä). - cDevice::IsPrimaryDevice() now also checks whether the primary device actually has a decoder and returns false otherwise. This should improve device allocation on systems that are only used as a receiver and don't actually display anything. - Increased the value of MAXRETRIES to 20 to reduce the probability of disturbances in transfer mode. - All bonded devices (except for the master) now turn off their LNB power completely to avoid problems when receiving vertically polarized transponders (suggested by Manfred Völkel and Oliver Endriss). - Reverted the change from version 1.5.7 that made all logging go to LOG_ERR (thanks to Christopher Reimer). - Added Begin/EndSegmentTransfer() to the EPG handler interface (thanks to Jörg Wendel). - The code for distributing recordings over several video directories is now deprecated and disabled by default. You can re-enable this feature by removing the comment sign ('//') from the beginning of the line //#define DEPRECATED_DISTRIBUTED_VIDEODIR // Code enclosed with this macro is ... in the file videodir.c. Note, though, that this can only be a temporary workaround. This feature will be completely removed in one of the next developer versions. Distributing the video directory over several disks was a useful feature in times when disks were still relatively small, but it also caused serious problems in case one of the disks failed. Nowadays hard disks come in sizes measured in terabytes, and tools like "mhddfs" can be used to combine several disks to form one large volume. A recommended method for a relatively safe disk setup in a VDR system is to use two 1TB (or larger) disks and use them as a RAID-1 (mirrored). That way, if one disk fails, you can replace it without data loss.
Have fun!
Klaus
[ANNOUNCE] VDR developer version 2.1.1
- Copperhead
- Geschlossen
-
-
Vielen Dank für die neue Version, Klaus.
Gerade getestet und läuft bisher einwandfrei. -
Ich bedanke mich auch. Ist aber eigentlich nur für Leute mit Rotor interessant, oder? Ansonsten könnte man auch auf 2.0.3 warten.
-
Die Integration vom DVBAPI Patch finde ich sehr interessant. Dadurch ergbibt sich für mich als Netceiver-Benutzer mit Uralt-Kernel mal wieder die Möglichkeit einen ungepatchten VDR zu benutzen...
Danke Klaus!
-
Ich bedanke mich auch. Ist aber eigentlich nur für Leute mit Rotor interessant, oder? Ansonsten könnte man auch auf 2.0.3 warten.
naja du brauchst halt das patch auf dem epghandler nicht mehr manuell, ist halt für alle die Pakete beziehen etwas angenehmer...
Danke für die neue Version.
Christian
-
Endlich ! Ich warte schon den ganzen Sommer auf die Rotor Unterstützung !
Schon mal vielen Dank, ich kann erst morgen testen, dann gibt es Feedback wie es läuft.Greetings,
MrNike -
Ganz herzlichen Dank für die neue Version!
Die Integration vom DVBAPI Patch finde ich sehr interessant. Dadurch ergbibt sich für mich als Netceiver-Benutzer mit Uralt-Kernel mal wieder die Möglichkeit einen ungepatchten VDR zu benutzen...
Das changelog der 2.1.1 stiftet hier leider Verwirrung:
ZitatThe changes since version 2.0.0:
Die Änderung bzgl. der DVBAPI floß schon mit VDR 2.0.1 ein, die am 13. April veröffentlicht wurde: [ANNOUNCE] VDR version 2.0.1 releasedDa das 2.1.1 changelog ebenso die Änderungen von VDR 2.0.2 vom 20. Mai beinhalten: [ANNOUNCE] VDR version 2.0.2 released
muß man jetzt recht mühsam die Änderungen raussuchen, die in VDR 2.0.3 einfliessen würden.
Regards
fnu -
Gibt es auch ein .diff von 2.0.2 -> 2.1.1 ?
-
-
Vielen Dank!
-
Mir ist gerade aufgefallen, dass sich die Versionsnummer des dvbhddevice-Plugins auch auf 2.1.1 geaendert hat. Wird die Version jetzt auch immer auf die vdr-Version angepasst, war das nicht nur fuer 2.0.0 geplant?
Die Nummern selbst sind mir eigentlich relativ egal, verwirrend ist jetzt nur, dass die Version im powarman-Repository deutlich niedriger ist, bei im Prinzip gleicher Codefunktionalitaet. Ist der VDR jetzt der Referenzcode fuer dieses Plugin, findet die Entwicklung jetzt hier statt?
Gruss,
S:oren -
Mir ist gerade aufgefallen, dass sich die Versionsnummer des dvbhddevice-Plugins auch auf 2.1.1 geaendert hat. Wird die Version jetzt auch immer auf die vdr-Version angepasst, war das nicht nur fuer 2.0.0 geplant?
Alles, was in der Version 2.1.x "angefasst" wird, bekommt eine Versionsnummer, die mit 2.1 beginnt. Daß jetzt das dvbhddevice-Plugin zufällig 2.1.1 hat, so wie VDR selber, liegt halt daran, daß beide gleichzeitig erhöht wurden. Die nächste VDR Developer Version wird 2.1.2 heißen, und das dvbhddevice-Plugin wird dann weiterhin 2.1.1 haben - es sei denn, es wird darin auch wieder was geändert.In der kommenden 2.0.3 Stable wird das dvbhddevice-Plugin die Versionsnummer 2.0.1 haben, weil es die erste Revision der Release 2.0 ist ;-).
Zitat
Die Nummern selbst sind mir eigentlich relativ egal, verwirrend ist jetzt nur, dass die Version im powarman-Repository deutlich niedriger ist, bei im Prinzip gleicher Codefunktionalitaet. Ist der VDR jetzt der Referenzcode fuer dieses Plugin, findet die Entwicklung jetzt hier statt?
Ich synchronisiere den Code, den ich mit VDR ausliefere, immer auf den Stand in http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice. Aber da powarman die Versionsnummer nicht erhöht, muß ich das wohl tun...Klaus
-
Alles, was in der Version 2.1.x "angefasst" wird, bekommt eine Versionsnummer, die mit 2.1 beginnt. Daß jetzt das dvbhddevice-Plugin zufällig 2.1.1 hat, so wie VDR selber, liegt halt daran, daß beide gleichzeitig erhöht wurden. Die nächste VDR Developer Version wird 2.1.2 heißen, und das dvbhddevice-Plugin wird dann weiterhin 2.1.1 haben - es sei denn, es wird darin auch wieder was geändert.
In der kommenden 2.0.3 Stable wird das dvbhddevice-Plugin die Versionsnummer 2.0.1 haben, weil es die erste Revision der Release 2.0 ist ;-).
Die Verwirrung hat also Methode? Wenn die italienischen und finnischen Uebersetzungen von 2.1.1 nach 2.0.3 uebernommen werden, dann bekommt dort das identische Plugin zu 2.1.1 die Nummer 2.0.2 (2.0.1 gibts schon)?
Aber da powarman die Versionsnummer nicht erhöht, muß ich das wohl tun...
Ich wollte ihm gerade einen entsprechenden Patch schicken, weiss aber nicht, welche Nummer nun die richtige ist...
Zur Klarstellung: Mir waere eine getrennte Pflege des Plugins fuer 2.0 und 2.1 durchaus recht (ich nutze da z.B. einen outputonly-Patch zum Strom-(Hitze-)Sparen, der in 2.0 ziemlich reingewuergt ist und mit einer potentiellen kleinen Aenderung am dvbdevice in 2.1.x elegant waere), aber das vertraegt sich ja nicht so recht mit einem einzelnen Referenzrepository. Und zum Ausgangsproblem: Dort kann es ja nur eine Versionsnummer geben (ich gehe mal davon aus, dass Andreas nicht mehrere Branches pflegen wird)...
Gruss,
S:oren -
Die Verwirrung hat also Methode? Wenn die italienischen und finnischen Uebersetzungen von 2.1.1 nach 2.0.3 uebernommen werden, dann bekommt dort das identische Plugin zu 2.1.1 die Nummer 2.0.2 (2.0.1 gibts schon)?
Genau so ist es. Klar mag dir das jetzt eher unsinnig erscheinen, aber was ist, wenn es in der VDR-Version 2.1.z eine Änderung am Plugin-API gibt, die auch das dvbhddevice-Plugin betrifft? Spätestens dann könnte das Plugin in VDR-Version 2.0.x nicht mehr die gleiche Versionsnummer haben wie in 2.1.x. Dann lieber gleich von Anfang an...ZitatIch wollte ihm gerade einen entsprechenden Patch schicken, weiss aber nicht, welche Nummer nun die richtige ist...
Zur Klarstellung: Mir waere eine getrennte Pflege des Plugins fuer 2.0 und 2.1 durchaus recht (ich nutze da z.B. einen outputonly-Patch zum Strom-(Hitze-)Sparen, der in 2.0 ziemlich reingewuergt ist und mit einer potentiellen kleinen Aenderung am dvbdevice in 2.1.x elegant waere), aber das vertraegt sich ja nicht so recht mit einem einzelnen Referenzrepository. Und zum Ausgangsproblem: Dort kann es ja nur eine Versionsnummer geben (ich gehe mal davon aus, dass Andreas nicht mehrere Branches pflegen wird)...
Glaub' mir, ich würde auch lieber nur an der Version 2.1.x arbeiten und die 2.0 einfach so lassen, wie sie ist. Aber Bugfixes müssen halt auch in einer stabilen Version sein.Bring deine Änderungen am dvbhddevice-Plugin einfach in Andreas Repository ein und kümmere dich nicht um Versionsnummern. Ich schaue normalerweise vor jeder VDR-Release (egal ob Stable oder Developer) ob es dort was Neues gibt und übernehme es entsprechend.
Du kannst auch den Plugin-Code, der mit VDR kommt, einfach vollkommen ignorieren und immer den aus Andreas Repository nehmen. Allerdings kann ich dann halt nicht garantieren, daß er zur jeweiligen VDR-Version passt. Das, was ich ausliefere, habe ich zumindest erfolgreich kompiliert, und in der Developer-Version auch im Alltagsbetrieb getestet...Klaus
-
Klar mag dir das jetzt eher unsinnig erscheinen, aber was ist, wenn es in der VDR-Version 2.1.z eine Änderung am Plugin-API gibt, die auch das dvbhddevice-Plugin betrifft? Spätestens dann könnte das Plugin in VDR-Version 2.0.x nicht mehr die gleiche Versionsnummer haben wie in 2.1.x.
Das kann ich so nicht nachvollziehen. Nahezu jedes ausserhalb des vdr gepflegte Plugin wird 2.0 und 2.1 parallel unterstuetzen (hat ja mit 1.6 / 1.7 / 2.x auch funktioniert), freilich mit unschoenen #ifdef.
Glaub' mir, ich würde auch lieber nur an der Version 2.1.x arbeiten und die 2.0 einfach so lassen, wie sie ist. Aber Bugfixes müssen halt auch in einer stabilen Version sein.
Keine Frage. Aber was spricht dagegen, einfach bei jeder (veroffentlichten) Aenderung des Plugins die Versionsnummer hochzuzaehlen? Dann waere mir auch egal, ob 2.0 oder 2.1 davorsteht, solange es einheitlich ist. Der vdr hat ja diese strenge Trennung von stable/developer, bei Plugins ist das (nach meinem Eindruck) eher unueblich.
Aber ich will mich hier keinesfalls um die Strategie streiten, nur verstehen, wie es mit den Nummern gemeint ist. Das ist nun ja klar und absolut ok fuer mich, auch wenn ich eine einheitliche Plattform ohne forks besser gefunden haette.Gruss,
S:oren -
Hi,
kann es sein, dass sich der VDR 2.1.1 trotz der entsprechenden Einstellung nicht mehr den Kanal beim Abschalten merkt?
Ich habe nach dem Neustart des VDR immer wieder den ersten Kanal der aktuellen Liste.
Bei 2.0.2 hat das noch geklappt.Ciao.
Michael. -
kann es sein, dass sich der VDR 2.1.1 trotz der entsprechenden Einstellung nicht mehr den Kanal beim Abschalten merkt?
Ich habe nach dem Neustart des VDR immer wieder den ersten Kanal der aktuellen Liste.
Bei 2.0.2 hat das noch geklappt.
Sieh doch erstmal im Log nach ob er beim Beenden nicht einfach absemmelt bevor er den letzten Kanal speichern konnte.
Wäre ja nun nicht das erste Mal das ihn ein Plugin vorher runterreißt.Gerald
-
Feedback: Motorsteuerrung geht wunderbar. Getestet habe ich mit einem plain VDR 2.1.1, einer aktivieren Karte und aktiviertem Diseqc.
Wie wird denn das Steuersignal gesendet wenn mehr als ein Device genutzt werden? Geht das immer an die erste Karte oder immer an die aktive Karte?
Eine praktische Funktion wäre es die Device wählen zu können, welche als Motor fungieren soll.Was kann ich denn in den Settings bei 'Positioner swing' einstellen?
Greetings,
MrNike -
Feedback: Motorsteuerrung geht wunderbar. Gestest habe ich mit einem plain VDR 2.1.1, einer aktivieren Karte und aktiviertem Diseqc.
Ich wollte gerade auf deine Fragen antworten, aber anscheinend hast du es inzwischen selber hinbekommen.
Eine "Drehanzeige" ist in der LCARS-Skin eingebaut.Zitat
Wie wird denn das Steuersignal gesendet wenn mehr als ein Device genutzt werden? Geht das immer an die erste Karte oder immer an die aktive Karte?
Eine praktische Funktion wäre es die Device wählen zu können, welche als Motor fungieren soll.
"Mehr als ein Device an einem Rotor" ist noch nicht implementiert, kommt aber noch.Klaus
-
Was ist mit deiner sources.conf? Gibt es da den Eintrag S360E?
Genau das war das Problem. Das war noch die alte. Jetzt geht es soweit.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!