VDR 1.7.8 mit vdr-xine, aktuelles xine mit vdpau

Ich erlaube mir hier mal wieder einen neuen Thread zu eröffnen, der zu ION/vdpau wird langsam etwas lang, und dreht sich zT mehr um Gehäuse als um Software. Meine Kiste ist ION, aber das muss hier ja nicht unbedingt der alleinige Fokus sein. Und um ein Howto für vdr-xine hat grade in einem anderen Thread jemand gebeten.

Nachdem ich mit meinen eigenen from-scratch Installationen nicht weit gekommen bin, habe ich nochmal von vorne angefangen, und zwar auf Basis folgender Anleitung.

http://www.eurocardsharing.com/f273/howto-vdr…ng-s2api-142317

Ich hoffe der Link ist nicht zu "zwielichtig". Es wird auch das hier immer "böse" genannte Plugin erwähnt, aber den Teil kann man ja locker ignorieren (habe ich jedenfalls), ebenso wie div. sonstige Plugins oder Spezialitäten wie DISEqC, die man nicht braucht.

Ich finde das ist eine ganz gute Grundlage, um mal die Basics zu xine(-lib/-ui) mit vdpau und VDR mit vdr-xine hinzubekommen. Natürlich gibt es immer auch noch die WIKI-Seiten, aber mir hätten die nicht gereicht.

Meine Distri: Suse 11.2 M4, Kernel 2.6.30, GCC 4.4
Meine CVS-Stände waren vom 7.8.
Spezialitäten waren:
- VDR 1.7.8 für GCC4.4 musste ich eine Zeile patchen (siehe ION/vdpau Thread)
- Die xine-ui von vor knapp zwei Wochen hat immer einen Fehler in einem Makefile
src/xitk/skins/xinetic/Makefile
dort tauchen Sachen doppelt auf, einfach entfernen (für make install)

Wichtig: keinerlei alte xine-Rückstände sollten vorhanden sein, seien es libs, plugins (/usr/lib/xine), include Dateien usw. Sonst kommt man in alle vorstellbaren xine Höllen.

Damit ist es mir gelungen, einen VDR mit xine plugin grundsätzlich zum Laufen zu bringen.
Wesentlicher Unterschied des xine plugin zu xineliboutput: das Plugin stellt nur die Daten bereit (über Sockets in /tmp/vdr-xine/), die vom normalen xine Programm angezeigt werden. Die config liegt dann in ~/.xine/config (statt in ~/.xine/config_xineliboutput). Vorteil: Absturz von xine reisst den vdr nicht mit. Zur Steuerung verwende ich remote-Plugin, die Details der xine-Tastensteuerung-Weiterleitung-an-VDR blieben mir verborgen (dazu gibts aber auch grade einen Parallel-Thread).

Haupt-Problem im Moment:
SDTV ruckelt gerne schrecklich, xine sagt auch System ist langsam, mit jeder Menge Log-Fehler:
video_out: throwing away image with pts 5988455 because it's too old

Zunächst habe ich folgenden Tipp befolgt:
xine-lib: Uncommenting this in /src/video_out/video_out_vdpau.c
#define LOCKDISPLAY

Das hat aber nichts gebracht (habs aber gelassen).
Dann habe ich in der xine-config eingetragen:
engine.buffers.video_num_buffers:2500

Dachte erst es hilft, aber nein, auch nicht wirklich. Abhilfe schafft nur, zwischendurch mal auf einen HD Kanal zu schalten, danach ist auch SD OK, sprich die frame drops treten nur noch vereinzelt auf.

Was ist da denn los??

Ausserdem bekomme ich keine 1080i Sender (Anixe, AstraHD+), Timeout beim Tuning (Karte TBS 6920).

Die 720p Sender sind weitgehend flüssig und Ton OK (allerdings musste ich dazu die xine-config mal löschen, also zurücksetzen auf defaults).

Freu mich auf alle Tipps!

Quote

Original von peter2
Welche Hardware hast da? Ich nehme an du hast den nvidia Treiber installiert!
Hast du im tool "nvidia-settings" die Option PowerMizer.

Ich habe mit meinem Revo das Problem, das er manchmal bei SD Materiel die GPU nicht ganz hoch taktet, das ruckelt dann.

