Posts by muellerph

    Nachdem ich mich lange mit der PVR350 und der C't4 rumgeärgert hatte, frage ich mich ob es überhaupt Sinn macht für PVR350 only die C't-Version zu nehmen.

    Die C't ist wunderbar für alle DVB-Varianten, aber für ne PVR350 only braucht man das alles nicht (EPG, etc.) und für ne PVR350 muß man eh alles selbst compilieren (IVTV, Lirc) - und dabei ist die 3'er sogar noch "einfacher" als die 4'er...

    Welchen Vorteil habe ich eigentlich wenn ich die C't version nehmen gegebenüber einem Vanilla Sarge (mal davon abgesehen daß eine auch bei C't inzwischen veraltete Version von VDR gleich dabei ist)?

    Die headers sind zwar zu 99% die richtigen allerdings ist das Appendix nicht eingetragen. Mit diesen Headers bekommst Du nur Versionsinfos zu "2.4.27" und nicht zu "2.4.27-ct-1".

    Es gibt 2 Stellen wo das fehlende "-ct-1" eingetragen werden muß, hab sie aber gerade nicht parat (bin nicht daheim).

    Habe auch DVB-T und die PVR350.
    Bei mir hatte ich danach aber Probleme mit dem bttv-Modul (genauer mit nem eeprom-modul), daß bei ivtv auch neu gebaut wird, dann aber für dvb-t nicht mehr geladen werden kann (symbols).
    Wenns bei Dir auf Anhieb klappt, dann sei froh...

    Ich würde erst gar nicht versuchen etwas für den RC4 zu machen sondern einfach gleich auf die finale im 2.6.12-ct-1 umsteigen.

    Es gibt von der Anzahl der Module für den Kernel keinen Unterschied zwischen dem RC4 und dem fianlen (für beide sind die gleichen vorhanden), also gibt es keinen Grund nicht direkt auf den 2.6.12-ct-1 umzusteigen.

    Falls Ihr dem so nicht traut, Ihr könnt auch natürlich auf Kernelorg noch die Unterschiede zwischen RC4 und final ansehen, ob es da irgenwelche Änderungen gibt, die Euch betreffen - ich bezweifle es und selbst wenn wollt Ihr die Änderungen haben ;)

    Und für den 2.6.12-ct-1 gibt es sowohl die headers als auch die Sourcen.

    Last Euch hier nicht von dem Wort "Experimental" bei Heise abschrecken. Ich habe noch von keinem hier gelesen, der mit diesem Kernel Probleme hat, aber nicht mit dem RC4.

    Das gilt natürlich auch alles für den 2.4.31...

    Per apt-get bekommst du die ivtv oder ein passendes LIRC nicht.

    Für reine Kernelheader per apt-get mußt Du auf die experimetellen Kernel 2.6.12 oder 2.4.31 umsteigen (wie auf der C't HP beschrieben).

    Für IVTV brauchst Du nur die header, solltest du aber die FB zum laufen bringen wollen, dann brauchst Du noch die LIRC-quellen und die Kernel-Source.

    Falls 1. eben nein gewesen wäre, wäre es sehr einfach.

    Dein VDR1 gilt dann als Gateway für das interne Netz zwischen VDR1 und VDR2. Da gibts genügend Howtos im Internet - google: howto sarge gateway

    Die einzigen Besonderheit dabei wäre dass Du:
    - Feste IPs verwendest
    - Keinen Proxy verwendest
    - Dein DNS-Server die IP-Adresse von Deinem Router hat (192.168.0.2)
    Die Howtos sollten eigentlich reichen.

    Da Du aber vom Internet auf VDR2 willst, kenne ich mich nicht so aus.

    Das Problem ist hier, wie Dein VDR1 Pakete and VDR2 weiterleiten soll.
    Ich baue 2 Netzwerkkarten (bei Dir WLAN und ETH) eigentlich immer in 2 Adressebereichen (192.168.1.x und 192.168.2.x).
    Ob dies in einem Netz geht, weiß ich nicht. Wenn nicht ist dann das Schlagwort Bridge und das ist haarig. Kannst ja mal mit google: howto sarge brige suchen.

    Generell hat das aber wenig mit C'tVDR zu tun, sondern ist Linux oder Sarge allgemein. Solltest daher den Thread dorthin schieben.

    1 Frage:
    Willst Du vom Internet auf VDR2 auch zugreifen können (das macht es dann erheblich komplizierter)?

    Aber selbst wenn.
    Die configdateien wirst Du Dir selber schreiben müssen.
    Ich weiß ja nicht mal wie die IP-Adressen Deines Routers/WLAN aussehen. Ob diese DHCP machen oder Du feste IPs machen kannst und dann auch in welchen IP-Adressräumen.

    Ich habe die FB zum laufen gebracht. Habe dafür allerdings LIRC selber kompilieren müssen.
    Mit LIRC 0.7.1 klappts dann auf jeden Fall.

    Vorgehen (aus der Docu zu ivtv-0.3.6w):
    1. Kernel-Sources installieren (headers reichen nicht).
    2. Version anpassen ../include/linux/version (ansonsten stimmen die modversion nicht überein)
    3. make dep
    4. ln -s /usr/src/kernel-sources-... /usr/src/linux

    5. Lirc entpacken
    6. ./setup.sh
    7. Haupeauge auswählen (menüpunkte 1 dann 5 dann f)
    8. Speichern und konfigurieren (menüpunkt 3)
    9. make, make install, depmod -ae

    10. In /etc/modutils/ivtv eintragen:
    alias-char-major-61 lirc_i2c
    add above ivtv lirc_dev lirc_i2c

    11. update-modules
    12. depmod -ae

    13. /usr/local/sbin/lircd starten (und in ein startscript bei jedem Boot eintragen)

    14. modprobe ivtv

    Nun sollte es gehen ;)

    Philipp

    Hallo,

    bastel an einer ct4 - PVR350 only Lösung.
    Habe den 2.4.31-ct-1 genommen, ct-vdr-1.2.6-34 (tobi sarge/testing), wobei ich lirc 0.7.1 und ivtv 0.3.6w selbst kompiliert habe und bekomme nun auch Bild sowie Ton. Dass meine FB noch nicht funktioniert ist ein anderes Thema.

    Allerdings funktioniert das Keyboard nicht wenn vdr läuft und ich kann daher nicht umschalten.
    So wie ich es ahne, habe ich einmal das remote-plugin installiert gehabt und nun funkt mir das dazwischen.

    Zuerst zu den Indizien:
    In der /var/log/syslog taucht nach dem start von pvr folgender Eintrag auf:

    Code
    Jul  2 22:02:15 localhost vdr[4066]: ERROR (remote.c,282): Ungültiger Dateideskriptor
    Jul  2 22:03:47 localhost last message repeated 540859 times
    ...

    Wenn ich das remote-plugin installiere fehlt diese Fehlermeldung, daher gehe ich davon aus, dass der pvr immer noch das Ding starten will, aber es natürlich nicht kann aber trotzdem das Keyboard blocked.

    Eine Suche hier im Forum hat mir nicht wirklich weitergeholfen. Es gibt nur Infos zu einem fehlerhaften plugin, ich habe/will es aber eigentlich gar nicht...

    Kann mir einer helfen?

    Testing ist eigentlich kein gutes System für jede Box.

    Testing ist immer in einem releasefähigem Stand zu halten, das ist wohl das größte Problem. Das bedeutet insbesondere wenn mal wieder die glibc oder der Compiler geändert wird, dass erst alle anderen Pakete für ein Paket migriert werden müssen, bevor ein Paket aus SID in testing darf.
    Da kann man dann unter Umständen ewig warten, bis ein Paket kommt. Früher oder später greift man dann entnervt eh auf unstable zu und das kannst Du dann gleich.

    Nur kurz vor einem Release ist Testing wirklich eine Alternative, kurz nach einem Release ist es einfach "Blödsinn".

    Zu guter letzt bekommst Du aus oben genannten Gründen manchmal monatelang kein Bugfix für kritische oder gar Sicherheitsprobleme.

    Bei Debian gibbets halt nur Stable oder Unstable. Testing ist sogesehen halbschwanger oder halb tot ;)

    Klar hab ich schon ein paar mal nen Kernel kompiliert, wollte aber auf dem VDR jetzt nicht ne ganze Entwicklungsumgebung installieren, geschweige denn die ganzen Kernelsourcen für nur 1 Modul. :(

    Ich habe den Text auch nur für die Search-Engine geschrieben, damit andere bei PVR 350 ziemlich schnell sehen, dass die plain vanilla ct4 nichts für PVR 350 ist - kompilieren, paket bauen etc. ist halt nichts für mal kurz das Dingens zum laufen zu bringen.
    Unabhängig davon ist die 350 ja eh ein Biest bis sie so läuft wie gewollt - dann noch mit dem Kernel rumschlagen kann einen schnell überfordern...

    A propos Kernel-Headers:
    Wie ich schon vermutet habe, hat Heise nun für den Experimental Kernel 2.6.12 die Headerdateien hinzugefügt.
    Also noch eine Option: Nehmt den 2.6.12'er, wenn man nicht den gesamten Kernel bauen will (was aber immer noch ne Entwicklungsumgebung erfordert).

    Wirst Du bei Deinem Modul (Du baust doch als Modul) die Kernelversion gleichbehalten, bzw. auch sonst nichts ändern? Dann könntest Du ja Dein fertiges Modul zur Verfügung stellen und jeder der will, kann es sich dann einfach in das /usr/lib/modules/... -Verzeichnis legen?

    Spart dann einigen die gesamte Entwicklerumgebung ;)

    Bin auch gespannt auf Dein Howto :)

    Zumindest mit ctvdr3 habe ich es versucht, bin aber dann daran gescheitert, dass der Kernel ohne Versionsinformationen gespeichert wurde. Die sind aber scheinbar zwingend notwendig bei den linux-wlan-ng treiber selber zu backen.

    Aber bevor Du jetzt zu sehr ans selber verzweifelt rumbasteln gehst, benutz doch die hostap-treiber. Die sind soweit ich es gesehen habe schon kompiliert (für beide Versionen) und die Prism-Chipsätze werden von hostap unterstützt.

    Hostap kann hier mehr als nur einen AP emulieren, hostap kann ganz normal als client konfiguriert werden. AFAIK soll hostap eh den lead bekommen und linux-wlan-ng ganz ersetzen. Hostap kann auch wpa etc.

    Philipp

    So wie ich es sehe sind bei der ctvdr4 die ivytv Treiber nicht mehr mit dabei.
    Die Kernelheader zum 2.6'er fehlen (noch?), vielleicht wartet ja Heise auf den heute erschienen finalen 2.6.12'er und bringt ein Gesamtupdate.

    Unabhängig davon fehlt der ivtv Treiber und damit ist die ctvdr4 nicht ohne Eigencompilierung für ne PVR 350 zu gebrauchen :(

    Muß wohl auf die Header warten oder auf den 2.4'er Kernel ausweichen (da sind die Header dabei).

    Philipp

    Jaja ich weiß, viel zu spät. Aber nicht immer hat man zu Hause die Zeit die man sich erhofft.

    egal:

    Quote

    was muss ich hier setzten wenn ich WEP 128 Bit schlüssel einsetzte?


    PRIV_KEY128=true

    Quote

    Hexadezimal oder normal?


    Hexadezimal

    Quote

    AuthType="opensystem" # opensystem | sharedkey (requires WEP)


    Wenn mich nicht alles täuscht sharedkey
    Ich benutze es als AdHoc-Netzwerk, deswegen brauche ich sharedkey