Posts by wfaust

    Hier mal eine Beschreibung wie man WLAN inkl. wicd GUI in der yaVDR Sidebar und VDR Applikationsmenü zum laufen bringen kann.


    Achtung: Ich empfehle zuerst wpa_gui anstatt wicd zu versuchen. wpa_gui ist kein Netzwerk Manager wie wicd, reicht aber in den meisten Fällen vollkommen aus. wicd ist nicht immer unproblematisch, da teilweise langsam und nicht immer ohne Macken (siehe unten). wicd empfiehlt sich eigentlich nur dann, wenn dauernd zwischen mehreren Netzwerken gewechselt wird, wer hotplugging usw. braucht oder aber per ssh Zugang mittels wicd-curses alles einstellen will - eben halt einen vollwertigen Netzwerk Manager braucht. In den meisten Fällen ist wohl wpa_gui schneller, schlanker und leichter zu debuggen.


    Ein Tutorial für die wpa_gui Installation hatte ich gerade gepostet unter: http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/111254-tutorial-wlan-mit-wpa-gui-inkl-sidebar-vdr-applikationsmenü-installieren/


    Zur Info: Ich habe alles auf einem Zotac ND22 HTPC mit rt2x00 WLAN Treiber ausprobiert, aber die Beschreibung sollte mit vielen anderen WLan Treibern klappen.


    • Es sollten keine anderen Network Manager zusätzlich installiert sein, es
      sei denn, Ihr wisst, was Ihr tut. Desweiteren gehe ich davon aus, daß
      man in einem Terminal mittels "sudo su" als root user eingeloggt ist.
    • WLan und wicd Software installieren. Zur Info: wicd wird über wicd-gtk oder wicd-curses kontrolliert/eingestellt. Inbesondere bei einem ssh Fernzugriff kann wicd-curses recht praktisch sein.

      Code
      1. apt-get update
      2. apt-get install wireless-tools
      3. apt-get install wpasupplicant
      4. apt-get install wicd wicd-curses wicd-gtk


      Achtung: bei der wicd Installation den yaVDR User gemäß der Anfrage der netdev Gruppe zuordnen. Mein User heißt "medusa", was weiter unten noch eine Rolle spielen wird. "medusa" müßt Ihr also überall hier durch Euren Usernamen ersetzen. Manchmal ist es bei der Installation schwer zu erkennen, ob ein User der netdev Gruppe zugeordnet wird oder nicht. Daher der Hinweis, daß standardmäßig der User nicht zugeordnet wird und man mittels Leertaste die Option einschalten muß. Sollte man sich nicht sicher sein, kann mit "adduser medusa netdev" der User aber auch noch später der netdev Guppe zuordnen.


      Wer unter Linux problematische WLan-Hardware hat, sollte evtl mit "uname -r " nachschauen, welchen Kernel er hat und die passenden backport wlan Treiber installieren. Die verfügbaren backport Module werden nebenbei mit

      Code
      1. apt-cache search linux-backports-modules


      angezeigt. Mein yaVDR Kernel war 2.6.38-13 und ich habe daher folgende Backport Module installiert (der orig. 2.6.38-13 Treiber lief hier aber auch stundenlang ohne Probleme):

      Code
      1. apt-get install linux-backports-modules-cw-3.0.0-2.6.38-13-generic


      Ich würde es aber zuerst ohne backport module probieren. Sollte es Probleme geben oder überhaupt kein Treiber für das WLan Modul vorhanden sein, kann man einfach später noch die wlan Module nachinstallieren.

    • Da wicd alle Netzwerkverbindungen verwaltet, sollte die Datei /etc/wpa_supplicant/wpa_supplicant.conf nicht angelegt werden und auch in /etc/network/interfaces sollte nur

      Code
      1. # The loopback network interface
      2. auto lo
      3. iface lo inet loopback


      vorhanden sein. Der bei mir während der yaVDR Installation angelegte eth0 Eintrag hat nicht gestört, doch wer sicher gehen will, raus damit.

    • Jetzt fügen wir wicd-gtk der Sidebar von yaVDR hinzu. Um das Updatesicher hinzubekommen, muss ein entsprechendes yaVDR Template erstellt und verarbeitet werden:

      Code
      1. mkdir -p /etc/yavdr/templates_custom/etc/wmdrawer/web/
      2. echo "(wicd WLAN Konfigurieren) (wicd-gtk.xpm) (/usr/share/vdr/menuorg-appswitcher standalone=no app=wicdgtk)" >/etc/yavdr/templates_custom/etc/wmdrawer/web/12_wicdgtk
      3. chown root:root /etc/yavdr/templates_custom/etc/wmdrawer/web/*
      4. chmod 644 /etc/yavdr/templates_custom/etc/wmdrawer/web/*
      5. process-template /etc/wmdrawer/web


      Der aufgerufene Upstart Service wicdgtk muss noch erstellt werden. Ich habe dazu die firefox.conf Datei in /etc/init als Vorbild genommen und mit

      Code
      1. cp -p /etc/init/firefox.conf /etc/init/wicdgtk.conf


      kopiert und anschliessend /etc/init/wicdgtk.conf etwas angepasst. Wie beschrieben, mein yaVDR User heißt medusa. Ihr müßt also medusa in der Zeile mit "exec su ..." auf Euren Usernamen ändern:


    • Jetzt fügen wir wicd-gtk auch noch dem Applikationsmenü in VDR hinzu. Wieder bemühen wir yaVDR Templates um alles sicher für Updates zu machen:

      Code
      1. mkdir -p /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml


      Dann mit

      Code
      1. nano /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/20_12_wicdgtk


      eine Datei mit der folgenden Zeile als Inhalt erstellen:

      Code
      1. <command name=<?cs call:quote(_("wicd WLAN Konfiguration")) ?> execute="/usr/share/vdr/menuorg-appswitcher standalone=no app=wicdgtk &amp;> /dev/null " />


      Die Zugriffsrechte einstellen mit

      Code
      1. chown root:root /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*
      2. chmod 644 /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*


      Und aktivieren:

      Code
      1. stop vdr
      2. process-template /var/lib/vdr/plugins/menuorg.xml
      3. start vdr

    Sodele, wenn alles richtig ist, solltet Ihr nach einem Reboot in der yaVDR Sidebar bzw. im VDR Applikationsmenü wicd-gtk aufrufen können. Auch das automatische Umschalten auf ein kabelgebundendes Netzwerk klappt bei mir scheinbar problemlos. Wer per Terminal eingeloggt ist, kann auch wicd-curses anstatt wicd-gtk aufrufen.


    Bei mir gab es allerdings auch kleine Probleme, die ich hier nicht verschweigen möchte:


    Beim ersten Start von wicd-gtk wurden mir scheinbar keine SSIDs von vorhandenen WLAN Netzen zur Auswahl/Konfiguration angezeigt. Es kann etwas dauern, bis wicd-gtk die vorhandene WLAN Netze anzeigt, also Geduld. Evtl. hilft auch ein Klick auf Refresh (erscheint erst nach dem ersten erfolglosen SSID Scan). Voraussetzung ist naklar auch, daß der installierte WLAN Treiber überhaupt funktioniert. Wer Probleme hat, sollte es jetzt evtl. mit den backport Modulen probieren (siehe oben).


    Ein weitere Problem bei mir war, daß nach einem Reboot sich wicd meistens mit dem falschen SSID Netz verbinden wollte, daß nicht mehr verwendet werden soll. Ich habe zwei APs und nach einem Reboot versuchte sich wicd oft beim falschen ehemals verwendeten SSID Netz einzuloggen und trotz Fehler wegen fehlendem Passwort hat er es dann nicht einfach weiter bei dem zweiten richtigen Netz versucht. Abhilfe brachte hier, für das nicht gewünschte SSID Netz in wicd ein falsches Password anzugeben und dann nicht automatisch verbinden zu lassen. Komischerweise muss man wohl irgendein Passwort angeben, damit man sich nicht automatisch verbinden lassen kann, da wicd sonst die Einstellungen nicht abspeichert. Abhilfe kann auch das manuelle Löschen eines alten Netzes aus /etc/wicd/wireless-settings.conf schaffen. wicd speichert die wlan Zugangsdaten in dieser Datei.


    Auch ist es oft kaum möglich zu erkennen, ob in der wicd-gtk GUI eine Option ein- oder ausgeschaltet ist. Hier kann es durchaus sinnvoll sein, in einem Terminal wicd-curses anstatt wicd-gtk aufzurufen.


    Nach einem Neustart des System kann es 2-3 Minuten dauern, bis wicd mittels WLAN den Rechner verbunden hat. wicd ist also nicht gerade schnell.


    Wenn weiter keine SSIDs in wicd-gtk angezeigt werden, dann hat man vermutlich ein Problem mit dem WLAN Treiber und sollte es erst einmal von Hand entsprechend der Beschreibung auf


    http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/93996-gelöst-wlan-aktivieren/


    Oder die detaillierten Beschreibung auf der Ubuntu wiki Website versuchen:


    http://wiki.ubuntuusers.de/wlan

    [Editiert: Dank abgeänderten Punkt 4 jetzt für yaVDR 0.4-0.61 geeignet]


    Ich hatte hier schon diverse Beschreibungen zur Installation von WLAN und yaVDR 0.4 und 0.5 gelesen. Es fehlte aber eine Beschreibung, wie man WLAN inkl. GUI gut in yaVDR installiert. Hier mal meine Installation inkl. wpa_gui in der Sidebar und dem VDR Applikationsmenü. Wer unbedingt einen Netzwerk-Manager wie wicd fürs WLAN haben will, der findet unter http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/111297-tutorial-wlan-mit-wicd-netzwerk-manager-inkl-sidebar-vdr-applikationsmenü-zugriff-installieren/ eine ähnliche Installationsanleitung von mir.


    Zur Info: Ich habe alles auf einem Zotac ND22 HTPC mit rt2x00 WLAN Treiber ausprobiert, aber die Beschreibung sollte mit vielen anderen WLan Treibern klappen.


    • Es sollten keine anderen Network Manager zusätzlich installiert sein, es sei denn, Ihr wisst, was Ihr tut. Desweiteren gehe ich davon aus, daß man in einem Terminal mittels "sudo su" als root user eingeloggt ist.
    • WLan und wpagui Software installieren:

      Code
      1. apt-get update
      2. apt-get install wireless-tools
      3. apt-get install wpasupplicant
      4. apt-get install wpagui


      DIe Pakete wpasupplicant und wireless-tools sind bei yaVDR 0.5 meistens schon installiert. Wer unter Linux problematische wlan-Hardware hat, sollte evtl mit "uname -r" nachschauen, welchen Kernel er hat und die passenden backport wlan Treiber installieren. Die verfügbaren backport Module werden nebenbei mit

      Code
      1. apt-cache search linux-backports-modules


      angezeigt. Mein yaVDR Kernel war 2.6.38-13 und ich habe daher folgende Backport Module installiert (der orig. 2.6.38-13 Treiber lief hier aber auch stundenlang ohne Probleme):

      Code
      1. apt-get install linux-backports-modules-cw-3.0.0-2.6.38-13-generic


      Ich würde es aber zuerst ohne backport Module probieren. Sollte es Probleme geben oder überhaupt kein Treiber für das WLan Modul vorhanden sein, kann man einfach später noch die wlan Module nachinstallieren.

    • Ihr mußt Euren User Account ("medusa" durch Euren Usernamen ersetzen) der netdev Group zuordnen:

      Code
      1. adduser medusa netdev


    • In /etc/network/interfaces sollten folgende Zeilen für das wlan hinzugefügt werden:


      Ein Hinweis: Wer wie ich kein WLAN aktivieren will, wenn der Rechner per Netzwerkkabel via eth0 verbunden ist, der kann unter "iface wlan0 ..." eine weitere Zeile mit

      Code
      1. pre-up /sbin/ip link | /bin/grep -q 'eth0:.*state.*DOWN'

      hinzufügen. Dies verhindert ein Aktivieren von wlan0 bei funktierendem eth0. Solange man nach dem Start des Rechners nicht zwischen eth0 und wlan0 wechseln will, reicht dies. Wer hotplugging von eth0/wlan0 haben will, braucht also mehr als nur diese eine Zeile. Leider ist bei ausgeschalteten wlan0 auch wpa_gui funktionsunfähig. Wer also einen WLAN Zugang mittels wpa_gui konfigurieren will, muß dann das Netzwerkkabel beim Booten abgezogen haben.


      Achtung: Bei dem von yaVDR 0.6 verwendeten Ubuntu 14.04 gibt es ein Problem, wenn man die interfaces Datei wie oben beschrieben erweitert. Ubuntu braucht über zwei Minuten länger zum Booten und zeigt dabei unter anderem ""Waiting for network configuration" auf dem Bildschirm. Desweiteren kann es passieren, daß das Webconfig nicht mehr erreichbar ist. Das Problem taucht u.a. immer dann auf, wenn ein per iface angegebenes Device nicht sofort funktioniert, was bei dhcp und wlan mit WPA fast immer der Fall ist. Die Lösung ist, anstatt auto allow-hotplug anzugeben. Hier eine Beispiel einer /etc/network/interfaces Datei für yavdr 0.6:


      Wer dennoch warten muss, weil er ein anderes Network Setup hat, kann die Wartezeit z.B. durch das Entfernen/Verringern der sleep Befehle in /etc/init/failsafe.conf erreichen. Wenn das Webconfig nicht erreichbar ist, kann es hilfreich sein, den start von tntnet bis zu einer funktionierenden Netzwerkverbindung zu verzögern. Dies kann man z.B. durch das Erstellen einer Datei /etc/init/wait-for-tntnet.conf mit folgenden Inhalt erreichen:


      Das Script verzögert den Start von tntnet eine Weile bzw. bis google.de (durch eigene Routeradresse erestzen) angepingt werden kann.

    • Erstellt die Datei /etc/wpa_supplicant/wpa_supplicant.conf
      mit folgenden zwei Zeilen:

      Code
      1. ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
      2. update_config=1


      und setzt die Zugriffsrechte:

      Code
      1. chown root:netdev /etc/wpa_supplicant/wpa_supplicant.conf
      2. chmod 770 /etc/wpa_supplicant/wpa_supplicant.conf


    • Rebootet das System. Die ifconfig Ausgabe sollte jetzt wlan0 auflisten, wobei iwconfig anzeigt, dass daß wlan0 noch nicht mit einem AP verbunden ist. Dazu fehlt ja noch das Passwort u.a.m., welches wir später mit wpa_gui erstellen. Sollte kein wlan0 auftauchen, kontrolliert ob Ihr einen funktionierenden wlan Treiber habt. Installiert evtl. die backport Module.
    • Jetzt fügen wir wpa_gui der Sidebar von yaVDR hinzu. Um das Updatesicher hinzubekommen, muss ein entsprechendes yaVDR Template erstellt und verarbeitet werden:

      Code
      1. mkdir -p /etc/yavdr/templates_custom/etc/wmdrawer/web/
      2. echo "(wpa_gui WLAN Konfigurieren) (wpa_gui.xpm) (/usr/share/vdr/menuorg-appswitcher standalone=no app=wpagui)" >/etc/yavdr/templates_custom/etc/wmdrawer/web/12_wpagui
      3. chown root:root /etc/yavdr/templates_custom/etc/wmdrawer/web/*
      4. chmod 644 /etc/yavdr/templates_custom/etc/wmdrawer/web/*
      5. process-template /etc/wmdrawer/web


      Der aufgerufene Upstart Service wpagui muss noch erstellt werden. Ich habe dazu die firefox.conf Datei in /etc/init als Vorbild genommen und mit

      Code
      1. cp -p /etc/init/firefox.conf /etc/init/wpagui.conf


      kopiert und anschliessend /etc/init/wpagui.conf etwas angepasst. Bei mir wird wpa_gui als User medusa ausgeführt. Ihr müßt also medusa in der Zeile mit exec su auf Euren Usernamen ändern:


    • Jetzt fügen wir wpa_gui auch noch dem Applikationsmenü in VDR hinzu. Wieder bemühen wir yaVDR Templates um alles sicher für Updates zu machen:

      Code
      1. mkdir -p /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml


      Dann mit

      Code
      1. nano /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/20_12_wpagui


      eine Datei mit der folgenden Zeile als Inhalt erstellen:

      Code
      1. <command name=<?cs call:quote(_("wpa_gui WLAN Konfiguration")) ?> execute="/usr/share/vdr/menuorg-appswitcher standalone=no app=wpagui &amp;> /dev/null " />


      Die Zugriffsrechte einstellen mit

      Code
      1. chown root:root /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*
      2. chmod 644 /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*


      Und aktivieren:

      Code
      1. stop vdr
      2. process-template /var/lib/vdr/plugins/menuorg.xml
      3. start vdr
    • Das wars. Ihr solltet jetzt wpa_gui in der yaVDR Sidebar oder im VDR Applikationsmenü aufrufen können und nach vorhanden wlan Netzen suchen/konfigurieren können.
      Falls alles nicht gefruchtet hat und keine Netze in wpa_gui angezeigt werden, dann hat man vermutlich ein Problem mit dem WLAN Treiber und sollte es erst einmal von Hand entsprechend der Beschreibung auf


      http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/93996-gelöst-wlan-aktivieren/


      Oder der detaillierten Beschreibung auf der Ubuntu wiki Website versuchen:


      http://wiki.ubuntuusers.de/wlan


      Wer sich mit Netzwerken verbinden kann, aber keine IP Adresse per dhcp bekommt, der hatte evtl. vorher wie ich wicd oder einen anderen Manager installiert und nicht rückstandsfrei entfernt?

    Für weitere Verbesserungsvorschläge bin ich immer offen :D

    Ich habe hier zwei 1TB (F1?) Samsung Platten an meinem Ct VDR Rechner und einem OpenSuse Rechner per SATA angeschlossen.
    Bei den Samsung Platten kann ich hier mit "hdparm -S 120 /dev/sdb" das Standby auf 10 Minuten setzen und die Platte macht auch nach 10 Minuten Inaktivität den Spindown, doch nachdem die Platte einmal aus dem Spindown wieder aufgeweckt wurde, ist die hdparm Einstellung in der Platte gelöscht und muss erneut erfolgen.


    Ich habe daher folgenden Eintrag in /etc/crontab hinzugefügt:


    15,30,45,59 * * * * root /usr/bin/usbhdstandby


    Desweiteren habe ich das Script in /usr/bin/usbhdstandby mit folgenden Befehlen angelegt:



    Das Script schaut mittels hdparm -C alle 15 Minuten nach, ob die Festplatte aktiv ist und falls ja, schickt das Script den 10 Min Standby Befehl. Der Befehl darf nur geschickt werden, wenn die Platte aktiv ist, da die Platte sonst von dem Befehl aufgeweckt wird. Wenn die Platte also in den 15 Minuten zwischen den zwei Script Aufrufen für mindestens 10 Minuten nicht genutzt wird, geht die Platte schlafen.


    Achtung: Ich habe das Scipt nicht mit yaVDR getestet. Prüfe ob die Platte durch manuelles Aufrufen von hdparm schlafen geht und ob hdparm -C auch wirklich korrekt anzeigt, dass die Platte aktiv ist bzw. schläft. Da gab es bei einigen hdparm Versionen falsche Anzeigen (es wurde fälschlich immer active angezeigt), weshalb ich z.B. bei ct VDR erst ein aktuelles hdparm selbst kompilieren musste. Und abschliessend leider noch der Kommentar, dass auch Samsung gerne an der Firmware bastelt und es durchaus sein kann, dass es mit Deiner F4 Samsung Platte nicht klappt. Ein Grund, weshalb ich mir gerne externe eSATA+USB Platten von den Festplatten-Herstellern kaufe, da dort eigentlich immer ein ordentliches Standby dabei ist. Vorsicht ist da eigentlich nur bei externen Seagate Platten angesagt, da hier oft erst unter /sys allow_restart auf 1 gesetzt werden muss, damit das Standby zumindest bei USB ordentlich klappt. Ansonsten stehen bei vielen modernen Platten die Chancen eher schlecht, ein ordentliches Standby bei fremden USB-Gehäusen hinzubekommen. Die wenigsten Platten können sich leider dazu heute meistens die hdparm -S Einstellung nicht dauerhaft merken und auch bei SATA Anschluss wird es immer schwieriger ein 3,5" Laufwerk mit Standby Support zu finden, wenn man nicht gerade ein Stromsparmodell nimmt...


    Ob die Platte ntfs oder ext formatiert ist, sollte eigentlich egal sein, da die Platte von selbst beim Zugriff aufwacht. Probleme gibt es nach meiner Erfahrung eigentlich immer nur dann, wenn doch irgendwo ein timeout bei einem der höheren Zugriffslayer (Anwendung,...) auftritt (bei mir der WDTV Netzwerkzugriff via NFS - während CIFS anstatt NFS kein Timeout Fehler erzeugt).

    Fireblade


    Deine Aussage hilft keinem weiter. Die meisten Receiver<->TV Kombinationen funktionieren sicherlich problemlos und keiner behauptet, dass das Problem mit jeder Receiver/TV Kombination auftritt. Im Gegenteil, das Problem ist glücklicherweise auf wenige Geräte beschränkt. Bei Onkyo Receivern sind einige 8xx/9xx Modelle mit eingeschalteten Scaler in Kombination mit einigen Samsung TV Modellen betroffen (eine genaue Ursachenbeschreibung des Problems ist im Netz zu finden). Bei Denon sind wohl auch einige Receiver/TV Kombinationen problematisch. Fang einfach mal an nach HDMI Problemen und deren Ursachen zu suchen und Du wirst finden ;-)


    Desweiteren kann er jetzt ein besseres Kabel kaufen, doch was macht er, wenn dies nicht hilft? Da würde ich doch eher den Repeater als erste Wahl vorziehen. Liegt es am Kabel, dürfte der Repeater genug Reserven schaffen, damit auch das alte Kabel geht. Liegt es aber nicht am Kabel, dürfte nur der Repeater helfen. Aber wer weiss, vielleicht wird das Problem beim zurückgeschickten TV behoben....

    q-reiter


    wie gesagt, die Probleme sind bekannt und wenn Du nach NVidia<->TV und inbesondere Receiver <-> Samsung TV Verbindungsproblemen suchst, wirst Du fündig. Ich pers. hatte mit billigen 2m HDMI Kabeln noch keine Probleme, aber alles über 2m war hier durchaus bei >=1080p50 problematisch. Von drei billigen 3m Kabeln hat hier nur eines bei 1080p50 funktioniert, wobei inbesondere die nVidia PC Ausgabe an den Onkyo Receiver sehr empfindlich für schlechte Kabel war. Dennoch vermute ich nicht, dass Du bei 2m ein Kabelproblem hast. Meistens sehen die Symptome dann auch etwas anders aus (entweder wird die Verbindung erst garnicht aufgebaut, oder es gibt eben auch im normalen Bild kleinere sichtbare Fehler).


    Daher mein Tipp, probiere einen aktiven Repeater. Mit dem Teil funktionieren dann auch billigere längere Kabel meistens problemlos und kostet ähnlich viel wie ein hochwertiges kurzes Kabel. Ich habe ein Teil, dass genauso aussieht wie das "Clicktronic HC 55P" und ich hatte es damals wegen der vielen positiven Erfahrungen anderer User mit dem Teil bei www.radiostore.de gekauft. Das Teil wird auch von anderen unter der Modellbezeichnung "C 233 L" günstiger verkauft. Auf meiner blauen Verpackung steht nur "C233L", "all 4 u" und "Home Cinema Systems" als Hinweis auf den Hersteller/Modell. Achtung: Darauf achten, dass wirklich ein Netzteil dabei ist, da es oft auch ohne verkauft wird und nur mit angeschlossenen Netzteil hat es bei vielen Usern geklappt. Inzwischen scheint Radiostore das Teil nicht mehr anzubieten. Stattdessen gibt es einen wesentlich günstigeren "Repeater mit separater Stromversorgung HDMI 1.3b" fuer Euro 24,62. Angesichts des günstigeren Preises ein Versuch wert...


    Ich hatte zwei Repeater gekauft, da ich auch ein 25m billiges Kabel einsetzen wollte. Letztlich hat aber schon ein Repeater gereicht, damit ich hier selbst 1080p60 problemlos über 25m zwischen einem Onkyo Receiver und Samsung TV hinbekomme. Nur um klazustellen: Die Vebindungsprobleme mit schwarzem Bildschirm für 1-2s hatten hier nichts mit dem langen Kabel zu tun. Habe also noch ein Teil übrig, falls Du es damit probieren willst...

    Für mich hört sich das nach einem eher typischen Synchronisationsproblem zwischen PC und TV an. Die Ursache liegt manchmal an einem schlechten Kabel, aber wenn das Kabel nicht zu lang (<1,5m) und auch ansonsten das Kabel gut mit anderen Geräten bei gleichem Bildschirmmodus funktioniert, tippe ich eher auf ein grundsätzlichen Kommunikationsproblem zwischen PC und TV. Dann kommt es zu Verbindungsabbrüchen und die Verbindung zwischen PC und TV muss neu aufgebaut werden, was den TV 1-2s schwarz schaltet. Das Problem kann durchaus auch sehr eng mit einem Bildschirmmodus zusammenhängen, weshalb es evtl. nur in VDR und nicht in XBMC auftritt, wenn sich die Bildschirmmodi unterscheiden.


    Ich hatte hier inbesondere mit einem Samsung 55B7020 erhebliche Probleme. Bei Bandbreiten >= 1080p50 gab es öfters den schwarzen Bildschirm. Neben PC<->TV Verbindungen sind derartige Probleme besonders oft zwischen diversen Receivern und einigen TV Herstellern zu finden (z.B. die Onkyo Receiver und Samsung TVs).


    Abhilfe schafft meistens der Einsatz eines aktiven HDMI Repeaters (kostet ca. 30 Euro). Es ist wichtig dabei, daß der HDMI Repeater sein eigenes Netzteil hat und das Handshake zwischen TV und PC selbst erledigt und nicht einfach nur das Signal verstärkt weiterleitet. Aktive Verstärker ohne Netzteil wie man sie teilweise in HDMI Kabel eingebaut findet funktionieren nach meiner (und anderen Usern) daher eher nicht. Es hat mich viele Stunden und viel Geld für Kabel gekostet, herauszufinden dass mir ein billiger Repeater alle Probleme vom Hals schafft....

    Seit dem yavdr 0.3 xbmc Update vor einigen Tagen werden bei mir
    keine Verzeichnisse mehr mit AVCHD Daten erkannt und gescrapped.
    Es sieht so aus, also ob sämtliche Scrapper einfach über Verzeichnisse mit
    AVCHD Daten hinwegspringen. .nfo Dateien in den BDMV/STREAM Verzeichnissen werden ebenso ignoriert.


    Ein Bug? Oder habe ich da was verpasst? Online habe ich nichts gefunden.
    Dies scheint ein yavdr spezifisches Problem zu sein!?

    Nach Ausführung von dist-upgrade habe ich gerade ein neues xbmc update
    reingespielt bekommen. Leider sind danach die Einstellungen zur Anbindung
    an VDR weg. Ich bekomme also z.B. kein TV mehr in xbmc angezeigt.


    Ich habe nach dem update, sowohl als root, als auch als vdr user das
    /usr/bin/update-xbmc-dharma-pvr.sh Script vor dem ersten Start von xbmc aufgerufen.


    Habe ich da was falsch gemacht, oder sind die Einstellungen einfach mit der
    neuen Version nicht mehr möglich? Irgendeine Idee, wie ich die
    Einstellungen, sofern vorhanden, wieder installieren kann?

    XBMC manuell starten? Wie? "start xbmc" oder "xbmc --standalone" funktioniert nicht... egal ob als root oder vdr user. Ich habe noch nicht so ganz verstanden, wie yavdr 0.3 Bildschirm, fronends usw. managed. Reicht ein einfaches "stop vdr" vor dem XBMC Aufruf?


    Auch bei mir funktionieren die Scraper bei yavdr 0.3 nicht mehr. Alles lief sehr gut unter 0.2 . Der OFDB Scraper hängt sich wie hier beschrieben schnell auf. Das Problem schein nicht auf den OFDB Scraper beschränkt. Auch andere Scraper hängen und lassen sich nicht mehr abbrechen.


    Da auch ich den Eindruck habe, dass hier die XBMC Version das Problem ist und nicht die Scraper, gibt es irgendwo eine Quelle für neuere XBMC Version? Wenn ich das richtig mitbekommen habe, werden bei yavdr normal nicht XBMC Updates ausgeliefert?

    Ich hatte Schnee in dunklen Bereichen schon in 0.2. Betraf nur dunkle Stellen und auch nur dann, wenn ein Film via vdr oder xbmc lief. Das xbmc Menu war auch bei dunklen Stellen schneefrei. Ich hatte daher auch ein Problem im Zusammenhang mit vdpau vermutet.


    Ich habe diverse kurze und lange Kabel versucht.


    Ich habe es mal mit und ohne Onkyo 875 Verstärker zwischen PC und Fernseher versucht (und auch beim Onkyo dann diverse Settings probiert)


    Ich habe neben der onboard Grafik (Asus M4N78 Pro) auch eine GT220 probiert.


    Ich habe es mit ohne video studio levels probiert (nebenbei: die studio-level Einstellung funktioniert bei mir beim Abspielen von MPEG2 in xbmc nicht richtig... aber h264 geht... da hat wohl jemand noch was vergessen ;-).


    Alles ohne Erfolg. Zu meiner völligen Überrraschung kam die Abhilfe dann von einem aktiven HDMI Repeater mit eigenem Netzteil für ein paar Euro. Der Repeater sollte eigentlich wie in diversen Foren beschrieben Handshake Probleme zwischen Onko Verstäker und Samsung Fernseher lösen. Da war der Schnee plötzlich weg (und auch die Handshake-Probleme mit dem Onkyo 875).


    Wirklich extrem merkwürdig.....

    Nur zu Info für alle, die ein ähnliches Problem haben und hier auch erfolglos gesucht haben:


    Bei der Ct vdr 6 Installation hat es bei mir nicht mehr gereicht, einfach nur die Module


    mt352
    dvb_bt8xx
    dst


    in /etc/modules für die Avermedia 771 einzutragen. Sondern ich musste auch in /etc/modprobe.d/blacklist das Modul


    btaudio


    ausschalten. Merkwürdigerweise gibt es im logfile normal keinen Fehler und der Frontend-Treiber wird korrekt registriert. Erst wenn man mit Vdr "Neustart" den Treiber+VDR neu lädt, erscheint manchmal folgende Meldung (die mich letztlich zu btaudio führte):


    dvb_bt8xx: unable to determine DMA core of card 0,
    dvb_bt8xx: if you have the ALSA bt87x audio driver installed, try removing it.
    dvb-bt8xx: probe of dvb0 failed with error -14


    Sodele... hoffe es hilft jemanden weiter..

    Also,


    ein einfaches Lesen mit


    cat /proc/acpi/alarm


    bringt keine Fehlermeldung, beseitigt aber auch nicht das Problem beim Schreiben, denn mit einem darauf folgenden
    echo '2004-12-11 12:12:12' > /proc/acpi/alarm gibt es noch immer die Fehlermeldung:


    ACPI-0286: *** Error: No installed handler for fixed event [00000004]


    Interesant dabei ist vielleicht auch, dass trotz der obigen Fehlermeldung man die neu eingestellte Uhrzeit mit cat /proc/acpi/alarm korrekt angezeigt bekommt. Nur aufwachen tut der Rechner halt errst, wenn die Zeit ein zweites mal geschrieben wurde...

    Ich bin gerade dabei Ct Vdr 3 inkl. ACPI zu installieren. Dabei gab es ein ACPI Problem, dass mich doch ein paar Stunden aufgehalten hat. Hier Problem und Lösung, die hoffentlich in zukünftigen Versionen berücksichtigt werden...


    Das Problem: Bei manche Motherboards (ASUS P4P800 Deluxe) muss man wohl die Urzeit mindestens zwei mal in /proc/acpi/alarm speichern, bevor dies akzeptiert wird. Bei dem ersten Versuch nach dem Booten bekomme ich mit "echo '2004-12-11 12:12:12' > /proc/acpi/alarm" im syslog nur eine Fehlermeldung, dass ein Handler fehlt. Gibt man den Befehl ein zweites mal ein, gibt es keinen Fehler mehr und der Rechner wacht auch korrekt auf.


    Ich schlage daher vor, in /usr/share/vdr/shutdown-hooks/S90.acpiwakeup das Abspeichern der Uhrzeit einfach doppelt vorzunehmen. Also


    echo $TIME_TO_SET >$ACPI_ALARM
    echo $TIME_TO_SET >$ACPI_ALARM

    Ca. 30% aller Aufnahmen mit VDR (sowohl Ct's 1.2.2-6woody1 als auch Tobi's
    1.2.6 Elchi) sind bei meinem System (2x Nexus 2.1) defekt (Bild+Ton
    unbrauchbar). Das Problem scheint bekannt und tritt bei mir auch nur auf
    wenn beide Karten im System stecken. Einzeln gibt es mit keiner der Karten Probleme.
    Jede Karte hat Ihren eigenen IRQ und es liegt auch sonst scheinbar kein Hardware Problem
    vor (Fehler tritt auch bei gestarteten kalten PC schon auf). Mehr dazu in:


    http://www.vdrportal.de/board/thread.php?threadid=7204&sid=&threadview=0&hilight=picture%20type&hilightuser=0&page=1


    Entsprechend dem obigen Thread und aus Verzweiflung wollte ich nun einen
    neuen DVB Treiber installieren. Nun bin ich VDR und Linux Neuling,
    programmiere aber seit 25 Jahren. Mit den diversen Anleitung hier im Forum
    und anderen Sites bin ich doch als "Neuling" in einige zeitaufwendige
    Fallen getappt. So gab es eigentlich immer Probleme, den Anleitungen der
    "Experten" zu folgen, oft weil z.B. angeblich "selbstverständliche"
    Arbeitsschritte weggelassen werden, oder nicht vollständig waren.


    Deshalb habe ich mal meine Erfahrungen und Arbeitsschritte zum Installieren
    eines neuen DVB Treibers unter Tobi's 1.2.6 Elchi festgehalten (sollte mit
    der Ct Distribution genauso funktionieren, oder?). Fuer Kommentare zu Verbesserungen/Fehler/Infos
    bin ich immer dankbar


    ; Kernel installlieren - Evtl. sind nur die header Dateien notwendig, aber ich brauche den Kernel Source sowieso für einen Patch...
    ; Zurerst sollte man wie auf der Heise bzw. Tobi's Site beschrieben die sources.list Datei
    ; zum Installieren der Pakete erweitern...
    ; Notwendigen Pakete holen
    apt-get install dpkg-dev gcc g++ libc6-dev make patch debhelper autoconf automake bzip2 devscripts dh-make dpkg-dev
    cd /usr/src
    apt-get install kernel-source-2.4.21-i586-cdv
    ; Weiss der Teufel wieso... aber ich muss den Source nochmal extra entpacken...
    tar -xjvf kernel-source-2.4.21-i586-cdv.tar.bz2
    ln -s kernel-source-2.4.21-i586-cdv linux
    ; Jetzt noch -i586-cdv für EXTRAVERSION in makefile und conf.vars angeben
    cd linux
    nano conf.vars
    nano Makefile


    ; Damit der Kernel richtig installiert ist, noch ein paar Einstellungen kopieren/aktivieren..
    cp /boot/config-2.4.21-i586-cdv /usr/src/linux/.config
    cd /usr/src/linux
    make oldconfig
    make dep
    ; Wer will... ein make sollte jetzt durchlaufen...
    make


    ; der /build Link in /lib/modules/2.4.21-i586-cdv war falsch, und beim make des Treibers fehlt dann Rules.make
    ; - hat eine Stunde Suche gekostet... da ich glaubte es fehle was bzw. obige makes funktionierten nicht...
    cd /lib/modules/2.4.21-i586-cdv
    rm build
    ln -s /usr/src/kernel-source-2.4.21-i586-cdv build


    ; Jetzt kommt der DVB Treiber
    ; Die Pakete zum Compilieren des Treibers muessen auch noch von Hand installiert werden da
    ; eine automatische Installation der Pakete schlug fehl... Wie macht man das bloss???
    apt-get install debhelper libgtk1.2-dev libcdk-dev transfig tetex-bin automake ncurses-dev gs-common autoconf2.13
    cd /usr/src
    ; Download des installierten Treibers:
    apt-get source dvb-driver-2.4.21-i586-cdv
    ln -s linuxtv-dvb-1.0.1 DVB
    ; ODER Download des neueren Treibers von Schmidingers Site...
    ; PS: falls wget noch nicht installiert ist: apt-get install wget
    wget ftp://ftp.cadsoft.de/vdr/linux-dvb.2003-11-08.tar.bz2
    ln -s linux-dvb.2003-11-08 DVB


    ; Was das jetzt soll verstehe ich selbst nicht... basiert auf make Meldung... braucht man wohl kaum nur fuer die Treiber?
    mkdir ~/.szap
    cp /usr/src/DVB/apps/szap/channels.conf-dvbs-astra ~/.szap/channels.conf
    cd /usr/src/DVB/apps/szap
    ./szap


    cd /usr/src/DVB/driver/
    ; Jetzt noch im Makefile Kernel Version (2.4.21-i586-cdv) und Location (/lib/modules/$(KERNEL_VERSION)/build) angeben...
    nano /usr/src/DVB/driver/Makefile


    ; Jetzt sollte der Treiber eigentlich compilieren....
    ; und in /usr/src/DVB/driver/av7110/ sollte danach z.B. dvb-ttpci.o existieren
    make


    ; Zum Installieren und Aktivieren des Treibers zuerst VDR/Treiber beenden und dann neu installieren/starten
    /etc/init.d/vdr stop
    modprove -r dvb-ttpci
    make ./makedev.napi
    make install
    ; Jetzt wäre wohl ein reboot angesagt... aber es geht auch mit den zwei folgenden Befehlen
    ; Falls z.B. ein Resource-Konflikt angezeigt wird, ist ein reboot wohl angesagt (hoffentlich ein Backup zur Hand?)
    make insmod
    /etc/init.d/vdr start


    Jetzt laeuft zumindestens bei mir VDR...


    Mit dem linuxtv-dvb-1.0.1 Treiber Paket kann man auch im letzen Schritt folgendes verwenden:
    cd /usr/src/DVB
    debian/rules binary


    Dies laeuft hier ohne Fehler durch
    und die folgenden Pakete werden z.b. in /usr/src
    abgespeichert:


    dvb-dev_1.0.1-2_all.deb
    dvb-driver-source_1.0.1-2_all.deb
    dvb-zapping_1.0.1-2_i386.deb


    Jetzt sollte eigentlich folgendes genügen, doch ich habe es nicht ausprobiert:
    cd /usr/src
    dpkg -i dvb-driver-source_1.0.1-2_all.deb
    Letzteres hat bei mir nicht wirklich funktioniert und das obige "make install" funktionierte dann...

    Ich kann nur meine Erfahrungen als Newcomer nach einer MPlayer Installation mit dem Tobi-Skript erzählen (Ct vdr 1.2.2-6woody1):


    1. ich musste manuell die dummy Dateien unter /video anlegen. Wozu und ob wirklich notwendig... wer weiss???


    2. Das standardmäßig angegebene DVD Laufwerk in MPlayer konnte nicht gemountet werden, da ein entsprechende Eintrag in fstab fehlte. So wurde beim Mounten immer ein Fehler angezeigt und beim Versuch eine Datei zu starten wurde nur der Bildschirm
    kurz dunkel und das normale TV Programm kam ohne Meldung zurück.


    Zur Lösung habe ich folgende Zeile bei etc/fstab hinzugefügt:


    /dev/dvd /dvd iso9660 defaults,ro,user,exec,noauto 0 0


    Nun noch als root /dvd anlegen mit "mkdir /dvd" und nach einem reboot war alles ok und ich konnte DVD unter MPlayer mounten und abspielen...