[UPDATE vdr-experimental] VDR 1.5.14

Tobi · 17. Februar 2008

Hallo!

Es ist nun soweit - die Experimental-Pakete sind auf VDR 1.5.14 umgestellt (aber alte nicht-multiproto-DVB-API!). Nicht alle Plug-ins sind schon an das neue Übersetzungssystem via gettext angepasst!

Folgende Pakete wurden auf eine neue Upstream-Version aktualisiert:

- vdr-plugin-cinebars
- vdr-plugin-clock
- vdr-plugin-femon
- vdr-plugin-ffntedev
- vdr-plugin-fritzbox
- vdr-plugin-iptv
- vdr-plugin-loadepg
- vdr-plugib-pvr350
- vdr-plugin-rssreader
- vdr-plugin-skinsoppalusikka
- vdr-plugin-text2skin
- vdr-plugin-vcd
- vdr-plugin-wapd
- vdr-plugin-xineliboutput

In der Multipatch-Version sind folgende Patches aktiviert:

- opt-20_liemikuutio
- opt-24_jumpplay
- opt-27_ttxtsubs
- opt-28_audioindexer
- opt-29_syncearly-audioindexer
- opt-30-x_analogtv
- opt-31-x_reelchannelscan
- opt-37-x_menuorg
- opt-38_disableDoubleEpgEntrys
- opt-39_noepg
- opt-40_iptv
- opt-41-x_timer-info
- opt-42-x_MainMenuHooks
- opt-43-x_recordshowfree
- opt-44_rotor
- opt-45_yaepg
- opt-47_sourcecaps
- opt-48-x_pin
- opt-50_graphtft-0.1
- opt-51_cuttime

In der Extensions-Patch-Version:

- opt-90_extensions
- opt-90_extensions_debian
- opt-91_ext-channelscan
- opt-91_ext-cmdsubmenu
- opt-91_ext-cutterlimit
- opt-91_ext-cutterqueue
- opt-91_ext-cuttime
- opt-91_ext-ddepgentry
- opt-91_ext-deltimeshiftrec.dpatch
- opt-91_ext-dolbyinrec
- opt-91_ext-dvbplayer
- opt-91_ext-dvbsetup
- opt-91_ext-dvdarchive
- opt-91_ext-dvlfriendlyfnames
- opt-91_ext-dvlrecscriptaddon
- opt-91_ext-dvlvidprefer
- opt-91_ext-graphtft
- opt-91_ext-iptv.dpatch
- opt-91_ext-jumpplay
- opt-91_ext-liemikuutio
- opt-91_ext-livebuffer
- opt-91_ext-mainmenuhooks
- opt-91_ext-menuorg.dpatch
- opt-91_ext-noepg
- opt-91_ext-osdmaxitems
- opt-91_ext-pinplugin
- opt-91_ext-premiereepgfix.dpatch
- opt-91_ext-rotor
- opt-91_ext-settime
- opt-91_ext-sortrecords
- opt-91_ext-sourcecaps
- opt-91_ext-syncearly
- opt-91_ext-timercmd
- opt-91_ext-timerinfo
- opt-91_ext-ttxtsubs.dpatch
- opt-91_ext-validinput
- opt-91_ext-volctrl.dpatch
- opt-91_ext-wareagleicon
- opt-91_ext-yaepg

Die folgenden Plug-ins sind rausgeflogen, da sie Upstream-seitig offensichtlich nicht mehr gepflegt werden:

- autotimeredit (Letzte Version von 11/2005)
- console (Letzte Version von 09/2004)
- mediamvp (Letzte Version von 04/2005)

Falls diese Plug-ins inzwischen vielleicht anderswo weiterentwickelt wurden, lasst es mich wissen!

Die folgenden Plug-ins sind überflüssig geworden:

- subtitles

Die folgenden Plug-ins funktionieren momentan nicht:

- channelscan
- reelchannelscan

Wer das pvr350-Plugin in Etch verwendet muss eine neuere Kernel-Version installieren. Entsprechende Kernel-Pakete gibt es z.B. auf backports.org.

Alle Pakete sind für i386 und AMD64 verfügbar.

Das Update auf die heute erschienene Version 1.5.15 folgt demnächst.

Tobias

towo · 17. Februar 2008

Hm, Pakete wurden installiert, vdr startet ohne Probleme, nur ein Bild bekomme ich nicht.
vdr-sxfe bringt nur ein paar Meldungen auf der Konsole:

Code

vdr-sxfe
vdr-sxfe 1.0.0rc2  (build with xine-lib 1.1.10, using xine-lib 1.1.10)




VDR server not given, searching ...
---------------------------------------------------------------
WARNING: MRL not given and server not found from local network.
         Trying to connect to default port on local host.
---------------------------------------------------------------
[16813] [vdr-fe]    Failed to open connection to bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[16813] [vdr-fe]       (ERROR (gnome_screensaver.c,55): Resource temporarily unavailable)
[16813] [vdr-fe]    Detected 2 CPUs
[16813] [vdr-fe]    Enabling multithreaded video decoding




