[ANNOUNCE] VDR developer version 1.7.9

Hi,

muss mal eben blöd fragen: wird es in (naher) Zukunft wieder die LiveBuffer Funktionalität in den neueren VDR Versionen (>1.7.0) geben?

Zitat

Original von NeoTrantor
muss mal eben blöd fragen: wird es in (naher) Zukunft wieder die LiveBuffer Funktionalität in den neueren VDR Versionen (>1.7.0) geben?

Man möge mich korrigieren, aber soweit ich weiß hat das der VDR nie gekonnt. Das wurde immer durch einen externen Patch realisiert. Insofern passt die Frage hier nicht so ganz.

Gerald

Ja, das stimmt. Allerdings hatte ich es so verstanden, dass die Änderungen und Umstellungen in den aktuellen vdr Versionen die Integration dieses Patches verhindern bzw erschweren. Daher wusste ich nicht so recht, wo ich die Frage posten soll (darf gern vom Admin verschoben werden).
Oder hab ich da was in den falschen hals gekriegt?

Ich habe ein Problem mit CA: In meiner FF ist ein CAM+Smartcard, parallel dazu eine DVB-S2 Budged ohne CAM. Seit 1.7.9 werden die verschlüsselten Kanäle nicht mehr hell (oft begleitet vom "Kanal nicht verfügbar"), während sie es mit 1.7.8, wenn auch erst nach mehreren Anläufen, noch liefen.
Das CAM wird im Menü korrekt erkannt, und Femon zeigt die korrekte Karte (FF) an. Auch sind die Bitraten usw. unverdächtig. Eine Blockade der Budget mit einer HDTV-Aufnahme hilft nicht.
Außer dem Patch 8 -> 9 habe ich nicht verändert. Das gewisse weiche Plugin ist nicht im Spiel.

vdr-1.7.9 lässt sich nicht mehr mit den aktuellen DVB Treibern übersetzen da man schon wieder das API geändert hat nun auf 5.1.

Kennt jemand die Änderungen welche zur neuen Minor Version geführt hat?

Ich dachte die höhere Versionen sind abwärtz kompatibel zumindest innerhalb der DVB_API_VERSION , weshalb wird auch DVB_API_VERSION_MINOR geprüft?

Die Version der Treiber ist auch abwärtskompatibel. Eigentlich ist das ein Fehler in VDR.

Ich habe mal eine Frage bezüglich der virtuellen Destruktoren. Mir fehlen irgendwie einige davon, beispielsweise in vielen MenuItem-Klassen. Beim Überladen dieser kommt es jedenfalls bei mir dazu, dass Segfaults auftreten, wenn meine Ableitungen gelöscht werden sollen. Ein Beispiel ist cMenuSetupPage, welches auch virtuelle Methoden vereinbart, die auch noch pure virtual ist. Ich war der Meinung, dass es dann auch immer virtuelle Destruktoren geben muss?!

Hallo,

Da mir im HDTV Bereich, niemand weiterhelfen konnte, hoffe ich das es okay ist wenn ich hier nochmal frage.

Seit ich vdr-1.7.9 verwende kann ich BBC-HD nicht mehr ansehen.
Der sender wird gelockt, bekomme aber kein Bild.

Im log stehen folgende Meldungen:

[demux_vdr] ts2es: payload not PES ?

Mit vdr-1.7.0 ging das noch ohne Probleme, anscheinend hat sich irgendwas geändert??

Gruß
Johannes

Zitat

Original von wilderigel

naja, vdr kann ka ned von vornherein neue treiber apis unterstuetzen.
is ja ned abzusehen wie kompatibel die sind.

Das mag ja richtig sein, dann sollte aber nicht nur ausgegeben werden das die API falsch ist sonder angezeigt werden welche API gefunden wurde und welche erwartet wird.

Ich habe deshalb meinen Rechner neu installiert, weil ich beim hin und her schalten zwischen API 3 und 5 nicht gemerkt hatte das es nun 5.1 ist.

Zitat

Originally posted by methodus
Ich habe mal eine Frage bezüglich der virtuellen Destruktoren. Mir fehlen irgendwie einige davon, beispielsweise in vielen MenuItem-Klassen. Beim Überladen dieser kommt es jedenfalls bei mir dazu, dass Segfaults auftreten, wenn meine Ableitungen gelöscht werden sollen. Ein Beispiel ist cMenuSetupPage, welches auch virtuelle Methoden vereinbart, die auch noch pure virtual ist. Ich war der Meinung, dass es dann auch immer virtuelle Destruktoren geben muss?!