Wenn du die PowerMizer Option siehst hab ich vielleicht eine Lösung.

Ich habe das Point-of-View 330 (ION/9400M), GPU-Memory grade noch auf 512M gestellt.
Nvidia Treiber 185.18.31.

In den nvidia-settings (-q all) finde ich leider keinen PowerMizer.

Seltsamerweise tritt das Problem grade nicht auf. Vielleicht hat die Erweiterung des GPU-Speichers im BIOS geholfen - oder es ist nur grad wieder irgendwas leicht anders.

1080i Sender laufen nun (siehe Parallel-Thread zur TBS) - und zwar mit der deinterlace Einstellung "half temporal" grade so flüssig. Über der config option steht "vdpau: HD deinterlace method" - heisst das die gilt nur für HD, und was wird dann für SD genommen? Immer temporal_spatial?

Im X-Fenster von nvidia-settings seh ich den PowerMizer auch.
Auch in meiner Version steht der Modus auf "Max Performance".
Und bei mir scheint es zu funktionieren - auch heute die ursprünglichen Probleme nicht gehabt.
Der Powermizer schaltet auf Stufe 3 (0..3) bei HDTV, bei SD schaltet er nach einiger Zeit über 2 auf 1 zurück. Auf 0 hab ich ihn noch nicht gesehen.

Bild ist bei mir zu dunkel, Abhilfe schafft gui.brightness Einstellung (auch über xine-Menu einstellbar). Guter Wert ist 35000.

Aktuell offenes Problem (noch nicht recherchiert): Fehlende Sonderzeichen (z.B. Timer) - nur leere Rechtecke zu sehen. Ausserdem falsche Umlaute bei Aufnahmen (in shell korrekt), Umlaute im EPG sind OK.

Nach etwa zwei Wochen Zeit für ein kleines Fazit. Ich habe den alten DVB-S-FF nach gut 6 Jahren abgelöst, aber in mancherlei Hinsicht trauere ich ihm auch nach.

Zwar habe ich nun einen neuen modernen VDR inklusive HD. Die Bildqualität bei HD ist gut.
Bei SD - naja. Einerseits hat man wohl allein schon wegen HDMI gegenüber dem alten Cinch-Video ein deutlich weniger vermatschtes Bild, auch subjektiv mehr Details. Andererseits ist schon häufig ein
Grieseln im Bild (Bildrauschen) - sei es im Signal oder durch die xine-Ausgabe? Ich schätze Receiver lassen da halt so manche "Bildverbesserungsmassnahme" drüberlaufen, die vielleicht auch wieder zu mehr Unschärfe führt, aber insgesamt halt doch den besseren Eindruck hinterlässt. Es gibt Inhalte die sind bestens, aber andere.. (DVB-T mal aussen vor, das ist oft sowieso grausam, egal mit welcher HW/SW).

Wirklich nervig sind aber die folgenden Punkte:

Synchronisations-Probleme bei der Wiedergabe von Aufnahmen, vorwiegend DVB-T Aufnahmen (übers Netz, siehe VDR2 in Sig - also PES. Das Problem hatte aber auch ein VDR 1.7.0 aus EasyVDR, der ja selbst noch PES ist). Auch der alte konnte da schon mal kurz auseinanderlaufen, aber dann hat man kurz rew-play gemacht und nach 1s war alles wieder OK. Hier kann man nur verzweifelt hin- und herspringen, Pause machen, stoppen und wieder starten und hoffen, dass es irgendwann wieder synchron wird. Und das trotz Bild+Ton über HDMI!

Die Reaktivität ist schon tw. sehr zäh - und ganz besonders beim Spulen. Beim alten FF begann das Spulen praktisch im Moment des Tastendrucks und hörte v.a. damit auch wieder auf, war dabei völlig smooth. Man konnte in 2s in der Aufnahme 10min vorspringen. Da war er allen mir bekannten Receivern weit voraus. Jetzt.. naja ihr kennt das vermutlich selbst. Macht einfach garkeinen Spass (mit xineliboutput war es noch schlimmer). Ich habe auch schon durch Spulen gegen Ende der Aufnahme die VDR/xine-Kombination in den Dauerhänger getrieben.

