Beiträge von batDan

    Ich glaube nicht, zumindest hab ich da auch nichts rausgefunden bislang. Ich hab die Automatik ausgeschaltet, da ich recht selten Sendungen in 4:3 schaue. Aber nerven tut's schon.


    Den Fehler gibt es schon seit vielen Monaten (oder seit es die 4:3-Automatik gibt), unverständlich, dass das nie gefixt wurde. Weiss jemand, wo/wem man einen Bug Report senden könnte? Das wäre wohl nicht der erste, aber vielleicht erhält dann ein Bugfix dieses lästigen Fehlers höhere Priorität, wenn ihn viele melden...

    @ Roi: Meinst du mit Zucken, dass zwischendurch ein schwarzes Bild/Frame angezeigt wird? Das wäre ein Problem, das mit der 4:3/16:9-Erkennung zusammenhängt. Wurde schon mehrfach hier im Forum erwähnt, aber anscheinend gibt's dafür immer noch keinen Fix. Wenn man die Automatik in den Xineliboutput-Plugin-Preferences ausschaltet, dann kommt das nicht vor. Dummerweise sind dann 4.3-Inhalte verzerrt.

    Ich musste es manuell installieren, weiss nicht ob ich ein Problem in meiner sources.list (und config) habe oder Tobi in seinen Paketen. Schliesslich will apt-get dist-upgrade auch immer alle vdr-plugins updaten, obwohl dann immer nur die aktuelle Version mit genau derselben Version ersetzt wird...

    Ich hab zwar einen VDR unter Debian Squeeze mit Tobi's vdr-ng Paketen, aber mein VDR hat vor kurzem nach einem Systemupdate auch total gezickt und ich hab ihn erst nach einigem Rumprobieren wieder zum Laufen gebracht. Ein Blick in /var/log/messages zeigte, dass xineliboutput abschmierte, weil VDPAU nicht gestartet werde konnte. Ich habe zuerst alle NVidia-Treiber-Sachen und xinelib/VDPAU Pakete überprüft, aber die sahen alle korrekt aus, genau wie auf einem VDR-Client auf dem gleichen Softwarestand, auf dem alles lief. Ich habe dann in meiner Verzweiflung noch versucht, den entsprechenden NVidia-Treiber (mit der gleichen Version, nicht den aktuellsten!) manuell zu installieren (den .sh-Installer, den man bei NVidia runterladen kann), und siehe da, nachher lief alles! Keine Ahnung warum, ich dachte eigentlich, die vdr-ng-Pakete sollten reichen, aber vielleicht hat der Treiber-Installer irgendwas zurecht gerückt, was die Pakete nicht korrekt installiert haben...

    Danke Roi für die Infos zu vdr-addon-xbmc. Nachdem im Moment alles relativ gut läuft bei mir (ausser den gelegentlichen kurzen Tonaussetzern, für die anscheinend noch keine abschliessende Lösung gefunden wurde) wollte ich noch XBMC über das VDR-Menü Externe Player zum Laufen bringen. Dummerweise kann ich das Paket vdr-addon-xbmc nicht mehr installieren, auf meiner einen VDR-Installation wird es nicht gefunden, auf der anderen kommt folgende Meldung:


    Code
    batMedia:/# apt-get install vdr-addon-xbmc
    Paketlisten werden gelesen... Fertig
    Abhängigkeitsbaum wird aufgebaut       
    Status-Informationen einlesen... Fertig
    Paket vdr-addon-xbmc ist nicht verfügbar, wird aber von einem anderen Paket
    referenziert. Das kann heißen, dass das Paket fehlt, dass es veraltet
    ist oder nur aus einer anderen Quelle verfügbar ist.
    E: Paket vdr-addon-xbmc hat keinen Installationskandidaten


    (Die sources.list ist auf beiden identisch und sollte stimmen, ist gleich wie in der Anleitung bei sebald.com beschrieben, seltsam, dass es auf dem einen Rechner von einem anderen Paket referenziert wird. Hab ich da wohl irgend ein veraltetes Paket installiert...?)


    Tobi, gibt's vdr-addon-xbmc momentan oder gar nicht mehr?

    Ich komme leider seit längerer Zeit auf keinen grünen Zweig mit den vdr-ng-Paketen und Debian Squeeze. Eine längere Zeit lang lief VDPAU nicht (auch nicht wenn ich XBMC gestartet hab), keine Ahnung ob Pakete gefehlt haben oder irgendwelche veraltete Pakete installiert waren, die die aktuellen gestört haben. Nachdem ich einige Pakete entfernt und wieder neu installiert habe und inzwischen viele Squeeze-Pakete upgedatet wurden, läuft VDPAU nun wieder, zumindest wenn ich XBMC benutze. Wenn ich das lokale Frontend von VDR aktiviere, dann geht aber nichts, d.h. es wird nur ein komplett schwarzes Bild angezeigt und sogar das Streaming geht dann nicht, VDR läuft zwar, empfängt aber wohl keine richtigen Daten mehr. In /var/log/messages steht nach einem VDR-Restart dann folgendes:



    Dann folgt nur eine unendliche Liste von diesen unrecognised PES streams und eben, kein Bild, weder auf dem lokalen sxfe-Frontend noch per Streamdev.


    Wenn ich das lokale Frontend (in /etc/vdr/plugins/plugin.xineliboutput.conf --local=none) abschalte und VDR neu starte, dann funktioniert das Streaming per Streamdev wieder und im Log steht nichts mehr über nicht erkannte PES streams:


    Code
    Jun 12 11:47:01 batMedia vdr: [20482] [xine..put] Listening on address '127.0.0.1' port 37890 
    Jun 12 11:47:03 batMedia vdr: [20507] [xine..put] Listening on port 37890
    Jun 12 11:47:03 batMedia vdr: [20507] [xine..put] Listening for UDP broadcasts on port 37890 
    Jun 12 11:47:03 batMedia vdr: Libgcrypt warning: missing initialization - please fix the application 
    Jun 12 11:47:04 batMedia kernel: [35364.672114] dvb_ca adapter 0: DVB CAM detected and initialised successfully 
    Jun 12 11:47:11 batMedia vdr: [20517] [xine..put] Detected video size 720x576


    Ich verstehe dieses Problem (mit meinem begrenzten Hintergrundwissen) echt nicht, warum verhindert das aktivierte Frontend auch den (Streaming-) Empfang?


    Tobi (oder andere bei denen es unter Debian Squeeze amd64) läuft: Ev. würde es helfen, wenn du mal eine Liste aller Multimediapakete posten könntest, die bei dir bei einer laufenden Installation installiert sind, also alles was mit NVIDIA-Treiber, xineliboutput, vdpau, vdr usw. zusammenhängt. Ich denke einige der Probleme, die ich früher hatte, hingen mit Konflikten zwischen Paketen zusammen, also älteren, die inzwischen obsolet sind, aber nicht automatisch entfernt wurden durch dist-upgrade's. Ich denke eher nicht, dass ich die Konflikte selber verursacht habe, ich habe nämlich eine zweite VDR-Installation auf derselben Debian-Basis (als Client, ohne DVB-Karten), die problemlos funktioniert hat, bis ich apt-get dist-upgrade gemacht habe. Dort hab ich aber absichtlich nicht selber irgendwelche Pakete neu installiert oder entfernt, sondern nur die automatischen Updates laufen lassen. Mit der Folge, dass es jetzt genauso nicht funktioniert wie die Hauptinstallation...


    olneit00: Ich hab XBMC auch nie mit dem XBMC-addon zum Laufen gebracht. Ich hab's dann aufgegeben und manuell einen gdm gestartet und dort XBMC auf dem zweiten Display (vt9) laufen lassen...

    Ergibt:


    Code
    ii  nvidia-glx                           195.36.24-1~etobi1                   NVIDIA binary Xorg driver
    rc  nvidia-glx-dev                       195.36.24-1~etobi1                   NVIDIA binary Xorg driver development files
    rc  nvidia-kernel-2.6.26-2-amd64         173.14.09+3+lenny1                   NVIDIA binary kernel module for Linux 2.6.26-2-amd64
    ii  nvidia-kernel-2.6.32-trunk-amd64     195.36.24-1~etobi1+2.6.32-5          NVIDIA binary kernel module for Linux 2.6.32-trunk-amd6
    ii  nvidia-kernel-common                 20100216+3+nmu1                      NVIDIA binary kernel module common files
    ii  nvidia-kernel-dkms                   195.36.24-1~etobi1                   NVIDIA binary kernel module DKMS source
    ii  nvidia-kernel-source                 195.36.24-1~etobi1                   NVIDIA binary kernel module source
    rc  nvidia-libvdpau1-driver              190.53-0.1~etobi2                    NVIDIA vdpau driver
    ii  nvidia-settings                      190.53-1                             Tool for configuring the NVIDIA graphics driver
    ii  nvidia-vdpau-driver                  195.36.24-1~etobi1                   NVIDIA vdpau driver



    Dann ist wohl nvidia-libvdpau1-driver schuld? Wo kommt denn das nur her?

    Das alleine hat noch nichts bewirkt, die Fehlermeldung beim Starten des X-Servers kommt immer noch. So wie ich die interpretiere, hab ich ein altes NVIDIA-Treiberkernelmodul der Version 190.53 drinnen, das bei der Installation von nvidia-kernel-dkms mit der Version 195.36.24-1~etobi1 nicht entfernt oder ersetzt wurde. Ich kenne mich aber mit Kernelmodulen nicht aus, weiss nicht, wie ich das loswerde...

    Danke für den Tipp, das hat bezüglich den Updates geholfen. Allerdings wird selbst nach dem erfolgreichen dist-upgrade immer wieder angezeigt, dass die schon vorher betroffenen Plugin-Pakete aktualisiert werden sollen, er tauscht sie dann jeweils mit der genau gleichen Paketversion aus (merkt nicht, dass die aktuellen schon installiert sind).


    Code
    Die folgenden Pakete sind zurückgehalten worden:
      libboost-dev
    Die folgenden Pakete werden aktualisiert:
      vdr-plugin-epgsearch vdr-plugin-fritzbox vdr-plugin-live vdr-plugin-streamdev-client vdr-plugin-streamdev-server
    5 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.



    Leider hab ich aber trotzdem kein Bild, es gibt anscheinend ein Problem mit den NVIDIA-Treibern. Bei der Installation kam folgende Fehlermeldung:




    Und nachher lässt sich der X-Server nicht starten, in var/log/messages steht:


    Code
    May 16 12:31:43 batMedia kernel: [ 2452.857131] NVRM: API mismatch: the client has the version 195.36.24, but
    May 16 12:31:43 batMedia kernel: [ 2452.857132] NVRM: this kernel module has the version 190.53.  Please
    May 16 12:31:43 batMedia kernel: [ 2452.857133] NVRM: make sure that this kernel module and all NVIDIA driver
    May 16 12:31:43 batMedia kernel: [ 2452.857133] NVRM: components have the same version.



    Nachdem ich dann den NVIDIA-Treiber direkt von deren Website geladen und installiert hatte, ging zumindest gdm und XBMC wieder (ich benutze die PVR-Version, solange ich das sxfe-Frontend nicht wieder zum Laufen kriege, das stürzt zwar auch gelegentlich ab, aber es ist einfacher zu installieren als das ganze xinelib-Zeug...). Nach einem Neustart war aber anscheinend wieder das alte NVIDIA-Kernelmodul da und selbst gdm ging nicht mehr (gleiche Fehlermeldung).


    Weiss nicht, was da kaputt ist bei mir...

    Tobi: Hast du die Squeeze (amd64) Pakete tatsächlich schon neu compiliert? Ich bekomme bei dist-upgrade immer noch die Meldung, dass viele vdr-plugins nicht aktuell sind.


    batDan



    Die folgenden Pakete sind zurückgehalten worden:
    gstreamer0.10-plugins-bad libboost-dev libdirectfb-dev libdirectfb-extra libsdl1.2-dev libsdl1.2debian libsdl1.2debian-alsa mplayer vdr-plugin-epgsearch vdr-plugin-fritzbox vdr-plugin-live
    vdr-plugin-streamdev-client vdr-plugin-streamdev-server

    Tobi: Es hat dann bei mir wieder funktioniert nach Aktivierung des local frontend (nur das VDR Frontend in Gnome funktioniert nicht). Allerdings ging Deinterlacing überhaupt nicht, obwohl ich die Einstellungen (TVTime usw.) nicht verändert hatte, auch das automatische Aufziehen von 4:3 Letterbox auf 16:9 ging nicht mehr. Dafür das Rückspulen in Aufnahmen :-).


    Jetzt sehe ich jede Menge neue Pakete mit dist-upgrade, kann aber nicht updaten, da:


    Code
    Die folgenden Pakete sind zurückgehalten worden:
      libboost-dev vdr-plugin-epgsearch vdr-plugin-fritzbox vdr-plugin-live vdr-plugin-streamdev-client vdr-plugin-streamdev-server


    Gerade stremdev-server ist essentiell...



    thomas-f: Also für einen aktuellen VDR solltest du auf Squeeze updaten, die Lenny-Multimedia-Pakete sind hoffnungslos veraltert. Nachdem ich eine Weile lang stable und testing gemischt habe, wurde mir das zu mühsam, mit Squeeze hab ich weniger Probleme als vorher...

    Seit dem letzten Update kommt xineliboutput ein wenig weiter, zeigt zumindest ganz kurz ein Bild und den gerade eingestellten Sender, aber dann nach knapp einer Sekunde crasht er wohl und das Bild verschwindet. Im syslog steht wohl nichts, was das Verhalten aufklären könnte:



    Kurz vorher (wohl beim Restart des VDR) stand eine Fehlermeldung, weiss nicht ob die damit zu tun haben könnte:


    Code
    Apr 19 10:29:44 batMedia vdr: Libgcrypt warning: missing initialization - please fix the application



    Funktionieren bei euch diese aktuellen vdr-ng-Pakete richtig, geht xineliboutput-sxfe?


    Ich hab ein squeeze amd64 System.

    Zitat

    Originally posted by gandalf
    Bei mir reicht es vdr-sxfe neu zu starten, der vdr ist bei mir rockstable, der würde wahrscheinlich auch in 100 Jahren noch laufen wie am erste Tag!!


    Geht das mit killall vdr-sxfe? Startet es sich dann selber wieder neu? Dann müsste man es nur irgendwo in ein Menü oder als Befehl in VDR einbauen, sodass es "Wife-kompatibel" wird... Ich habe bislang den ganzen VDR neu gestartet (dumm wenn grad eine Aufnahme läuft...), weil ich nicht wusste, wie und was ich im "Wiedergabe-Teil" neu starten muss.


    Zitat


    Man kann. Ich habe das hier mal beschrieben.


    Danke für den Tipp, ich probiere mal, ob das meine Probleme löst.

    Wie schon erwähnt wurde, kann VDPAU mehrere Streams gleichzeitig dekodieren. Falls/wenn das stabil läuft, wird das die ideale Lösung sein. Ich persönlich will ein flüssiges PIP mit Truecolor, sonst verzichte ich lieber ganz auf ein PIP. Wenn das softwaremässig möglich ist, kauf ich mir auch ohne zögern eine neue NVIDIA Grafikkarte, falls eine schnellere notwendig ist.

    Ich glaube, dass die aktuelle Version von xineliboutput nicht richtig funktioniert. Bis vor das Update auf die momentan noch aktuelle Version lief mein vdr-ng-basierter VDR (ausser dass es nach einiger Zeit und mehreren Kanalumschaltungen zu einem Flackern mit schwarzen Frames zwischen dem Videobild kam, dass man nur durch einen VDR-Neustart beheben konnte).


    Seit dem letzten Update schmiert xineliboutput bei mir immer gleich ab, soweit ich gesehen habe, startet dann VDR ständig neu, muss aber noch die Fehlermeldungen genauer anschauen.

    Ich glaube eher, dass die aktuelle Version der xineliboutput-Pakete von e-tobi-ng Schuld ist. Bis vor das Update auf die momentan noch aktuelle Version lief mein vdr-ng-basierter VDR (ausser dass es nach einiger Zeit und mehreren Kanalumschaltungen zu einem Flackern mit schwarzen Frames zwischen dem Videobild kam, dass man nur durch einen VDR-Neustart beheben konnte).


    Seit dem letzten Update schmiert xineliboutput bei mir auch immer gleich ab, mit wohl den gleichen Fehlermeldungen. Hoffentlich liefert Tobi bald ein Update nach. Weiss gar nicht, wie man xineliboutput (reicht das VDR-Plugin?) selber kompilieren könnte und dasjenige aus dem Paket ersetzen und ob das was bringen würde...

    Bei mir brach make zuerst auch mit einem Fehler ab. Ich musste make clean machen, danach ging es. Ausserdem hatte ich zuerst wie hier im Thread empfohlen die zwei Dateien passend zum Kernel (32/64 Bit) mit "ln -s ..." verlinkt, da kam ein Fehler, also hab ich sie kopiert wie im README beschrieben:


    - for x86 kernel (x86 32 bit installations of Linux):


    # cp v4l/tbs6980ctrl.o.x86 v4l/tbs6980ctrl.o
    # cp v4l/tbs6980fe_driver.o.x86 v4l/tbs6980fe_driver.o


    - for x86_64 kernel (x86 64 bit installations of Linux):


    # cp v4l/tbs6980ctrl.o.x86_64 v4l/tbs6980ctrl.o
    # cp v4l/tbs6980fe_driver.o.x86_64 v4l/tbs6980fe_driver.o


    Hast du übrigens die Kernel-Sourcen installiert?


    Weiss nicht warum, aber auf jeden Fall ging es im dritten Anlauf. Verwende allerdings e-Tobis vdr-ng Repository unter Debian Squeeze.

    Super! Aber zuerst muss man das anscheinend in einem seltsamen Format gespeicherte Archiv entpacken können... Dies funktioniert bei mir nicht:

    Code
    wget http://www.buydvb.net/download2/TBS6980/linux-s2api-tbs6980_v1.54.tar.bz2
    tar xjvf linux-s2api-tbs6980_v1.54.tar.bz2
    bzip2: (stdin) is not a bzip2 file.
    tar: Child returned status 2
    tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler


    Edit: Ich hab's rausgefunden, ist ein falsch benanntes RAR-Archiv:


    unrar x linux-s2api-tbs6980_v1.54.tar.bz2