Press Esc to exit


[16813] [input_vdr] Connecting (control) to tcp://127.0.0.1:37890 ...
[16813] [input_vdr] Server greeting: VDR-1.5.14 xineliboutput-1.0.0rc2 READY
[16813] [input_vdr] Connected (control) to tcp://127.0.0.1:37890
[16813] [input_vdr] Server does not support pipes ? (PIPE: Pipe transport disabled in config.)
[16813] [input_vdr] Data stream connection failed (PIPE)
[16813] [input_vdr] Server does not support RTP ? (RTP: RTP transport disabled in configuration.)
[16813] [input_vdr] Data stream connection failed (RTP)
[16813] [input_vdr] Connecting (data) to udp://127.0.0.1 ...
[16813] [input_vdr] Data stream connected (UDP)
[16813] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
[16827] [input_vdr] UDP:64-64 missing, requested re-send for -1 frames
[16827] [input_vdr] UDP:Re-ordering window exceeded, skipped missed frames 64-64
[16813] [input_vdr] Connections closed.
Terminating...
[16813] [vdr-fe]    Failed to open connection to bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Alles anzeigen

fnu · 17. Februar 2008

Tobi

Vielen Dank, das Du an uns amd64 Nutzer gedacht hast, ich werde testen und Feedback geben.

towo

So einen ähmlichen Fehler hatte ich selbst schonmal unter Lenny, da passte die Version von "xinelibout-sxfe" nicht zur installierten Version von xine/xine-lib.

Lösung war "xinelibout-sxfe" aus Lenny's Repository zu benutzen und nicht aus e-Tobi. Der VDR kam aber aus e-Tobis Etch Repository ....

Also, die "xinelibout-sxfe" mußte exakt zu den installierten xine-Libraries passen. Dem "vdr-plugin-xinelibout" war die Version der Libraries egal ....

Grüße
hummingbird_de

HolgerR · 17. Februar 2008

Danke Tobi,

hab's auch direkt getestet. Für (m)einen Streaming-Client ist's leider nicht brauchbar. "TurnoffPrimary" fehlt (mußte Marc ja in seinem aktuellen Ext.-Patch deaktivieren) und das Problem, dass beim Umschalten nur selten ein Bild erscheint, besteht natürlich auch noch. Für beides gibt es "Workarounds", aber alleine das manuelle Rumgefrickel an der channels.conf rechtfertigt nicht das Ergebnis. Und der Patch für Streamdev, der relativ verlässlich ein Bild bringt, macht den VDR unglaublich träge. Ich bin wohl vorerst bei 1.4.7 festgefahren. Einen Versuch war's aber allemal wert! Hab' jetzt erstmal auf "testing" umgestellt...

Gruß
Holger

wilderigel · 17. Februar 2008

sind halt noch einige plugins ohne *.po unterstuetzung.

randy hat hier ein paar plugins angepasst:
undelete
burn
taste

wilderigel · 17. Februar 2008

vdr-pictures (direkt bei den vdr sourcen) wird nicht in ein paket gepackt?

rüsseltier · 17. Februar 2008

Zitat

Original von towo
Hm, Pakete wurden installiert, vdr startet ohne Probleme, nur ein Bild bekomme ich nicht.
vdr-sxfe bringt nur ein paar Meldungen auf der Konsole:

Ähnliches Problem hier.
Laut xorg.log gibt es ein Problem mit

Code

FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be 1; fixing.

Code

vdr-sxfe 1.0.0rc2  (build with xine-lib 1.1.2, using xine-lib 1.1.2)




VDR server not given, searching ...
---------------------------------------------------------------
WARNING: MRL not given and server not found from local network.
         Trying to connect to default port on local host.
