Beiträge von joew

    Zitat

    Original von joew
    Langsam komme ich der Sache naeher: /var/lib/vdr/plugin-loader.sh hat offensichtlich Probleme, die VDR-Version sauber zu erkennen. Folglich werdem beim Start keinerlei Plugins mitgestartet (weil ja die versionen nicht passen). Mache ich nach dem login ein manuelles "/etc/init.d/vdr restart" dann klappt es. Nun ist die Frage, warum mit dem neuen Kernel der Versionscheck beim booten schiefgeht, aber bei einem spaeteren Restart dann wieder funktioniert.


    Wieder einen Schrtitt weiter: Um die Version zu ermitteln, ruft plugin-loader.sh "/usr/bin/vdr -u vdr -w 15 -V -L/usr/bin/vdr" auf. Dieser Befehl liefert folgenden Fehler:

    Code
    vdr: warning - cannot set dumpable: Invalid argument
    vdr: cap_set_proc failed: Operation not permitted


    Dazu habe ich http://www.linuxtv.org/piperma…/2006-January/007201.html gefunden, aber das bringt leider auch keine Besserung.

    Zitat

    Original von joew
    Danke fuer deine unermuedliche Hilfe! Es scheint wohl so zu sein, dass vdr auf diesem Port nicht lauscht. Aber vdr selber laeuft, und im logfile schreibt er immer wieder dass er zB channel-namen aktualisiert. Es sheint wohl die server-Seite der xineliboutput ein Problem zu haben. Es tauchen aber keine Fehlermeldungen in /var/log/messages auf. Uebrigens habe ich eben bemerkt, dass der Fehler nicht immer auftritt. Von 5 Bootvorgaengen ging es 4 mal nicht und 1 mal ging es.


    Langsam komme ich der Sache naeher: /var/lib/vdr/plugin-loader.sh hat offensichtlich Probleme, die VDR-Version sauber zu erkennen. Folglich werdem beim Start keinerlei Plugins mitgestartet (weil ja die versionen nicht passen). Mache ich nach dem login ein manuelles "/etc/init.d/vdr restart" dann klappt es. Nun ist die Frage, warum mit dem neuen Kernel der Versionscheck beim booten schiefgeht, aber bei einem spaeteren Restart dann wieder funktioniert.

    Zitat

    Original von hummingbird_de
    Nein, das Plugin für "MRL" fehlt nicht. MRL heißt "Media Resource Locator", sprich die Stream-Addresse die Du ansprichst (127.0.0.1:37890). Ähnlich URL: http, ftp ....


    Dein vdr-sxfe versucht den Stream des MRL zu öffnen und stellt fest, das Format versteht er nicht bzw. hat dafür kein Plugin/Codec.


    Danke fuer deine unermuedliche Hilfe! Es scheint wohl so zu sein, dass vdr auf diesem Port nicht lauscht. Aber vdr selber laeuft, und im logfile schreibt er immer wieder dass er zB channel-namen aktualisiert. Es sheint wohl die server-Seite der xineliboutput ein Problem zu haben. Es tauchen aber keine Fehlermeldungen in /var/log/messages auf. Uebrigens habe ich eben bemerkt, dass der Fehler nicht immer auftritt. Von 5 Bootvorgaengen ging es 4 mal nicht und 1 mal ging es.

    Zitat


    In meinem o.a. HowTo habe ich z.B. wegen eines solchen Fehlers die Pakete " xineliboutput* " per /etc/apt/preferences gepinnt. Damit verhindere ich, das er "xineliboutput-fbfe/-sxfe" vom e-Tobi Repository nimmt. Diese passte nicht zur Xine-Version von Lenny, aber die aus dem Testing/Lenny Repository schon.


    xineliboutput compiliere ich eh selber (und ich habe auch daran gedacht, sie nach dem Kernel-Bau neu zu compilieren), daher sollte das schon passen.
    [code]

    Zitat

    Original von hummingbird_de
    Nun, unter Debian halte ich das für ein Gerücht. Debian-Way of Kernel-Build:

    Code
    #> aptitude install linux-source-2.6.18 kernel-package debianutils fakeroot libc6-dev libncurses5-dev gcc make
    #> cd /usr/src
    #> tar jxvf linux-source-2.6.18.tar.bz2
    #> cd linux-source-2.6.18
    #> cp /boot/config-2.6.18-5-k7 ./.config
    #> make menuconfig => Jetzt die Optionen anpassen und speichern
    #> make-kpkg --rootcmd fakeroot --append-to-version -k7-desktop --initrd kernel_image kernel_headers
    #> make-kpkg clean => Damit wird wieder einiges an Plattenplatz freigegeben

    Nach einer Zeit findest Du dann unter "/usr/src" die zwei Packages (linux-[image|headers].....deb). Diese kannst Du mit "dpkg -i" installieren und auch wieder entferen. Da die Header mitgebaut wurden funktioniert auch der "module-assistant". Hier nicht vergessen den Link "/usr/src/linux" auf das entsprechende Verzeichnis zu ändern.


    Habe das jetzt mal so versucht (allerdings kernel 2.6.22.9, da das die Kernel-Version bei Ubuntu ist). Kiste scheint tadellos zu booten (bis auf lirc, aber danach schaue ich spaeter) und vdr laeuft auch. Allerdings will vdr-sxfe damit nicht laufen. Es sieht so aus als ob ein Plugin fuer MRL nicht gefunden wird:


    Hat jemand eine Idee?

    Zitat

    Original von hummingbird_de
    Nun, unter Debian halte ich das für ein Gerücht. Debian-Way of Kernel-Build:


    Danke fuer den Hinweis. Das Problem ist halt nur, dass ich schon seit geraumer Zeit (noch bevor ich von suse auf debian gewechselt habe) dazu uebergegangen bin, meine Systeme automatisiert zu konfigurieren. Dazu habe ich mir eine Sammlung von perl-scripten geschrieben. Das Konzept ist aehnlich wie cfengine. Kernel-Compilierung will aber nicht so recht in dieses Konzept reinpassen.


    Zitat


    #> cd /usr/src
    #> tar jxvf linux-source-2.6.18.tar.bz2


    Hier ist einer der Knackpunkte: Wie finde ich (automatisiert) den exakten Dateinamen heraus um die Datei auspacken zu koennen? "dpkg -L linux-source" listet diese Datei zumindest nicht auf.


    Das naechste Problem ist, dass ich sicherheits-Updates automatisch mitinstallieren moechte.


    Das bedeutet, ich muss irgendwie merken, dass ein neuer Kernel verfuegbar ist, ohne ihn jedoch zu installieren. Stattdessen muss ich die source ziehen, patchen, und mein eigenes compilat installieren.


    Oder wuerde "apt-get update;apt-get upgrade" automatisch sowohl meinen kernel als auch den kernel-source durch den neuen ersetzen? Aber dann muesste ich wiederum wissen, wann ich die neue source auspacken/patchen/compilieren/installieren muss.


    Da du dich gut mit dem debian-way-of-life auskennst, waere es nett wenn du mir helfen koenntest etwas Licht in das Dunkel zu bringen (aber ich fuerchte, es wird langsam etwas OFF-topic ;)


    Zitat

    Da die Header mitgebaut wurden funktioniert auch der "module-assistant". Hier nicht vergessen den Link "/usr/src/linux" auf das entsprechende Verzeichnis zu ändern.


    So richtig verstehe ich noch nicht was ich mit module-assistant anfangen soll. Muss ich den neuen kernel erst booten bevor ich m-a verwende oder reicht der symlink?

    Zitat

    Original von wilderigel


    mein gutsy hat keine /etc/serial.conf, dafuer aber ne /var/lib/setserial/autoserial.conf die auch funktioniert.


    Mein gutsy hatte das auch nicht. So frech wie ich bin habe ich die einfach angelegt, da das ja in der manpage so drinsteht. /var/lib/setserial/autoserial.conf existiert bei mir auch, aber die habe ich garnicht angefasst (warum auch? die manpage sagt ja dass das in /etc/serial.conf muss). Und siehe da, bei mir hat es funktioniert. Versuch doch einfach mal /etc/serial.conf anzulegen. Wenn es nicht funktioniert kannst du ja immer noch weitersuchen.


    Ah! Das ist ja interessant! Die Kernel-Compiliererei wollte ich mir aber (zumindest auf Produktiv-Kisten) eigentlich ersparen, da ich so wenig wie moeglich an der Default-Installation aendern wollte. Jede Aenderung an der Default-Installation bringt IMHO langfristig (wenn man wieder auf eine aktuelle Distribution aufruesten will) eine Menge Aerger :(

    Hallo,


    Ich habe das Problem, dass nach dem Booten der erste Tuning-Versuch fehlschlaegt und der vdr kein Signal bekommt. Schalte ich auf einen anderen Kanal und wieder zurueck, geht alles problemlos.


    Dieses Problem habe ich sowohl bei debian (sarge) als auch bei ubuntu (gutsy) auf unterschiedlicher Hardware und sogar bei unterschiedlichen SAT-Installationen (mit unterschiedlichen Multischaltern) gesehen. Es scheint auch nicht wirklich VDR-spezifisch zu sein, da ich das auch schon bei anderen DVB-Applikationen beobachtet habe.


    Da das auch bei anderen Applikationen passiert, liegt der Verdacht nahe, dass es am Treiber oder an der Hardware liegt. Hardware moechte ich an dieser Stelle aber ausschliessen, da ich das schon bei 4 unterschiedlichen Installationen mit jeweils unterschiedlicher Hardware gesehen habe. Die einzige Gemeinsamkeit ist dass bei allen diesen Installationen mehrere Satelliten ueber 17->8 oder 17->16 diseqc-switche angefahren werden.


    Hat schon einmal jemand dieses Problem gesehen? Vielleicht hat auch jemand eine Idee, wie ich das naeher einkreisen kann?


    Ahja: Bislang habe ich sowohl TT-budget-S1200 (PCI) als auch TT-budget-S1400 (PCI) versucht. Beide haben den Philips saa4146 und stv0299.

    Zitat

    Die entscheidende Option scheint

    Code
    Option          "EnableAGPDMA" "true"


    zu sein. Damit sinkt die CPU-Belastung des vdr-sxfe bei mir (Ausgabe ueber VGA) von ca 40% auf ca 5..15%.


    Ich bin damit aber immer noch nicht so ganz gluecklich: Obwohl die CPU zu 75..85% vor sich hin-idle't, habe ich gelegentlich Haenger/Ruckler. Manchmal auch mehrere kurz aufeinanderfolgend. Hat jemand eine Idee woran das liegen koennte? Wuerde es Sinn machen dem vdr-sxfe echtzeit-Prio zu geben?

    Zitat

    Original von hummingbird_de
    Aber mal Hand aufs Herz, ich glaube die von Dir genannten Auflösungen betreffen nur die den S-Video & FBAS Ausgang, oder? Man benötigt an einem PC Monitor keinen Overscan, nicht?


    Soweit ich das sehe, macht der Treiber da keinen Unterschied zwischen TVout und VGA. Das betrifft auch overscan. Wenn ich das nicht einstelle, habe ich auch mit VGA bei manchen Sendern Streifen oben (wie ich in Budget auf Ubuntu Gutsy (7.10) beschrieben hatte).

    Zitat

    Original von OppTupacShakur
    hi, ich sitze grad an dem problem das wohl die einstellung in /var/lib/setserial/autoserial.conf
    /dev/ttyS1 uart none


    Setserial(8) auf ubuntu gutsy sagt aber, das muss in /etc/serial.conf. Damit funktioniert es hier auch. Seltsamerweise existiert hier /var/lib/setserial/autoserial.conf ebenfalls, wird aber offensichtlich nicht verwendet.


    BTW: aus https://help.ubuntu.com/community/Install_Lirc_Gutsy habe ich mir die wesentlichen Schritte beim lirc-debugging extrahiert:


    Code
    troubleshooting:
    1. modules loaded? (lirc_dev+lirc_serial for serial receiver)
    2. devices exist? (/dev/lirc, /dev/lirc0 or /dev/lirc/0)
    3. mode2 works?
    4. lircd.conf exist? (create with irrecord)
    5. lircd runs?
    6. check remote control with irw.
    7. learn remote with application (e.g. VDR)
    Zitat

    Original von hummingbird_de
    Ja, dazu gibt "Direct Memory Access"-Kanäle (DMA), damit Datentransfer keine CPU Zeit kostet.


    Dass DMA die CPU entlastet ist schon klar. Aber anhand all der Diskussionen um cle266 herum hatte ich bislang den Eindruck, dass die MPEG-Dekodierung den Haupt-Anteil der CPU verbraet.


    Zitat


    Die von Dir gewünschte Auflösung habe ich noch nie benötigt, aber ich würde mal die ein oder andere Suchmaschine ausserhalb dieses Portals bemühen. Ist eher kein VDR Problem.


    Diese Einschraenkung scheint schon im Treiber zu sein. Hier ein Ausschnitt aus via(4):



    Zitat


    1360x768 habe ich mit dem fglrx-Treiber und einer Radeon 9200 schon benutzt.


    fglrx wird den mpeg-decoder des cle266 wohl eher nicht unterstuetzen, oder?

    Zitat

    Original von hummingbird_de


    die Hardware-Beschleunigung wird durch xorg benutzt. Der ehemalige Unichrome-Treiber ist seit geraumer Zeit Teil von "xserver-xorg-video-via". Das funktioniert neben Debian Lenny, auch mit der Xorg-Version von Debian Etch :)


    Die entscheidende Option scheint

    Code
    Option          "EnableAGPDMA" "true"


    zu sein. Damit sinkt die CPU-Belastung des vdr-sxfe bei mir (Ausgabe ueber VGA) von ca 40% auf ca 5..15%.


    BTW: Mit dem xvmc Mode, der in via(4) erwaehnt wird, startet vdr-sxfe ueberhaupt nicht? Ist das normal?


    Ich wuerde nun gerne noch die Aufloesung auf 1920x1080 stellen, weil das die native Aufloesung des LCD-TV ist. Aber das scheint der Treiber wohl nicht zu unterstuetzen?

    Hallo,


    ich habe vdr auf ubuntu-gutsy installiert wie in Budget auf Ubuntu Gutsy (7.10) beschrieben. Mit dieser Konfiguration habe ich nun das Problem, dass nach einem Boot die Fernbedienung nicht funktioniert. Mache ich hingegen ein "/etc/init.d/vdr restart", dann funktioniert sie.


    Kann das daran liegen, dass (wegen upstart) vdr schon startet bevor lircd gestartet hat?


    Wenn ja, wie sage ich dem vdr dass er warten soll bis lircd bereit ist?

    Im Moment laeuft die Ausgabe ja ueber den VGA-Ausgang. Zur Ansteuerung eines LCD-TV (der demnaechst angeschafft werden soll) sollte das IMHO besser sein als ueber SCART, also wuerde ich das gerne so belassen. Andererseits wird der LCD-TV am VGA-Eingang vermutlich weder Formaterkennung noch Deinterlace machen. Liege ich mit dieser Vermutung richtig?


    Der (anzuschaffende) TV soll full-HD (also 1920x1080p) koennen. Macht es da Sinn das X11-Display auf ebendiese Aufloesung zu stellen? Oder waere es besser das X11-Display auf die PAL-Aufloesung zu stellen (meine budget-Karten koennen eh kein HD)?

    Zitat

    Original von Quo


    Zitat aus der C't:


    Alle Deinterlacing-Verfahren haben gemeinsam, dass die unterste Bildzeile ein mehr oder weniger störendes Flackern aufweist. Das lässt sich durch die Einstellung "Overscan" ändern. Bereits ein bis zwei Prozent Zoom lassen das Problem verschwinden.


    Die Streifen sind aber auch da wenn kein deinterlace aktiv ist.

    Zitat

    Original von joew
    Seltsamerweise geht transparentes OSD jetzt.


    OSD ist immer genau dann transparent, wenn fuer den eingeschalteten Kanal EPG-Informationen vorliegen. Liegen keine EPG-Informationen vor (zB weil gerade erst eingeschaltet wurde) so ist das OSD nicht transparent. Ist das wirklich so beabsichtigt? Mir scheint das eher ein Bug zu sein.


    Habe jetzt auch Autologin aktiviert. Jetzt startet vdr-sxfe im Vollbild-Modus und wenn ich "f" druecke, wird das Bild in ein normales Fenster verbannt und ich kann auf dem gnome-desktop arbeiten :-). IMHO ein optimaler Kompromiss zum WAF ;)


    Manchmal kommt es vor, dass die Fernbedienung nicht mehr tut. Dann hilft auch ein Restart von vdr-sxfe nicht, ich muss schon "/etc/init.d/vdr restart" sagen, damit die Fernbedienung wieder geht.


    Gibt es eine Uebersicht, welche interlace-Verfahren existieren und wie man sie aktiviert?

    Seltsamerweise geht transparentes OSD jetzt. Im Gegensatz zum Ton bin ich mir aber hier definitiv sicher, dass es vorher nicht ging und dass es nicht an der Verkabelung liegen kann. Ich habe auch nichts verstellt.


    Das Interlace scheint wohl daran zu liegen, dass /etc/vdr/plugins/plugin.xineliboutput.conf von vdr-sxfb nicht ausgewertet wird. Das muss man wohl auf der Kommandozeile uebergeben?


    Ahja: "vdr-sxfb --help" sagt leider nur einige Beispiele. Es sagt leider nicht, welche Methoden moeglich sind.

    Das mit dem Ton lag vermutlich an der Verkabelung. Es geht jetzt.


    Es stehen also im Moment noch 2 Probleme offen:
    - Striche oberhalb/unterhalb des Bildes
    - Deinterlace.
    - Ahja: es waere ganz angenehm, wenn man das OSD transparent schalten koennte.

    Zitat

    Original von kiwix
    Ich würde aber erstmal --local=none einstellen. VDR beim starten ganz normal als Dienst starten. An der Konsole anmelden und dann vdr-fbfe von Hand starten.


    Damit ist sichergestellt, dass der VDR Server an sich startet. Wenn das alles glatt läuft kann man in der conf ja wieder auf fbfe umstellen.


    Ja, das tut schon besser. Zwar tut vdr-fbfe immer noch nicht, aber immerhin kriege ich mit vdr-sxfb ein Vollbild und das OSD wird nicht mehr zerfetzt. Habe den Eingangsartikel entsprechend angepasst.


    Aber einige Nacharbeiten bleiben noch:


    - Ton geht nicht.
    - deinterlace tut nicht.
    - Bei den meisten Sendern sind oben und unten weisse Streifen zu sehen. Das sieht so aehnlich aus wie das Teletext in der Austastluecke beim analogen Fernsehen.