Beiträge von Antiriad

  • S2-6400 mit yaVDR nutzen klappt irgendwie nicht

    Wenn Du die S2-6400 FB benutzen willst muss Du nix anlernen unter Yavdr 0.4. Die Karte wird incl. Fernbedienung tatsächlich out-of-the-box unterstützt, da muss kein dkms und auch kein Plugin für händisch nachinstalliert werden.
    Ich würde ja vorschlagen Du machst dein zerfrickeltes System einfach platt und instalierst yavdr einfach nochmal neu, das dürfte wohl am schnellsten gehen.

  • TechnoTrend TT-micro S825 - PVR-Funktion mit welchen Einschränkungen?

    Naja, der ist nicht unbedingt besser als "Baumarkt" Receiver. Die Kiste braucht schon ne Weile um zu booten, Umschaltzeiten sind grade so erträglich.
    Das können andere HD taugliche Geräte in der Preisklasse besser (z.B. von Medialink, Opticum, Octagon, Smart, etc.). Und wenn man sich genauer umschaut findet man hier auch Receiver (die zwar nicht HD+ zertifiziert sind),
    die aber nach entsprechendem "SW-Update" trotzdem mit HD+ Karten umgehen können. Leider haben die dann alle oft zwei SW-Bugs: Das Vorspulen in Aufnahmen von HD+ Sendern ist möglich und die Aufnahmen landen auch noch unverschlüsselt auf der Platte. Aber da kommt bestimmt bald ein Bugfix für... :mua Allerdings haben diese Receiver dann meist auch nur einen rudimentär implementierten Timeshift, nicht so dolle EPG Funktionalität und andere kleine Macken. Aber irgendwas is ja immer...

  • [0.4] RC6 Infrarot Empfänger, Modell IR606Q und Harmony 300 keine Reaktion auf Tastendrücke

    So, bin heute Abend endlich mal wieder dazu gekommen mich um diese Baustelle zu kümmern. Und jetzt endlich läuft dieser verdammte IR-Empfänger auch unter Linux. :)
    Wie schon vermutet fehlt in dem linux-media-dkms build in der Datei mceusb.c die Device ID für diesen Empfänger, darum fühlt sich das Modul nicht zuständig für das Teil.


    Nach dem ich die Zeile:
    { USB_DEVICE(VENDOR_FORMOSA, 0xe042) },
    in static struct usb_device_id mceusb_dev_table[] eingefügt hatte (und linux-media-dkms neu gebaut und installiert habe) wurde das Teil dann auch endlich erkannt:


    Unter /proc/bus/input/devices sind dann diese zwei Einträge hinzu gekommen:


    Und endlich kommen die Tastendrücke auch bei eventlircd an und der VDR lässt sich bedienen. :tup

  • [0.4] RC6 Infrarot Empfänger, Modell IR606Q und Harmony 300 keine Reaktion auf Tastendrücke

    Oh ja, das währe wirklich klasse wenn Du dir das mal anschauen könntest. :)


    In der Zwischenzeit habe/hatte ich die ganze Sache nochmal bei Null begonnen.
    1) Yavdr 0.4 neu installiert
    2) yavdr-upgrade ausgeführt
    3) apt-get install linux-media-dkms ausgeführt
    4) reboot


    Jetzt tauchte lustigerweise auch ein dem IR-Receiver zuzuordnendes device (I: Bus=0003 Vendor=147a Product=e02d Version=0110
    N: Name="USB IR Receiver USB IR Receiver") unter /proc/bus/input/devices auf:


    Unter lsusb sogar zwei (kbd&mouse?):

    Code
    Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 147a:e042 Formosa Industrial Computing, Inc.  <---------
