[ANNOUNCE] VDR developer version 1.7.27

Uwe · 1. April 2012

Zitat von Uwe

Hier hat mit vdr-1.7.27 sich wieder ein Problem bemerkbar gemacht, welches eigentlich schon gelöst wurde von Klaus (prio).
Es hat vielleicht was mit dem Bonding von Device 1 und Device 2 der FF HD 6400 zu tun?
Zusätzlich zur FF HD 6400 ist noch eine Dual S2 DVB karte eingebaut, hier aber bekommt Device 3 und Device 4 jeweils ein eigenes DVB Kabel.
Wenn der Vdr nun wegen einem Timer startet und eine Aufnahme startet (Device2), dann bleibt das Live Bild stehen (Standbild), erst wenn ich umschalte funktioniert wieder alles.
Der VDR ist ungepatcht und es sind die gleichen Plugins aktiviert wie bei vdr-1.7.26. Das Problem konnte ich die ganze Woche, jeden Tag nachvollziehen.
Hat jemand eine Idee bzw kann das bestätigen. Im Log konnte ich nichts auffälliges finden.

Nun klappt es wieder. Danke an Klaus (kls)

Zitat

Die einzige Änderung in dvbdevice.c zwischen 1.7.26 und 1.7.27 war

--- dvbdevice.c 2012/03/13 09:50:56 2.68
+++ dvbdevice.c 2012/03/25 10:41:45 2.69
@@ -1448,7 +1448,7 @@