Dazu kommt noch dass ich jetzt schon zum zweiten mal eine Aufnahme habe (auch DVB-T/PES), die irgendwann mittendrin abbricht. Bei der einen konnte man durch "Drüberspringen" weiter hinten wieder weitermachen, bei der anderen ist ab der Stelle keine Chance mehr, bricht immer sofort ab. VLC gibt die Aufnahme problemlos wieder. Mit dem mplayer-Plugin konnte ich mir behelfen, auch das schafft die Wiedergabe.
Der alte FF hatte niemals jemals ein solches Problem - bei "Knacksern" im Empfang gabs halt ein paar Artefakte und dann gings weiter.

Hier die Log-Ausgaben (Google findet dazu garnix!)

Sep  1 22:31:35 flmedia vdr: [5337] resuming replay at index 66566 (0:44:22.17)
  Sep  1 22:31:35 flmedia vdr: [5338] non blocking file reader thread started (pid=2340, tid=5338)
**Sep  1 22:31:35 flmedia vdr: [5337] SetBrokenLink: no GOP header found in videopacket
  Sep  1 22:31:35 flmedia vdr: [5337] setting audio track to 1 (0)
**Sep  1 22:31:35 flmedia vdr: [5337] ERROR: incomplete PES packet!
  Sep  1 22:31:35 flmedia vdr: [5338] non blocking file reader thread ended (pid=2340, tid=5338)

Also auch ich bin durchaus geneigt, mir die im Moment wieder heftig diskutierte FF-HD genauer anzuschauen, falls sie denn tatsächlich mal das Licht der Welt erblickt und richtig gut funktioniert.

Jetzt noch ein paar Tips, was ich seit der Grundinstallation alles gemacht habe und welche Fallstricke es dabei gab.

- Generell gibt es mit GCC4.4 häufig noch Kompilier-Fehler, weil die neue Version strenger ist.
Meistens geht es um Konvertierung von const char* in char* - es hilft dann ein cast auf (char*).

- Plugins: femon, skinenigmang, extrecmenu, epgsearch, mplayer (mp3)

- Sonderzeichen / Symbole
Download: http://andreas.vdr-developer.org/fonts/download…tf-20080905.tgz
.ttf daraus nach /usr/share/fonts/truetype, fonts-config aufrufen, VDR: Einstellungen OSD: Schriftart VDR-Symbols

- Umlaute
Darauf achten dass zB in runvdr die div. lang-Variablen wie LANG, VDR_LANG, LC_ALL
auf de_DE.UTF-8 gesetzt sind!
-> Falsche Umlaute in Aufnahmen ändern mit convmv (Suse-Paket: convmv)
convmv -f latin1 -t utf8 --notest <somefiles> (-r für recursive)
Inhalte von Dateien, zB summary.vdr:
find . -name 'summary.vdr' | xargs -I{} iconv -f latin1 -t utf8 -o {} {}

- ACPI wakeup
http://www.vdr-wiki.de/wiki/index.php/ACPI_Wakeup
Besonders darauf achten: wenn die Rechner-Zeit lokal ist und nicht UTC, muss man im
Skript 1/2h (je nach Sommer/Winterzeit) dazurechnen. Dabei helfen kann "date -R".
Brückenzeit (Einstellungen/Sonstiges) von 30min auf 10min herabsetzen:
wenn der nächste Timer beim Abschalten weniger als die Brückenzeit weg ist,
wird mindestens die Brückenzeit bis zum wakeup vom VDR vorgegeben!
Sobald Warnung beim Poweroff, wird der Timer also auch nicht klappen!
Vorlaufzeit (Zeit fürs Booten) muss man selbst ins Skript aufnehmen! (zB -80)

- extrecmenu
Irgendwo im Forum einen Patch gefunden, sonst kompiliert er nicht (leider vergessen wo).
Ersetzen des Original-Menus klappt nicht.

- epgsearch
in epgsearch.c einfügen: #include <langinfo.h>
zahlreiche der oben erwähnten GCC4.4 casts auf (char*):
epgsearchsvdrp.c: 745, epgsearchtools.c: 746, menu_dirselect.c: 86, searchtimer_thread.c: 568/569

Offen sind zB folgende Punkte:

- automatische 4:3/16:9 Umschaltung (autocrop) - dazu benötigt man offenbar
die sogenannten "durchflieger"-Patches

- sensors (Temperatur-Überwachung)

Nun ja. Under construction eben..