Bus 001 Device 004: ID 05af:0630 Jing-Mold Enterprise Co., Ltd
Bus 001 Device 003: ID 147a:e02d Formosa Industrial Computing, Inc. <-----------
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    147a:e02f ist laut usb -v wohl die ne "Maus":
    bInterfaceClass 3 Human Interface Device
    bInterfaceSubClass 1 Boot Interface Subclass
    bInterfaceProtocol 2 Mouse


    147a:e042 müsste dann wohl das "Kbd" device sein, aber dort spuckt lsusb -v nicht so viele Infos zu aus:
    bInterfaceClass 3 Human Interface Device
    bInterfaceSubClass 0 No Subclass
    bInterfaceProtocol 0 None
    iInterface 0




    Für Vendor=147a Product=e02d ist bei yavdr 0.4 ja auch ein profile unter /etc/eventlircd hinterlegt, trotzdem erfolgt keinerlei reaktion auf Tatstendrücke auf der FB.


    Ich hab dann noch folgenden Test gemacht:
    1) stop eventlircd
    2) apt-get install evtest
    3) evtest /dev/input/event2


    Das führt zur folgenden Ausgabe:


    Das sind aber auch alle Ausgaben die man sieht, bei Tastendrücke auf der Harmony 650 (Windows MCE Profil eingestellt) passiert nix in der Shell. Die LED am IR-Empfänger leuchtet brav auf bei jedem Tastendruck, aber es erfolgt sonst weiter keiner Reaktion. Ziehe ich den IR-Empfänger ab vom VDR Rechner und steck das Ding an den Windows PC, funktionert die Kombination IR empfänger+ Harmony 650 einwandfrei, Tastendrücke werden ausgeführt, das Windows Media Center lässt sich per FB bedienen.


    Wenn ich mal Testweise anstatt event2 (was ja die FB sein müsste) mal event3 oder event4 bei evtest angabe (also die von meinem Funk Keyboard), bekomme ich Ausgaben in der Shell wenn ich auf der Tastatur rumdrücke bzw. auf dem Touchpad rumwerkle. Prinzipiell funktioniert also auch das. Aber auf event2 herscht absolut tote hose.


    Bin ja wirklich gespannt ob man das zickige Device unter linux noch vernüftig zum laufen bekommt... ;)

  • [0.4] RC6 Infrarot Empfänger, Modell IR606Q und Harmony 300 keine Reaktion auf Tastendrücke

    Dachte es währe klar, aber das hatte ich natürlich bereits installiert (darum ja meine Frage ob der oben angebenen testbuild bereits in den stable branch eingeflossen ist).
    "apt-get update; apt-get upgrade; apt-get install linux-media-dkms" bringt also leider nix, Empfänger wird nicht unter /proc/bus/input/devices gelistet.


    Ist in dem Paket tatsächlich der Support für "Bus 001 Device 008: ID 147a:e042 Formosa Industrial Computing, Inc." drin?
    Ich hab mal ein Blick in die Paketsourcen geworfen und ich kann im aktuellen yavdr stable stand dieses Pakets in der Datei mceusb.c / mceusb_dev_table[] keinen Eintrag für das Formosa Device mit der ID 0xe042 finden...

  • [0.4] RC6 Infrarot Empfänger, Modell IR606Q und Harmony 300 keine Reaktion auf Tastendrücke

    Wie schauts eigentlich aktuell aus? Ist das oben genannte Testing Packet inzwischen auch im "stable" yavdr aufgenommen ?
    Ich hab hier auch so einen dieser nicht ganz billige IR606Q Receiver von Cohaus rumliegen, hatte gehofft das dat Ding wegen der beworbenen Linux kompatibilität
    einfach nur angesteckt werden muss und dann auch unter yavdr 0.4 als MCE Empfänger Out-Of-The-Box tut. Naja, ist natürlich anders gekommen, nix geht...


    Die Fernbedienung bzw. der IR-Empfänger selber funktioniert. An ein Windows-7 Rechner angesteckt, kurz die HW-Erkennung abgewartet und schon lässt sich per Fernbedienung das Windows-MCE starten und bedienen.
    (Plug&Play wie man es sich wünscht). HW-Defekt, leere Batterien und ähnliche Ausreden ziehen also nicht. ;)


    Der Empfänger wird in dmesg und lsusb angezeigt:


    [ 17.543158] generic-usb 0003:147A:E042.0003: timeout initializing reports
    [ 17.543518] generic-usb 0003:147A:E042.0003: hiddev0,hidraw2: USB HID v1.00 Device [Formosa21 eHome Infrared Transceiver] on usb-0000:00:


    Bus 001 Device 008: ID 147a:e042 Formosa Industrial Computing, Inc.



    aber unter /proc/bus/input/devices taucht das Empfänger nicht auf:


    I: Bus=0019 Vendor=0000 Product=0001 Version=0000
    N: Name="Power Button"
    P: Phys=PNP0C0C/button/input0
    S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
    U: Uniq=
    H: Handlers=kbd event0
    B: PROP=0
    B: EV=3
    B: KEY=10000000000000 0


    I: Bus=0019 Vendor=0000 Product=0001 Version=0000
    N: Name="Power Button"
    P: Phys=LNXPWRBN/button/input0
    S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
    U: Uniq=
    H: Handlers=kbd event1
    B: PROP=0
    B: EV=3
    B: KEY=10000000000000 0



    In einem xbmc forum habe ich nur die Info gefunden das der Empfänger wohl vom lirc_mceusb module angesprochen werden kann, aber das lirc_module scheint bei der yavdr-distri nicht dabei zu sein, sehe ich das richtig?
    Any ideas was man noch ausprobieren kann um den Empfänger doch noch an den Start zu bekommen?

  • Bootmeldungen aum TV anzeigen

    Ich glaub ich habe jetzt die Ursache des Kernel-Oops gefunden!


    In meinem Fall habe ich nämlich lirc homebrew support für ttyS0 im Webinterface aktiviert gehabt. Wie ich jetzt aber gesehen habe, meldet meine I/O Port Karte ihre Serialports nicht bei ttyS0 beginnend, sondern by ttyS4 (IO-Port Adresse ist auch ne andere als die übliche 0x2f8, 0x3f8 ). Da mein Board aber keinerlei COM Legacyports bei 0x3f8/ttyS0 besitzt, hat lirc beim modprobe erstmal versucht auf diesen Standardport zuzugreifen, hat dann gemerkt das es nicht geht und es gab eine Meldung das dieses Module nicht geladen werden konnte:


    [ 243.853261] lirc_dev: IR Remote Control driver registered, major 250
    [ 243.853407] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned.
    [ 243.855529] lirc_serial: port existence test failed, cannot continue


    Nach so einem modprobe lirc_serial versuch crasht dann auch 100% reproduzierbar "cat /proc/ioports".
    Deaktiviere ich lirc im Webinterface bzw. ich übergebe dem module beim laden die korrekte io-port adresse, gibts auch keinen kernel-oops mehr.
    Auslöser des ganzen war also die nicht valide Lircconfiguration meinerseits. Allerdings hätte ich erwartet das in so einem Fall (module kann nicht auf resourcen zugreifen und das module wird gleich wieder entladen) lirc halt einfach "nicht funktioniert" und nicht die Kernel internen Speicherbereich schrottet. Der Spruch der beim laden von lirc_serial kommt ("lirc_serial: module is from the staging directory, the quality is unknown, you have been warned.") ist also durchaus ernst zu nehmen. ;)

  • Bootmeldungen aum TV anzeigen

    Hallo Gerald,


    okay, ich hab die Datei /etc/rc2.d/S05loadcpufreq mal weggeschubst und ohne die Datei habe ich den Systemfreeze beim Booten bisher nicht mehr reproduzieren können. Die Kiste ist bisher immer aufgestartet und ich hab nen laufenden VDR mit Bild+Ton, soweit so gut. Wenn ich "cat /proc/ioports" ausführe, habe ich zwei verschiedene Ergebnisse beobachtet. Beim ersten Versuch beendete sich cat sofort mit ner "Getötet" meldung (Reproduzierbar), mit jedem weiteren aufruf von cat /proc/ioports gabs nen weiteren Callstack im dmesg log (siehe unten). Dann habe ich den Rechner rebootet und es nochmal probiert, diesmal funktionierte die cat Ausgabe, es gab keinen Absturz.


    Versuch #1:


    cat /proc/ioports
    Getötet


    dmesg:
    [ 60.155969] BUG: unable to handle kernel paging request at ffffffffa19334b1
    [ 60.155977] IP: [<ffffffff812e1e4b>] strnlen+0xb/0x40
    [ 60.155987] PGD 1a05067 PUD 1a09063 PMD 103eeb067 PTE 0
    [ 60.155995] Oops: 0000 [#2] SMP
    [ 60.155999] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sdb/uevent
    [ 60.156004] CPU 2
    [ 60.156007] Modules linked in: tda10023 snd_hda_codec_hdmi snd_hda_codec_realtek tda10021 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq joydev ppdev nfsd budget_av exportfs saa7146_vv nfs lirc_dev lockd fscache nfs_acl auth_rpcgss sunrpc videodev nvidia(P) v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core budget_core snd_timer snd_seq_device dvb_core snd psmouse serio_raw parport_pc soundcore saa7146 snd_page_alloc ttpci_eeprom lp parport usbhid hid ahci xhci_hcd libahci e1000e vesafb
    [ 60.156070]
    [ 60.156074] Pid: 1896, comm: cat Tainted: P D C 2.6.38-13-generic #54-Ubuntu /DH67CL
    [ 60.156083] RIP: 0010:[<ffffffff812e1e4b>] [<ffffffff812e1e4b>] strnlen+0xb/0x40
    [ 60.156090] RSP: 0018:ffff8800d9d8dcc8 EFLAGS: 00010286
    [ 60.156094] RAX: 0000000000000000 RBX: ffff880103edb173 RCX: 0000000000000000
    [ 60.156098] RDX: ffffffffa19334b1 RSI: ffffffffffffffff RDI: ffffffffa19334b1
    [ 60.156102] RBP: ffff8800d9d8dcc8 R08: 000000000000ffff R09: 000000000000ffff
    [ 60.156105] R10: 0000000000000000 R11: 0000000000000003 R12: ffffffffa19334b1
    [ 60.156109] R13: ffff880103edc000 R14: 0000000000000000 R15: 000000000000ffff
    [ 60.156114] FS: 00007fc7bf0d7720(0000) GS:ffff8800e6f00000(0000) knlGS:0000000000000000
    [ 60.156118] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 60.156122] CR2: ffffffffa19334b1 CR3: 00000000dc397000 CR4: 00000000000406e0
    [ 60.156126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 60.156130] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [ 60.156134] Process cat (pid: 1896, threadinfo ffff8800d9d8c000, task ffff8800dc1cc4a0)
    [ 60.156137] Stack:
    [ 60.156140] ffff8800d9d8dd08 ffffffff812e3fee ffff8800d9d8dce8 ffff880103edb173
    [ 60.156147] ffffffff817db9d2 ffff8800d9d8dd98 ffffffff817db9d2 ffff880103edc000
    [ 60.156154] ffff8800d9d8dd88 ffffffff812e5121 ffffea000302ffff ffff88010d105f80
    [ 60.156161] Call Trace:
    [ 60.156168] [<ffffffff812e3fee>] string.clone.3+0x3e/0xd0
    [ 60.156174] [<ffffffff812e5121>] vsnprintf+0x221/0x620
    [ 60.156181] [<ffffffff81185e08>] seq_printf+0x58/0x90
    [ 60.156189] [<ffffffff81173ad5>] ? do_filp_open+0x195/0x7c0
    [ 60.156196] [<ffffffff8106db28>] r_show+0x78/0x80
    [ 60.156202] [<ffffffff811861a6>] seq_read+0x256/0x3f0
    [ 60.156207] [<ffffffff81185f50>] ? seq_read+0x0/0x3f0
    [ 60.156214] [<ffffffff811c03bf>] proc_reg_read+0x7f/0xc0
    [ 60.156220] [<ffffffff81164fb3>] vfs_read+0xc3/0x180
    [ 60.156225] [<ffffffff811650c1>] sys_read+0x51/0x90
    [ 60.156232] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b
    [ 60.156235] Code: 31 c0 80 3f 00 55 48 89 e5 74 11 48 89 f8 66 90 48 83 c0 01 80 38 00 75 f7 48 29 f8 c9 c3 66 90 55 31 c0 48 85 f6 48 89 e5 74 2a <80> 3f 00 74 25 48 83 ee 01 48 89 f8 eb 10 0f 1f 80 00 00 00 00
    [ 60.156293] RIP [<ffffffff812e1e4b>] strnlen+0xb/0x40
    [ 60.156299] RSP <ffff8800d9d8dcc8>
    [ 60.156301] CR2: ffffffffa19334b1
    [ 60.156306] ---[ end trace c3c5733c8617f767 ]---



    Versuch #2:
    cat /proc/ioports
    0000-03af : PCI Bus 0000:00
    0000-001f : dma1
    0020-0021 : pic1
    0040-0043 : timer0
    0050-0053 : timer1
    0060-0060 : keyboard
    0064-0064 : keyboard
    0070-0071 : rtc0
    0080-008f : dma page reg
    00a0-00a1 : pic2
    00c0-00df : dma2
    00f0-00ff : fpu
    0290-029f : pnp 00:02
    03b0-03df : PCI Bus 0000:00
    03c0-03df : vesafb
    03e0-0cf7 : PCI Bus 0000:00
    03f8-03ff :
    0400-0453 : pnp 00:08
    0400-0403 : ACPI PM1a_EVT_BLK
    0404-0405 : ACPI PM1a_CNT_BLK
    0408-040b : ACPI PM_TMR
    0410-0415 : ACPI CPU throttle
    0420-042f : ACPI GPE0_BLK
    0450-0450 : ACPI PM2_CNT_BLK
    0454-0457 : pnp 00:09
    0458-047f : pnp 00:08
    04d0-04d1 : pnp 00:06
    0500-057f : pnp 00:08
    0cf8-0cff : PCI conf1
    0d00-ffff : PCI Bus 0000:00
    1180-119f : pnp 00:08
    d000-dfff : PCI Bus 0000:04
    d000-d003 : 0000:04:00.2
    d010-d017 : 0000:04:00.2
    d010-d012 : parport0
    d013-d017 : parport0
    d020-d027 : 0000:04:00.1
    d020-d027 : serial
    d030-d037 : 0000:04:00.0
    d030-d037 : serial
    e000-efff : PCI Bus 0000:01
    e000-e07f : 0000:01:00.0
    f000-f01f : 0000:00:1f.3
    f020-f03f : 0000:00:1f.2
    f020-f03f : ahci
    f040-f05f : 0000:00:19.0
    f060-f063 : 0000:00:1f.2
    f060-f063 : ahci
    f070-f077 : 0000:00:1f.2
    f070-f077 : ahci
    f080-f083 : 0000:00:1f.2
    f080-f083 : ahci
    f090-f097 : 0000:00:1f.2
    f090-f097 : ahci


    Alles sehr merkwürdig....
    Was ich noch beobachtet habe ist, das die Anzahl der vorhandenen CPUs einen Einfluss auf die Reproduzierbkeit zu scheinen habe. D.h. wenn ich bei dem vorhandenen i3 2120 die beiden Kerne + Hyperthreading aktiv habe, tritt der Freeze beim Boot extrem häufig auf. Schalte ich Hypethreading ab, reduziert sich reproduzierbarkeit drastisch. Schalte ich dann auch noch den zweiten Kern im BIOS ab, wirds noch "besser". Damit habe ich den Crash gar nicht mehr hinbekommen. Riecht ja irgendwie nach Racecondition...

  • Bootmeldungen aum TV anzeigen

    Ich habs geschaft einen "screenshot" vom Callstack zu machen, hat zwar ein paar Versuche mit der Digicam gekostet, aber am Ende stimmte das Timing. ;)
    Wenn ich den Callstack richtig lese scheint hier "grep" bei nem strlen Aufruf mit nem pagefault die Grätsche zu machen, wie kann denn das passieren? Und um die Antwort auf die gleich kommende Frage vorweg zu nehmen: Ja, ich habe bereits nen memtest86 laufen lassen (für ca.8 Stunden, kein Fehler detektiert) und yavdr habe inzwischen auch mehr als einmal frisch&sauber neu installiert.


    Update: Jetzt habe ich es auch geschafft die Ausgaben abzulichten die noch nach dem Callstack (und kurz vom dem Systemfreeze) kommen, da sieht man glaub ich auch wo der "grep" aufruf herkommt der fehlschlägt (grep -q Intel .*ICH $IOPORTS). Zur Information: Nach der Ausgabe mit dem Timestamp 7.841847 steht das System.

  • Bootmeldungen aum TV anzeigen

    Bin selber ein wenig weiter gekommen:


    In der grub.cfg den Kernelparameter ändern. (Achtung: Die grub.cfg wird generiert, Änderung hier sind also mit dem nächsten Update eh wieder futsch, aber zum testen kann man hier auch direkt dran rumfrickeln)


    - Die vorhandenen Kerneloption "splash", "quiet" und "vt.handoff=7" entfernen.


    - Die Kernelparameter "nosplash" und "-v noplymouth" hinzufügen (Ob die Parameter bei yavdr unbedingt notwendig sind weis ich nicht, bei nem "normalen" Desktop-Ubuntu sind sie es)


    Damit kann ich jetzt beim Booten die Logausgaben sehen. Und in der tat sehe ich für den Bruchteil einer Sekunde eine Ausgabe die nach Callstackausgabe ausschaut (-> Kernel Oops?). "Leider" friert die Kiste dort nicht sofort ein, sondern er scheint noch das Frontend/Xserver gestartet zu bekommen bevor der Rechner sich dann ins Nirvana verabschiedet (d.h. die Logausgaben werden schon wieder von nem später aufgeschalteten schwarzen Bildschirm überdeckt, grummel...).

  • Bootmeldungen aum TV anzeigen

    Zitat von Moorviper

    reicht es nicht <esc> zu drücken damit der bootsplash verschwindet
    evtl mal die konsolen durchswitchen


    Im Fehlerfall sehe ich die BIOS Meldung, danach wird der Bildschirm dauerhaft schwarz und es ist kein Konsolen wechseln per Tastatur möglich, der Rechner reagiert auf keinerlei Tastendruck (außer dem RESET-Schalter oder 4-Sekündiger PowerButton drücken am Gehäuse). Auch keinerlei SSH Verbindung ist möglich. Ich vermute das er in nem Kernel-Oops oder sowas ähnliches hängt. Sollte es "nur" ein Display/Xserver Problem sein, müsste der Rechner ja trotzdem per SSH erreichbar sein.

  • Bootmeldungen aum TV anzeigen

    Ich hab das gleiche Problem und würde auch gerne wissen wie man die Bootlog ausgaben zu Gesicht bekommen kann. WIe gehlhajo schon schrieb gibts die black.conf inder 0.4 nicht mehr und in der Troubleshooting Sektion vom yavdr wiki habe ich diesbezüglich auch nichts entdecken können. Wenn also jemand nen tipp hat... ;)

  • HDMI-Eingang schrottet Signal - Kann das sein ?

    Da verhält sich wohl jeder Fernseher anders. Bei meinem (50Hz) LCD Sony-TV verwendet der nvidia-treiber/yavdr bei der "automatischen" Hz Einstellungen auch 60Hz. Schlecht sieht das Bild deshalb aber nicht aus, aber Laufschriften biw z.B. bei n24/n-tv haben dann geruckelt. Musste dann auch selber hart die 50hz einstellen und schon hatte ich ein perfektes Bild mit Butterweichen scrollenden Laufschriften. ;)


    Die "Weiße Halos" deuten auf Überschärfung hin, schau mal nach ob Du irgendwo ne Einstellung hast wo man die Schärfe runter stellen kann.

  • Intel DH67CL + G620 = Problem

    Hallo,


    hab mir ein DH67CL Mainboard und eine G620 CPU zugelegt, dazu ein wenig DDR3 1333 Kingston RAM.Leider weigert sich diese Kombination stabil zu laufen.Linux legt sich beim booten gleich mit Kernel-Ooops auf die Klappe, memtest86+ ist reproduzierbar "ohne Funktion". Es blinkt nur das "+" Symbol und der Cursor, aber die Anzeige bleibt statisch auf
    dem stehen was ich als Foto angehängt habe. Das Programm reagiert auch nicht auf irgendwelche Tastendrücke. Den ganzen krams habe ich niegel-nagel-neu von Amazon gekauft. Das Board habe ich mir von Amazon tauschen lasse, hat aber nix gebracht, gleicher Fehler. Das RAM habe ich danach auch über Amazon getauscht, hat ebenfalls nix gebracht. Auch das Netzteil habe ich mal testweise ausgetauscht, ebenfalls keine Änderung. Bleibt ja jetzt eigentlich nur noch das die CPU nen hau weg hat, oder hat noch jemand nen Vorschlag oder Idee was man ausprobieren könnte?


    Bin hier langsam am Verzweifeln, hätte nie gedacht das es so schwierig ist ein lauffähiges Intel System aufzubauen (hatte bisher immer nur AMD Systeme, das gab es so ne Probleme irgendwie nie...).

  • P8P67M oder Intel Board (DH67XX)

    Zum DG67XX kann ich nicht direkts sagen, aber ich hab mir nen VDR auf DH61DL Basis Testweise aufgebaut:
    - MB: DH61DL
    - CPU: G620 (Boxed Lüfter)
    - RAM: 1x2GB AData Riegel
    - HDD: Western Digital AV-GP 2TB (WD20EVDS) (für die Aufnahmen)
    - SSD: 8GB Transcend (Fürs System, in diesem Fall yaVDR 0.4)
    - TT S2-6400 (übernimmt die Video-Ausgabe über HDMI und spielt den Sat Dual-Tuner ;) )
    - LiteOn DVD Brenner
    - Netzteil DC-DC Wandler: PicoPSu-90-XLP (Herstellerangabe: 90W, 95% combinedefficiency, Standby <0.050 watt)
    - Externes 100W 12 VNetzteil mit nem PF von 0.95
    - 1x SilenX IXTREMA Gehäuselüfter auf 12% der max. Drehzahl gestellt (->Quasi unhörbar).


    Also was die HW angeht fast alles nur Energieeffizientes "Green" Zeugs... ;)


    Im Betrieb (Live-TV ARD-HD) zeigt der VOLTCRAFT Energy Monitor 3000 was um 39-40W an. Wenn ich die Platte in den Standby versetze gehts nochmal 1-2 Watt runter.
    Der Lüfter "kostet" auch ein gutes Watt. Wird der Rechner runtergefahren (Weckfähig, LAN LEDs sind noch lustig am blinken und lauern auf ein WOL-Paket ;)) wird 0,9 -1,0 Watt angezeigt.
    Aber gerade in dem unteren Bereich ist die Genauigkeit bei den Geräten ja nicht so dolle, das Meßgerät ist laut Herstellerangaben eh nur für den Bereich 1,5W..3000W geignet
    mit nem Meßfehler von ± (1% + 1 W) .


    Mit ner VDPAU/Nvidia Ausgabe und ner seperaten Twin-Tuner Karte wird man wohl auch kaum unter die 40W kommen. Also wenn überhaupt, könntest Du hier im Vergleich zu deiner jetzigen HW max. 30W einsparen. (Wobei ich vermute das die Grafikausgabe über Nvidia Grafikkarte+Twintuner DVB Karte eher Leistungshungriger sein wird als die hier verwendete S2-6400 und Du daher sogar eher weniger als 30W Einsparpotential hast). Musste jetzt mal gegenrechnen was ein evtl. HW-Autausch kostet und wie lange die Kiste laufen muß damit Du die Kosten über die Stromrechnung wieder reingeholt hast.

  • DVB-S zu DVB-C sowie allgemeine Hardware- / "Plugin"fragen!

    Zitat von G0nzo

    Hallo zusammen,


    Bei mir im Wohnkomplex wurde vor ein paar Wochen eine "eigene Kabelanlage" in Betrieb genommen.
    Dazu wurde auf einem Dach eine DVB-S Anlage installiert welche jedes Gebäude im Keller mit dem Signalen vorsorgt.
    Von dort aus wird das Signal ins digitale Kabel Signal (DVB-C) umgewandelt und in die einzelnen Wohnungen gespeist.
    Vorteil dieser Konstallation ist das keine neuen Kabel in jede Wohnung gelegt werden müssen.


    Bist Du sicher das DVB-S -> DVB-C umgesetzt wird? Oder nicht doch eher DVB-S -> Analog-Kabel?
    Gerade wenn vorher das TV Programm von einem Kabelanbieter gekommen ist, kann ich mir schwer vorstellen das
    da jetzt "einfach so" alles nur noch Digital eingespeist wird. Die meisten Kabelnutzer schauen ja analog und die
    hätten dann ja jetzt nur noch rauschen auf dem TV. Oder wurde vorab jedem Bewohner im Wohnzkomplex von der
    Wohnungsgesellschaft ein DVB-C Receiver geschenkt? ;) Oder wird DVB-S -> Analog-TV und DVB-C umgesetzt? Fragen über fragen...
    Aber wenn wirklich nach DVB-C umgesetzt wird, ist wenigstens die Wahrscheinlichkeit das die privaten TV-Programme (anders als bei z.B. Kabel Deutschland)
    verschlüsselt werden extrem gering.

  • OPENBOX S9 DVB-S2 Sat Receiver

    Wohl kaum.


    Scheint ein closed source receiver mit custom firmware zu sein wie die meisten anderen 0815-SAT-Receiver auch.
    "Open" ist er eher in einer anderen Beziehung, aber das Thema wird aus rechtlichen gründen hier nicht so gern besprochen... ;)

  • diseqc.conf Inverto Monoblock quad 2 Tuner

    Ich habe auch das Problem das der VDR Probleme hat mit dem Diseq schalten ("normale" DVB Receiver an der selber Anlage funktionieren probemlos).
    Das Problem habe ich damit umschifft, einen Diseqc repeat einzubauen, d.h. es wird das Kommando zum Umschalten des LNBs
    drei mal direkt hintereinander geschickt:


    S13.0E 11700 V 9750 t v W15 [E0 10 38 F0] W15 t [E0 10 38 F0] W15 t [E0 10 38 F0] W15 t
    S13.0E 99999 V 10600 t v W15 [E0 10 38 F1] W15 T [E0 10 38 F1] W15 T [E0 10 38 F1] W15 T
    S13.0E 11700 H 9750 t V W15 [E0 10 38 F2] W15 t [E0 10 38 F2] W15 t [E0 10 38 F2] W15 t
    S13.0E 99999 H 10600 t V W15 [E0 10 38 F3] W15 T [E0 10 38 F3] W15 T [E0 10 38 F3] W15 T


    S19.2E 11700 V 9750 t v W15 [E0 10 38 F4] W15 t [E0 10 38 F4] W15 t [E0 10 38 F4] W15 t
    S19.2E 99999 V 10600 t v W15 [E0 10 38 F5] W15 T [E0 10 38 F5] W15 T [E0 10 38 F5] W15 T
    S19.2E 11700 H 9750 t V W15 [E0 10 38 F6] W15 t [E0 10 38 F6] W15 t [E0 10 38 F6] W15 t
    S19.2E 99999 H 10600 t V W15 [E0 10 38 F7] W15 T [E0 10 38 F7] W15 T [E0 10 38 F7] W15 T