cMenuSetupPage hat zwar keinen expliziten virtuellen Destruktor, aber die Klassen, von denen sie abgeleitet ist, haben welche. Soweit ich das sehe sollte das doch reichen, oder?

Klaus

Zitat

Originally posted by wilderigel
hab hier n problem mit osd position.

osd links % und oben % und wird nicht oder falsch gespeichert.

ist immer auf 0

Kann es sein, daß da ein Komma als Dezimalpunkt verwendet wird?

Sollte zwar durch

setlocale(LC_NUMERIC, "C"); // makes sure any floating point numbers written use a decimal point

in vdr.c nicht vorkommen, aber wer weiß...

Klaus

Hallo Klaus,

besteht die Möglichkeit bei 'call CMD before and after a recording'
eine kleine Erweiterung für gelöschte Aufnahmen mit aufzunehmen?
So könnte man ein laufendes noad killen, wenn die Aufnahme gleich wieder gelöscht wird.
Man könnte sich eine Mail schicken oder oder...

Oct 28 20:59:33 yaris vdr: [8421] executing '/usr/local/vdr/recording_hooks.pl deleted "/video/video0/Knight_Rider/2009-10-26.14.50.53-0.del"'

Danke,
Alex

Zitat

Original von kls

Kann es sein, daß da ein Komma als Dezimalpunkt verwendet wird?

Sollte zwar durch

setlocale(LC_NUMERIC, "C"); // makes sure any floating point numbers written use a decimal point

in vdr.c nicht vorkommen, aber wer weiß...

Klaus

Alles anzeigen

jo, das Verhalten habe ich hier auf dem Client (Kernel 2.6.31, gcc version 4.3.4 (Debian 4.3.4-5) ) auch, aber ein vorheriges

export LC_NUMERIC="C"

im runvdr-Script hilft, komisch.

Zitat

Originally posted by egal
jo, das Verhalten habe ich hier auf dem Client (Kernel 2.6.31, gcc version 4.3.4 (Debian 4.3.4-5) ) auch, aber ein vorheriges

Code

export LC_NUMERIC="C"

im runvdr-Script hilft, komisch.

Das macht VDR eigentlich auch:

setlocale(LC_NUMERIC, "C"); // makes sure any floating point numbers written use a decimal point

Klaus

Ich hatte keine negativen Auswirkungen des Kommas gesehen, wenn beim Lesen und beim Speichern die gleiche Umgebung herrscht.
Jetzt habe ich mir das ganze etwas genauer angesehen und bin etwas überrascht

• Setzen von LC_NUMERIC=C in der Runvdr ändert bei mir nichts
• Nach setlocale(LC_ALL,"") in vdr.c steht LC_NUMERIC auf "de@DE"
• Dann wird es von Klaus aber explizit gesetzt und ist auf "C"
• Bleibt auch so nach I18nInitialize()
• Die LC_NUMERIC ist im vdr wieder umgebogen nach LoadPlugins() auf "de@DE"
• aber nur wenn xineliboutput bei den Plugins ist

Setzt man nach LoadPlugins LC_NUMERIC nochmal explizit auf "C", scheint es sich bis zur Programmbeendigung nicht mehr zu ändern.
Ich verstehe jetzt nicht was da bei PluginManager.LoadPlugins(true) passieren kann.
Wenn das beim Initialisieren oder Starten eines Plugins passiert, kann ich es ja noch nachvollziehen, aber dann auch eher bei einem Plugin, das mit setlocale()-Aufrufen arbeitet. Von alldem ist nichts bei xineliboutput zu sehen.

Hallo
habe das gleiche problem,
mit kernel 2.6.31, ubuntu 9.10 und mandriva 2009.
vdr-1.7.9, vdr-1.7.8

mit vdr-sxfe als frontend
(1.1.6 und 1.2 von xine-lib schon ausprobiert)

bie mir gehen die SD aber nur die die unverschluesselt sind.
Habe eine ofizielle karte, lauft alles bestens unter kernel 2.6.27 und vdr-1.7.7.

Text bzgl. hier nicht erwünschtem Plugin entfernt.

wen jemand eine idee hat, bin bereit zu testen.
Scheint wahrscheinlich am kernel zu liegen.