Posts by Tux

    Auf der Titelseite des aktuellen Pearl-Katalogs gibt eine neue HD-Sat Receiverbox unter Android 4.0 für 100 Euro. An sich klingt das ganz toll. Aber ich habe da noch zwei Fragen zum Vergleich mit meinem VDR:

    • Kann sich das Gerät schlafen legen und vor der Aufnahme automatisch wecken, oder muss es bei anstehenden Aufnahmen durchlaufen?
    • Wie hoch ist der Strombedarf in Idle und im Standby / Aus?

    Ich vermute die Antworten werden mich beim VDR bleiben lassen.
    Tux

    Hallo DanielH,

    heino666 hat Recht. Ich habe mir auch erst nen Wolf gesucht und mit symbolischen Links gearbeitet. Die Lösung ist tatsächlich in der /etc/default/vdr die Variable VIDEO_DIR zu setzen. Das funktioniert mit meinem QNAP NAS.

    Um es ganz sauber zu machen habe ich das YaVDR Template System dafür benutzt, so dass mit einem "process-template /etc/default/vdr" die Variable drin steht. Das hält dann auch nach einem automatischen Upgrade in Zukunft.

    Hallo Soulfly2xs,

    Ich plane den Umstieg auf HD und freue mich, dass yaVDR bei Dir auf dem MB POV D510 MATX läuft, welches ist unter c't VDR im Einsatz habe.

    Wie sieht's mit dem Wakeup aus? Funktionert es einfach so out of the box? Oder musstet du etwas einstellen? Benutzt dein yaVDR ACPI Wakeup oder NVRAM? Shutdown auf S3 oder S5?

    Und welche kleine Umstellung im Bootvorgang meinst du? Wahrscheinlich eine Umkonfiguration von Upstart ( mit dem ich noch keine Erfahrung habe)?

    Vielen Dank und viele Grüße,

    Tux

    Hallo videoman,

    Ja, ich bin nach der Wiki Seite vorgegangen und habe die
    beiden nvram Konfigurationsdateien mit Hilfe des guess-helper.sh
    erstellen lassen, da mein Mainboard noch nicht in der Liste vorkommt.
    Das Atom Board beruht auf einem Intel Chipsatz, nicht VIA, deshalb
    habe ich zunächst INTEL ausgewählt, aber nachdem das nicht funktionierte
    habe ich es probehalber auch weggelassen.

    Bei der ACPI Methode hätte ich bei gesetztem Alarm im Dump einen Eintrag
    alrm_pending : yes
    erwartet. Was steht da bei Leuten, bei denen ACPI funktioniert? Und was bei
    HPET_emulated : yes

    Tux

    Das Mainboard Point of View MB-D510-MATX läuft bei mir mit dem c't-VDR Version "1.6.0-17ctvdr1" sehr schön, nur Wakeup bekomme ich einfach nicht zum Laufen. Daher verlagere ich den Thread jetzt in diese Spezial-Rubrik. Meine sonstigen Erfahrungen und bisherigen Versuche sind unter:
    Point of View MB-D510-MATX für Server?
    nachzulesen.

    1. NVRAM-Wakeup per BIOS RTC funktioniert
    Im BIOS gibt es die Möglichkeit den VDR zu einer bestimmten Uhrzeit automatisch neu starten zu lassen. Das hat funktioniert.

    2. ACPI-Wakeup -> kein Erfolg
    vdr-addon-acpiwakeup (0.0.10) zusammen mit 2.6.28-etobi.3-686 oder 2.6.26-2-486 funktionieren leider nicht, egal ob ich den RTC Wakeup im BIOS aktiviert habe oder nicht. Ich habe auch die Tipps aus dem VDR-Wiki zum Thema durchprobiert und einen Fehler in einem der mitgelieferten Scripte gefixt. Die errechnete und geschriebene Zeit nach /sys/class/rtc/rtc0/wakealarm geschrieben und unter
    /proc/driver/rtc kontrolliert. Leider bootet der VDR nicht zur programmierten Zeit (und nicht 1 oder 2 Stunden später).

    Beispiel ohne gesetzte Zeit:
    rtc_time : 17:14:16
    rtc_date : 2010-08-28
    alrm_time : 23:59:59
    alrm_date : ****-**-**
    alarm_IRQ : no
    alrm_pending : no
    24hr : yes
    periodic_IRQ : no
    update_IRQ : no
    HPET_emulated : yes
    DST_enable : no
    periodic_freq : 1024
    batt_status : okay

    Beispiel mit gesetzter Zeit (beim runterfahren automatisch abgegriffen):
    rtc_time : 17:34:55
    rtc_date : 2010-08-01
    alrm_time : 17:55:00
    alrm_date : 2010-08-01
    alarm_IRQ : yes
    alrm_pending : no
    24hr : yes
    periodic_IRQ : no
    update_IRQ : no
    HPET_emulated : yes
    DST_enable : no
    periodic_freq : 1024
    batt_status : okay

    Ich hatte auch an HPET per Bootparameter experimentiert. Was ich noch nicht probiert habe, sind die S3 und S4 Zustände. Ich fahre bisher per Shutdown runter, also S5.

    3. NVRAM funktioniert leider auch nicht
    Ich habe ACPI Wakeup deaktiviert und zwei NVRAM Konfigurationen erstellt, mit und ohne Intel Einstellung. Beide behaupten behaupten problemlos schreiben zu können und sie schreiben acuh garantiert etwas in die BIOS Einstellungen, da nach dem Neuboot der VDR mit BIOS Fehler stehenbleibt. Die Checksum stimmt nicht und daher sind alle Werte auf Default zurückgesetzt.
    Hier meine zwei Konfigurationen:

    ################################################
    ## Mainboard autodetection information:
    ##
    ## - Mainboard vendor: "Point of View"
    ## - Mainboard type: "MB-D510-MATX"
    ## - Mainboard revision: "Ver. A1"
    ## - BIOS vendor: "American Megatrends Inc."
    ## - BIOS version: "080016"
    ## - BIOS release: "01/28/2010"

    addr_min = 0x4F
    addr_sec = 0x50
    addr_day = 0x54
    addr_hour = 0x55
    addr_stat = 0xB9
    shift_stat = 1
    addr_chk_h = 0x31
    addr_chk_l = 0x7E

    upper_method = INTEL

    Und das gleiche nochmal ohne INTEL:

    ################################################
    ## Mainboard autodetection information:
    ##
    ## - Mainboard vendor: "Point of View"
    ## - Mainboard type: "MB-D510-MATX"
    ## - Mainboard revision: "Ver. A1"
    ## - BIOS vendor: "American Megatrends Inc."
    ## - BIOS version: "080016"
    ## - BIOS release: "01/28/2010"

    addr_min = 0x4F
    addr_sec = 0x50
    addr_day = 0x54
    addr_hour = 0x55
    addr_chk_h = 0x30
    addr_chk_l = 0x31

    Da die BIOS Methode schon funktioniert hat, wäre es am leichtesten die Checksum
    in Ordnung zu bringen, ich weiss nur nicht wie. Vielleicht hat jemand noch 'ne Idee
    für ACPI Wakeup.

    Danke,

    Tux

    Hallo Schnulli,

    In
    Point of View MB-D510-MATX für Server?
    habe ich von meinem Problem mit der Realtek Onboard Netzwerkkarte berichtet, und von meiner Lösung.
    Die Realtek Karte wird falsch erkannt und für die richtige fehlt der Treiber im Kernel.

    Ich hatte zunächst den Realtek Treiber passend zum Kernel selbst gebaut und eingebaut. Das funktioniert, ist aber für Laien schwierig.

    Die Mühe hätte ich mir fast sparen können. Sowohl ein Update des Debian Kernels im ct-VDR auf die neuste Version als auch der Umstieg auf einen e-tobi Kernel beseitigen das leidige Problem ohne eigenen Treiberbau. Leider braucht man dafür eine funktionierende Netzwerkverbindung. Die kann man sich ja mit einer temporär installierten Netzkarte im PCI Slot besorgen, da reicht auch eine 100MB für.

    Tux

    Ich habe ACPI Wakeup rausgenommen und statt dessen nvram wakeup konfiguriert mit Hilfe des mitgelieferten Hilfsprogramms. Also jede Menge manuelle Einstellungen im BIOS gefolgt von Neuboot. Und zwar zeimal, einmal mit Chipset Intel und einmal unknown.

    Leider scheint die Routine zur Ermittlung der passenden BIOS Checksum falsch zu sein. Jedesmal wenn ich zum Test eine Sendung programmiert habe und runtergefahren habe, hat der Bootvorgang gestoppt weil das BIOS einen Checksum Error hatte. *Alle* BIOS Einstellungen standen danach Default-Werten und ich musste alle neu einstellen. Die Wakeup-Einstellung hat diesen Reset nicht überlebt.

    Ein reiner Wakeup nur über manuelle BIOS-Einstellung funkioniert aber.

    Im Moment fällt mir nichts mehr ein wie ich einen automatischen Start hinbekommen könnte.

    Frage: Könnte es einen Unterschied machen in welchen ACPI Modus der Rechner bei einem Shutdown gesetzt wird und wo kann ich das anders einstellen. Ich denke so an S1, S3, S4?

    Ich hatte wieder mal Zeit den Kampf um das Wakeup aufzunehmen und habe zwar noch keine Lösung aber Fortschritte erzielt:

    - Mittels RTC im BIOS (ohne Linux) ist es mir gelungen die VDR-Box zeitgesteuert automatisch einschalten zu lassen. Ich schliesse daraus, dass Wakeup mit NVRAM höchstwahrscheinlich geht. Ich will aber lieber ACPI Wakeup.

    - Nach stundenlangem lesen, debuggen, programmieren bin ich einem Fehler auf die Schliche gekommen. Das Linux Kern ist neuer als 2.6.22 ( 2.6.26 bzw. 2.6.28 ) und damit wird die Aufwachzeit nicht in /proc/acpi/alarm sondern /sys/class/rtc/rtc0/wakeup gespeichert.

    - Die Aufwachzeit wird vom VDR in der Datei /var/cache/vdr/acpiwakeup.time gespeichert und zwar im menschenlesbaren Format z.B. "2010-08-01 17:55:00' in UTC.

    - Das vdr-addon-acpi-wakeup Script erwartet die Zeit aber in Sekunden seit Epoch (Sylvester 1970) in UTC. Wenn die RTC / ACPI Routine im Kernel merkt, dass das Format nicht richtig ist, speichert sie einfach keine Aufwachzeit. Liegt die Zeit in der Vergangenheit, speichert sie auch nicht. Also habe ich die Methode geändert, so dass sie die Wakeup Zeit in UTC Sekunden umrechnet.

    - Ein zweimaliges Setzen ist beim MB-D510-MATX nicht nötig und möglich, da das Device vom ersten Schreiben noch geblockt wird und sowieso der Wert geschrieben wird:
    Kontrolle der Aufwachzeit per
    cat /proc/driver/rtc

    - Ich habe die Parameter der hwclock Scripte beide auf --directisa gestellt

    - Ich habe den Kernel per Boot Parameter auf hpet=disabled gesetzt

    - Ich habe den Kernel geupdatet auf den neusten 2.6.26-2 von Debian und wird die Gigabit Ethernet Karte R8168 jetzt richtig erkannt ohne von Hand kompilierten Treiber. Aber ich teste auch alternativ mit dem 2.6.28-etobi Kernel.

    Ich habe noch nicht alle Kombinationen der oben angegebenen Massnahmen durchprobiert.

    Leider bootet der VDR immer noch nicht zur angegebenen Zeit.

    Tipps sind willkommen.

    Das Point of View MB-D510-MATX wird zusammen mit seinem kleinen Bruder Point of View MB-D510-MITX in der c't 15, S.52 besprochen.

    Dem Fazit kann ich nur zustimmen: Gute Boards, aber minimale Dokumentation und kaum Support auf den Herstellerseiten.
    Ich erwarte nicht, das je ein BIOS Update erscheinen wird.

    Ich habe lange erfolglos versucht, den VDR per ACPI Wakeup aufwecken zu lassen. Der Kernel unterstützt die Hardware und beim runterfahren wird die richtige Zeit (inkl. UTC) hineingeschrieben, aber er wacht leider nicht auf.
    Das Aufwachen per RTC habe ich dazu im BIOS deaktiviert, da sich beides wohl nicht verträgt.

    Als nächste werde ich also versuchen, die BIOS RTC Methode per NVRAM anzusprechen.

    Tux

    Seit gestern kann ich meinen VDR tatsächlich "anschalten"!

    Ein NVRAM CMOS total reset per Jumper hatte keinen Erfolg. Eine verzweifelte Verstellung von so ziemlich jeder BIOS Einstellung, auch wenn ich nicht alle verstanden habe, hat geholfen. Bleibt die Frage, welche der Einstellungen jetzt den Power On repariert hat. Ich tippe auf den ausführlichen Selftest beim Booten, statt dem abgekürzten. Eventuell hat das Netzteil dann einfach mehr Zeit sich zu stabilisieren. Auf jeden Fall geht es jetzt mit der PicoPCU (80Watt) und auch mit 20 Kontakten statt 24.

    Der Stromverbrauch ist laut Billigmessgerät von primärseitig 77 Watt auf 55 Watt gesunken. Im ausgeschalteten Zustand zeigt es 9-11 statt 11-13 Watt an. Den absoluten Zahlen traue ich nicht aber die Tendenz stimmt sicher und ist erfreulich.

    Tja, ich kann den VDR immer noch nicht per Power Taster starten. Ich habe jetzt zwei Netzteile, jeweils mit und ohne 20->24 Adapter probiert. Es funktioniert nur, wenn man den Stecker zieht, kurzschliesst bis kein Saft mehr übrig ist, und dann wieder einsteckt. Der vdr startet dann von alleine. Das Problem existiert auch ohne Verbraucher, also ohne die SAT Karten, etc.
    Ich dachte erst, es läge vielleicht am Linux-Kernel, der per ACPI Wakeup irgendwas beim Runterfahren verstellt. Ausserdem hatte der 486er Kernel weder den zweiten Core der CPU noch den Highmem erkannt. Also habe ich auf e-tobi's 686 umgestellt und ACPI wakeup deinstalliert. Jetzt läuft er auf beiden Kernen und mit vollen 2GB Ram, aber das Powerproblem bleibt.

    Hat Irgend jemand noch nen Tipp?

    Die Zeitsynchronisation funktioniert inzwischen. Ich habe den Menüpunkt unter Einstellungen -> EPG gefuinden.

    Ausserdem habe ich die zweite SAT Karte an den LBN angeschlossen. Super. Vorher hatte ich nur einen PCI Slot (EPIA ME6000) und Slotdoppler gingen aus gehäusetechnischen Gründen nicht.

    Das Starten per Power Knopf ist immer noch unzuverlässig. Aber eine Pico-PSU ist bestellt und ich hoffe das Problem erledigt sich dadurch. Ich bin auf die Leistungsaufnahme und den Geräuschpegel gespannt. Den grössten Lärm macht momentan definitiv der Netzteillüfter (SFX Netzteil).

    Aufnahmen direkt per NFS auf das NAS im Keller funktionieren. Allerdings blieb nach dem Abbruch einer laufenden Aufnahme das Aufnahmeverzeichnis stehen, obwohl es in der Aufnahmenliste nicht auftauchte?

    Zeitgesteuerte Aufnahmen per ACPI-Wakeup habe ich mich noch nicht getraut wieder zu testen.

    Das MB-D510-MATX hat zwei Anschlüsse für Lüfter, ein SYS und ein CPU. Ich habe zwei Gehäuselüfter mit gleichem Anschluss. Werde mal probieren die da anzuschliessen. Ich erwarte mir eine Temperaturgesteuerte Drehzahleinstellung. Im Moment laufen sie per Widerstand und Umschalter von drei verschiedenen Drehzahlen mit der geringsten. Die einzigen Bedenken habe ich mit den HF Teilen auf den SAT-Karten, die sehr heiss werden, kaum im Luftstrom sind und direkt nebeneinander stecken müssen.

    So, am Wochenende hatte ich Gelegenheit meinen alten VDR zu schlachten und auf das MB-D510-MATX umzubauen. Hier meine Erfahrungen soweit:

    Die Netzwerkkart im Chipsatz RTL8168B wird automatisch als RTL8169 erkannt und der RTL8169 Treiber geladen -> Kein Netzwerk. Es gibt in Debian Lenny keinen Treiber für RTL8168B. Also habe ich nach Anleitung aus http://www.ico.de/supportbereich/showthread.php?t=227 den Treiber nachinstalliert. Jetzt funtioniert auch das Netzwerk.

    Die ATX Netzteilbuchse liegt in der Mitte -> Kable vom Netzteil zu kurz -> Netzteil bisher fliegend eingebaut, funktioniert soweit. Abhilfe: Entweder kleine Verlängerung kaufen, oder gleich auf Pico-PSU umrüsten wie ich es sowieso vorhatte. Der Strombedarf ist identisch zu vorher. Das kann ich auch nur über Pico-PSU senken. Bisher werden 62 Watt primärseitig gezogen.

    Frage: Sollte ich auf 60W oder 80W Pico-PSU setzen?

    Die Verbindung zum NFS-Server über den Mountpoint /var/lib/video.00 klappt super, Aufnahmen kann ich ohne Verzögerung abspielen

    Die Uhrzeit stimmt nicht. Ich finde auch den Punkt nicht, wo der VDR den Kanal einstellt, von dem er die Uhrzeit nimmt. Eventuell ist ja ntpd sowieso besser. Solange kann ich auch die automatische Aufnahme nicht testen.

    Das Runterfahren funktioniert. Das Anschalten per Taster funktioniert nicht. Ich muss den Netzstecker einige Zeit rausziehen. Dafür bootet er wenn ich den Stecker wieder reinstecke !?

    Zweite Budget Karte habe ich noch an die Schüssel angeschlossen. Kommt noch.

    Lirc funkioniert dank RS-232 Schnittstelle auf Anhieb wie bisher.
    Leider kann ich mein Display auf Basis der Druckerschnittstelle nicht mehr weiter betreiben. Da brauche ich wohl etwas auf USB Basis.

    Das Booten von Flash-SATA funktioniert super. Rauf und Runterfahren sind jetzt viel schneller.

    Die Temperatur der CPU pendelt im Moment bei 39 Grad, bei 3 Lüftern (zwei langsame Gehäuselüfter, ein Netzteillüfter). Netzteillüfter ist bald nicht mehr, und einen Gehäuselüfter kann ich noch abklemmen. Dann ist Ruhe.

    Softwareprobleme:
    - hatte die alte channel.conf als root kopiert und vergessen auf vdr:vdr umzustellen. Der VDR durfte sie nicht lesen und brach ab.
    - das Burn Plugin funktioniert nicht ohne Brenner, auch wenn man nur Images bauen möchte -> deaktiviert
    - Nachinstallieren von Paketen erwartet die ct-VDR CD. Ich habe aber kein CD-Laufwerk für SATA -> bei Abbruch nimmt er das Debian-Repository vom Netz. Muss mal die Sources komplett auf Netz umstellen.

    Soweit mein Zwischenbericht. Die Familie kann immerhin wieder Fernsehen und damit ist die schwierigste Phase überwunden. Der Rest ist Feintuning.

    Ich habe das Board im fliegenden Aufbau noch ohne Gehäuse
    gebootet bekommen. Das vorbereitetet c't-VDR auf dem SSD
    fährt fehlerfrei vollständig hoch. Die Gigabit Netzwerkkarte wurde
    automatisch erkannt.
    Zutaten: Memory, SATA-SSD, Netzteil,
    PS2-Keyboard, VGA-Monitor.
    Es fehlen noch: FF und Budget Sat Karten, SFX Netzteil und Gehäuse.

    Als nächste werde ich prüfen müssen, ob das Board auch
    mit dem SFX Netzteil von Fortron Source hochfährt, welches
    nur einen 20 Pin Stecker hat, und nicht wie das ATX Netzteil
    mit einem 24 Pin Stecker. Sonst habe ich noch dem Einbau
    in das alte Gehäuse ein Problem.

    Ne Pico-PSU hat doch auch nur 20 Pins und funktioniert trotzdem,
    oder?

    Moin,

    Ich habe hier seit 7 Jahren ein EPIA M6000 mit TT FF laufen,
    das ganze auf c't-VDR 6. Hatte ganz zu Beginn auch LinVDR 0.7.
    Das OSD wird bei uns nur dann träge, wenn wir
    ARD oder ZDF gucken während gerade die Aufnahme
    läuft, also quasi live und nicht zeitversetzt.
    Es scheint so als ob ARD und ZDF grössere Datenmengen,
    als die privaten verschicken(?) und er zwischen wegspeichern
    und wiederholen zuwenig Zeit hat,
    Abhilfe: auf einen anderen Kanal im gleichen Buquet umschalten,
    dann reagiert auch das OSD wieder schneller.

    Grüße,

    Tux