if (dvbTuner && ProvidesTransponder(Channel)) {
result = hasPriority;
- if (Priority >= 0) {
+ if (Priority > IDLEPRIORITY) {
if (Receiving()) {
if (dvbTuner->IsTunedTo(Channel)) {
if (Channel->Vpid() && !HasPid(Channel->Vpid()) Channel->Apid(0) && !HasPid(Channel->Apid(0)) Channel->Dpid(0) && !HasPid(Channel->Dpid(0))) {

Alles anzeigen

Wenn ich das wieder so ändere, wie es in vdr-1.7.26 war, klappt es wieder!

Das in vdr-1.7.27 in dvbdevice.c geändert:

Code

if (dvbTuner && ProvidesTransponder(Channel)) {
     result = hasPriority;
-     if (Priority > IDLEPRIORITY) {
+//     if (Priority > IDLEPRIORITY) {
+                if (Priority >= 0) {
        if (Receiving()) {
           if (dvbTuner->IsTunedTo(Channel)) {

rudirabbit · 1. April 2012

Hallo, Ich habe nun fast alle Plugins die ich brauche gegen die 1.7.27 bauen können

Leider läuft arghdirector nicht durch.
Ich habe den alten i18n Kram rausgenommen, doch nun tritt dies auf.

Code

Plugin arghdirector:
make[1]: Entering directory `/test/vdr-1.7.27/PLUGINS/src/arghdirector-0.2.7-test1'
make[1]: Leaving directory `/test/vdr-1.7.27/PLUGINS/src/arghdirector-0.2.7-test1'
make[1]: Entering directory `/test/vdr-1.7.27/PLUGINS/src/arghdirector-0.2.7-test1'
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -DUSE_GRAPHTFT -DUSE_JUMPPLAY -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME='                    "arghdirector"' -I/usr/src/dvb/linux/include -I../../../include -I/usr/src/dvb/linux/include arghdirector.c
../../../include/vdr/status.h:36:16: error: âvirtual void cStatus::ChannelSwitch(const cDevice*, int, bool)â was hidden [-Werror=overloaded-v                    irtual]
arghdirector.c:82:16: error:   by âvirtual void cDirectorStatus::ChannelSwitch(const cDevice*, int)â [-Werror=overloaded-virtual]
cc1plus: some warnings being treated as errors
make[1]: *** [arghdirector.o] Error 1

Natürlich habe ich die Änderungen gelesen:

Zitat

- Made the "overloaded-virtual" warning an error to detect hidden overloaded
virtual functions (thanks to Anssi Hannula for pointing out -Werror=...).
Plugin authors may want to change -Woverloaded-virtual to -Werror=overloaded-virtual
in their Makefiles.

Ich habe das Makefile des Plugins deshalb so geändert:

Code

CXX  ?= g++
-CXXFLAGS ?= -O2 -Wall -Woverloaded-virtual
+CXXFLAGS ?= -O2 -Wall -Werror=overloaded-virtual

Bringt leider keine Änderung

hotzenplotz5 · 1. April 2012

arghdirector 0.2.7 ? wo gibt es das ?
ABER :
https://launchpad.net/~yavdr/+…0%7Eprecise.debian.tar.gz

in debian/patches
damit baut das plugin ohne probleme mit vdr-1.7.27

https://launchpadlibrarian.net…0~precise_BUILDING.txt.gz

rudirabbit · 1. April 2012

Hi,

Zitat von hotzenplotz5

arghdirector 0.2.7 ? wo gibt es das ?

Dort

Die 0.2.6d ging aber auch nicht, ich werde deinen Link mal testen - Danke

3PO · 1. April 2012

Zitat von hotzenplotz5

arghdirector 0.2.7 ? wo gibt es das ?

Hier:
EDIT: Der Hase war schneller...

hotzenplotz5 · 1. April 2012

besten dank blechbüx !

rudirabbit · 1. April 2012

Hi,
ist seltsam.
Die Änderungen in der Debian Version von hotzenplotz5 sind im Prinzip die selben die ich gemacht habe. (i18n und die Änderungen im Makefile)
Das Problem bei dem Zugriff auf die Class mit der versteckten Funktion bleibt. Trotz der angepassten Compiler Option

FireFly · 1. April 2012

Du musst einfach nur ein "bool Liveview" and die Parameterlisten dranhängen damit es kompiliert - aber ob dann das Plugin noch wie gewollt funktioniert wenn das neue Flag nicht ausgewertet wird ist ne andere Frage ...

rudirabbit · 2. April 2012

FireFly: Oh Mann, da hätte ich selbst draufkommen können (oder müssen) - Es gilt auch hier nicht die Ausrede, daß ich C++ im Prinzip nicht wirklich kann.
Wenn man eine eigene Klasse aus einer anderen erbt, dann müssen die Funktionsprotypen identisch sein, und dies ist auch in Delphi so
Danke - hab's nicht gesehen.
Die Compiler Fehlermedungen waren hier auch nicht wirklich hilfreich...
BTW:
Deine Bedenken, weil dieser Parameter in der Funktion nicht ausgewertet wird muss ich noch testen - evtl. kann man was einbauen.

HALLO01 · 2. April 2012

Zitat von Keine_Ahnung

Was hast du gegen den API Wrapper?

Hast du den Pfad dazu in make.config korrekt gesetzt?

cu

Alles anzeigen

welches make.config muss angepasst werden?

Edit: Das des vdr's denke ich- hab ich gerade gemacht und es funktioniert

nox · 2. April 2012

Da danach gefragt wurde... In meinen FreeBSD ports die ich grad teste http://people.freebsd.org/~nox/tmp/vdr-ports-1.7.27-005.shar (und so oder so aehnlich wohl nach dem Ende des ports slush committen werde) hab ich auch patches fuer die reelchannelscan und infosatepg plugins: multimedia/vdr-plugin-reelchannelscan/files/* und multimedia/vdr-plugin-infosatepg/files/* (die beiden patch-Makefile sind allerdings nur fuer FreeBSD ports intressant, und der eine oder andere Bugfix und portability Fix ist auchnoch dabei.)

Das erstmal nur so, wenn Bedarf ist koennt ich wohl auch noch zusammengefasste Patchfiles fuer die beiden (oder andere in dem shar) Plugins machen...

HTH,
Juergen

nox · 3. April 2012

Ich hab vdr gestern mal laenger laufen lassen und mir scheint er hat garkeinen epg scan gemacht? "svdrpsend scan" tut auch nix, live playback laeuft weiter... Wenn ich auf dem dvb-t + -s vdr auf dvb-t umschalte scanned er dvb-s, aber wenn dvb-s live laeuft scanned er dvb-s scheints nie, und dann hab ich nochmal auf nem Testrechner mit dvb-t-only getestet, da tat zumindest "svdrpsend scan" auch nix, live playback lief auch da weiter.

Frage: Ist das nur bei mir so?

Gruss,
Juergen

fnu · 3. April 2012

Zitat von nox

Frage: Ist das nur bei mir so?

Hast Du zufällig "vdr-plugin-dynamite" aktiv? Ähnliches hat letzte Woche schonmal einer beschrieben, gut es war nicht mit FreeBSD ...

Reagrds
fnu

nox · 3. April 2012

Zitat von fnu

Hast zufällig "vdr-plugin-dynamite" aktiv? Ähnliches hat letzte Woche schonmal einer beschrieben, gut es war nicht mit FreeBSD ...

Reagrds
fnu

Nein, das passiert auch mit nur xineliboutput und skinenigmang. Also dass "svdrpsend scan" nix tut.

Hmm...
Juergen

mini73 · 4. April 2012

Moin!

Was für einen vdr setzt du denn dein, irgend eine bestimmte Distribution, irgendwelche Patches oder vanilla-vdr?

Lars.

johns · 4. April 2012

Ich habe schon gedacht es liegt an meinem Plugin.

Ich habe diesen Effect auch mit 1.7.25 (gentoo mit diesen Patch ddepgentry liemikuutio mainmenuhooks menuorg nalustripper yaepg).
Mit 1.7.22 hat sicher noch geklappt. Wenn man Menu -> Einstellung -> EPG -> Scan ausgeführt hat, ist das Bild eingefrohren und
man konnte im syslog den scan sehen. Dies ist mit dieser Version nicht mehr der Fall.

Ich habe nun den zweiten LNB Eingang aktiviert, nun klappt der Scan wieder.

Johns

nox · 4. April 2012

Zitat von mini73

Moin!

Was für einen vdr setzt du denn dein, irgend eine bestimmte Distribution, irgendwelche Patches oder vanilla-vdr?

Lars.

Das ist auf FreeBSD, getestet zuletzt mit vanilla vdr + FreeBSD portability patches: http://people.freebsd.org/~nox/tmp/vdr-ports-1.7.27-005.shar

Zitat von johns

Ich habe schon gedacht es liegt an meinem Plugin.

Ich habe diesen Effect auch mit 1.7.25 (gentoo mit diesen Patch ddepgentry liemikuutio mainmenuhooks menuorg nalustripper yaepg).
Mit 1.7.22 hat sicher noch geklappt. Wenn man Menu -> Einstellung -> EPG -> Scan ausgeführt hat, ist das Bild eingefrohren und
man konnte im syslog den scan sehen. Dies ist mit dieser Version nicht mehr der Fall.

Ich habe nun den zweiten LNB Eingang aktiviert, nun klappt der Scan wieder.

Johns

Alles anzeigen

Ja, so ist das hier auch, Menu -> Einstellung -> EPG -> Scan tut nix, und mit nem dual tuner (ich hab da zwar nur dvb-t) faellt das Problem nicht auf. Und mit 1.7.22 (die Version ist im Moment noch in ports: http://www.freshports.org/multimedia/vdr) tat das hier auch noch.

Da das scheints sowohl ~~dvbhddevice~~ softhddevice als auch xineliboutput betrifft: koennte es auch ein Problem mit Priorities sein, dass die beiden Plugins da vielleicht angepasst werden muessen?

Gruss,
Juergen

nox · 6. April 2012

Manchmal hilft ein Blick in die Source doch... Ich glaub dass epg scans auf single tuner mit xineliboutput oder softhddevice im live view mode nichtmehr starten liegt daran dass cDevice::Receiving's bool arg nixmehr tut; das defaulted zumindest bei 1.7.22 noch zu false und sagte der Funktion sie soll receiver mit live view priority und kleiner ignorieren - und wenn eitscan.c cEITScanner :: Process dann cDevice :: Receiving aufruft returned es jetzt true auch wenn das device nur im live view mode ist und der epg scan startet deshalb nichtmehr.

Hab Klaus jetzt mal auf der vdr list gefragt wie man das am besten fixed... http://article.gmane.org/gmane.linux.vdr/45881

Gruss,
Juergen

nox · 7. April 2012

Nur fuer die die es nochnicht gesehen haben, Klaus hat geantwortet http://article.gmane.org/gmane.linux.vdr/45889 und ich hab seinen fix erfolgreich getestet, ich haeng den mal an.

Danke an Klaus!
Juergen

Kron · 8. April 2012

Hallo

Wollte seit längeren mal wieder aktiv was am VDR machen und einen eigenen Skin basteln.

Dabei ist mir im VDR Code folgendes aufgefallen:
skins.h

Code

/*TODO
  virtual void SetItem(const cEvent *Event, int Index, bool Current, bool Selectable, bool NowNext???, bool Schedule???);
  virtual void SetItem(const cTimer *Timer, int Index, bool Current, bool Selectable);
  virtual void SetItem(const cChannel *Channel, int Index, bool Current, bool Selectable);
  virtual void SetItem(const cRecording *Recording, int Index, bool Current, bool Selectable);
  --> false: call SetItem(text)
  */

Wie man unschwer erkennen kann steht das auf der TODO Liste.
Wann kann man so ganz grob mit einer Umsetzung rechnen ? Oder im gibt es im Moment wichtigeres ?
Kann man bei der Umsetzung helfen wenn ja wie und was müsste alles geändert werden?

Wäre cool wenn die Funktionen umgesetzt werden würden vor allem Recordings so kann man schon viel mehr Infos im Skin anzeigen lassen.

Gruß

Sebastian

[ANNOUNCE] VDR developer version 1.7.27

Jetzt mitmachen!

Teilen