---------------------------------------------------------------
[3117] [vdr-fe]    sxfe_display_open: failed to connect to X server (:0.0)
[3117] [vdr-fe]       (ERROR (xine_sxfe_frontend.c,450): Connection refused)
[3117] [vdr-fe]    sxfe_display_open: failed to connect to X server (127.0.0.1:0.0
[3117] [vdr-fe]       (ERROR (xine_sxfe_frontend.c,454): Connection refused)
[3117] [vdr-fe]    sxfe_display_open: failed to connect to X server.
[3117] [vdr-fe]       (ERROR (xine_sxfe_frontend.c,457): Connection refused)
[3117] [vdr-fe]    If X server is running, try running "xhost +" in xterm window
Error opening display

Alles anzeigen

Tobi · 17. Februar 2008

vdr-pictures gibts in der nächsten oder übernächsten Version. Ich wollte die Pakete erstmal schnell online haben.

PS: Es kann sein, dass die 1.5.14 mit dem DVB-API-Patch Probleme mit der WinTV NOVA-SE2 macht. Kann das jemend nachvollziehen? Ich werd wohl schleunigst auf die 1.5.15 updaten.

Tobi · 17. Februar 2008

Bei Problemen mit Xine prüft bitte mal ob libxine1-xvdr installiert ist und nicht libxine-xvdr.

rüsseltier · 17. Februar 2008

Hier ist libxine1-* installiert.

wilderigel · 17. Februar 2008

hier tut vdr-sxfe auf nem etch clienten ohne probleme.

gandalf · 18. Februar 2008

Zitat

Original von Tobi
:
:
In der Extensions-Patch-Version:
:
:

Alles anzeigen

Dumme Frage?, wie komme ich denn an die Extensions-Patch-Version? Gibt es dafür auch spezielle tags für die sources.list?

Gruss,
Gandalf

Tobi · 18. Februar 2008

Statt vdr-multipatch einfach vdr-extensions verwenden - siehe:

http://e-tobi.net/blog/article…obi-net-debian-repository

Beim Wechsel zwischen Patchvarianten, den Befehl `vdraptrefresh` verwenden!

Tobias

gandalf · 18. Februar 2008

Danke!

Ich war wohl zu forsch und habe "vdr-extensions" auch auf die Zeile fÃ¼r vdr-devel angewendet. Werde gleich mal den vdraptrefresh testen.

Gruss,
Gandalf

Oli · 18. Februar 2008

Hallo

habe gestern abend auch noch meinen VDR von 1.4.7 auf 1.5.14 geupdatet,
lief auch alles ohne Probleme durch, leider habe ich keinen Empfang mehr, also nur ein schwarzes Bild,
OSD und Aufnahmen laufen ohne Probleme

im Syslog erscheint dann folgendes

Code

Feb 18 18:59:07 vdrk vdr: [2804] transfer thread ended (pid=2691, tid=2804)
Feb 18 18:59:07 vdrk vdr: [2691] switching to channel 3
Feb 18 18:59:07 vdrk vdr: [2691] buffer stats: 0 (0%) used
Feb 18 18:59:07 vdrk vdr: [2691] [core.pids] 1: now tuned to source 88c0 transponder 1b725
Feb 18 18:59:07 vdrk vdr: [2815] transfer thread started (pid=2691, tid=2815)
Feb 18 18:59:07 vdrk vdr: [2806] TS buffer on device 2 thread ended (pid=2691, tid=2806)
Feb 18 18:59:07 vdrk vdr: [2805] buffer stats: 0 (0%) used
Feb 18 18:59:07 vdrk vdr: [2805] receiver on device 2 thread ended (pid=2691, tid=2805)
Feb 18 18:59:07 vdrk vdr: [2782] ERROR: frontend 1: Das Argument ist ungültig
Feb 18 18:59:07 vdrk vdr: [2816] receiver on device 2 thread started (pid=2691, tid=2816)
Feb 18 18:59:07 vdrk vdr: [2817] TS buffer on device 2 thread started (pid=2691, tid=2817)

Alles anzeigen

Ausgabe Device ist eine FF 1.3 Sat Karte und eine Skystar 2.6 D ist verbaut

Gruß

Oliver

fozy · 18. Februar 2008

Hallo,

ich habe das gleich Problem wie Oli. Ich konnte durch ein Image das ganze zurückdrehen und nochmal ausprobieren und dadurch feststellen, das es anscheinend nur am vdr Packet liegt. Mein System besteht aus 1x TT FF Ver. 1.3 mit AvBoard + 1x TechniSat Budget. Videoausgabe erfolgt über das AV Board. Die vdrdevel Version funktioniert (zum Glück -> WAF). Hat jemand eine Idee?

Gruß
Fozy

Tobi · 18. Februar 2008

Habt ihr Meldungen im Log von wegen "cx88 timeout" o.s.ä.?

ups · 18. Februar 2008

Zitat

Original von Tobi
Habt ihr Meldungen im Log von wegen "cx88 timeout" o.s.ä.?

Ja hier, hatte ich auch schon bei frueheren Versionen.
"vdr kernel: cx88[0]/2: cx8802_timeout"

Aber auch ich habe das Problem wie Olli nach update auf 1.5.14. Widergabe von Aufzeichnungen funtionieren, Umschalten nicht moeglich (Bild schwarz). Wenn ich mit Femon die Empfangsleistung der Dat-Karten kontrolliere sind die Werte gegenueber der 1.4.x Versionen deutlich schlechter. Verbaut habe ich eine Nexus 2.1, eine NOVA-SE2 und eine Skystar.

Uwe

Oli · 18. Februar 2008

die Meldungen die ich aus dem Syslog gepostet habe ist leider das einzigste was ich bisher gefunden habe /var/log/messages steht nichts

Oli

BTW: als ich den VDR gestern über die Fernbedienung ausschalten wollte , habe ich eine OSD Meldung erhalten das sich der VDR in 4 min auschalten wird

Ist das ein neue Funktion ??? wenn ja was muss ich machen um das alte verhalten wieder zu bekommen

wilderigel · 18. Februar 2008

/var/log/messages is bei debian meist etwas mager, probier mal /var/log/syslog.

[UPDATE vdr-experimental] VDR 1.5.14

Jetzt mitmachen!

Teilen