Ich habe jetzt die Version 1.8 (sowohl modules als auch utils) ins experimental-Repository auf heise online gepackt. Nach dem Studieren der Bug-Reports zum Debian-Paket bin ich nicht sicher, ob die Version mit dem 2.6.15er-Kernel überhaupt geht. Wäre schön, wenn es jemand mit passender Hardware ausprobieren könnte.
Peter
Ich habe mal eben die ndiswrapper-utils aus unstable für sarge neu übersetzt. Die anhängende Datei mit dpkg-i <Name> installieren, kann es mangels geeigneter Hardware nicht selbst testen. Rückmeldungen bitte per Mail, dann kann ich das Paket ggf. ins Repository packen. Danke,
Peter
Hallo,
nach längerer Abstinenz habe ich endlich Zeit gehabt, aktuellere DVB-Treiber für ctvdr3 (Kernel 2.4.27) in ein Paket zu verwandeln. In einigen Threads wird über diese Treiber schon gesprochen - ich hatte sie einigen zum Probieren vorab gegeben - jetzt sind sie auch "offiziell" zu haben.
Näheres steht hier: http://www.heise.de/ct/ftp/pro…tradebs.shtml#dvbtreiber2
Die Kurzform:
- Firmware-Load für Premium-Karten via Hotplug (Firmware im Archiv ist C-Version)
- VHF-Fix für TechniSat AirStar2
- schnellere Umschaltzeichen bei Transponderwechsel bei alten Nova-Ts
Die Treiber liegen auch im testing-Ast der VDR-Repositories auf heise online. Wer die als Quelle eingetragen hat, kann mit apt-get installieren - von o.g. Seite ist aber auch ein manueller Download möglich (Installation dann mit dpkg -i). Die Treiber haben ein abweichenden Namen, um sie von offiziellen Debian-Treibern zu unterscheiden, werden also nicht automatisch bei einem apt-get upgrade gezogen.
Außerdem ist der testing-Zweig des Repository für ctvdr3 jetzt wieder auf einem halbwegs aktuellen Stand.
Peter
Zitatunter ctvdr2 hatte ich zwar auch kein fbtv, habe aber auf der Konsole #9 alle Textausgaben es VDR gesehen. Da mein VDR nicht in der Stube steht (sondern derzeit über den HF-Modulator eines defekten Videorecorders das Hausantennennetz speist, wäre es schön, wenn ich wenigstens die alten Sachen wieder am VGA-Monitor sehen würde...
Das war das control-Plugin. Leider fehlt diese Funktion in den aktuellen Versionen, wie ich gerade mit TomG festgestellt habe. Wenn das mit dem Framebuffer nicht zum Spielen zu kriegen ist, vielleicht einfach eine alte Version des Plugins selbst übersetzen?
Peter
Möp zurück 
Eine konkrete Idee habe ich leider nicht, aber ein paar Hinweise:
- zum Neulernen der FB muss die Datei /var/lib/vdr/remote.remote-event.conf gelöscht werden, während der VDR _nicht_ läuft.
- ich habe bei einem Nexus-Testsystem "Wackler" am Klinkenstecker des Empfängers - in der Regel hilft das Drehen des Steckers in der Buchse.
- das spätere Anschließen einer USB-Tastatur oder -Maus verschiebt die Linux-Gerätenummer, weil die beim Booten schneller rankommen als das Plugin (/dev/input/event1 statt /dev/input/event0).
- das Programm evtest wird standardmäßig mitinstalliert; es ist im Paket dvb-utils.
Peter
Interessant wäre zu erfahren, welche Netzwerkkarte drinsteckt, dann kann vielleicht jemand beispringen, der die auch hat Betrifft das Verhalten sowohl internen als auch externen Verkehr, könnte vielleicht ein MT/RU-Problem sein ...
Peter
Zitatbeim Online-Update bleibt bei mir die Installation auch bei 33% haengen.
Welche Art von Netzzugang? Router, ISDN, DSL ...
Was passiert beim Download einer ähnlich großen Datei (~2 MByte) von irgendeinem Server mit wget? (Zum Probieren nach dem Boot von der Installations-CD einfach auf eine andere Console wechseln, etwa mit Alt-F2, und dort wget <URL>.)
ZitatDie Offline-Installation bringt folgende Ausgabe in der deboot.log:
cp: reading `/cdrom/vdr/debian/pool/main/u/util-linux/bsdutils_2.12-10_i386.deb': Input/output error
gunzip: /install/var/cache/debconf/*.gz: No such file or directory
Auch das "riecht" nach einem CD-Fehler (siehe letzte Antwort in diesem Thread)
Peter
Danke fürs deboot.log - es gibt darin mehrere Anzeichen dafür, dass beim Einlesen von Dateien von der CD Fehler auftreten:
ZitatGet:2 copy: elchiosdpipac3/ Packages [6582B]
gzip: stdin: not in gzip format
Err copy: ./ Packages
Sub-process gzip returned an error code (1)
und hinther fällt die Installation auf die Nase. Eigentlich sollte sie das mit einer Meldung quittieren und nicht weiter machen ...
Wo ansetzen: Das heruntergeladene ISO mit md5sum prüfen - kommt die gleiche raus, die zum Image veröffentlicht ist (df3491075d1147182c1e48804a5ed94a)?
Wenn die CD mit jigdo entstanden ist, muss jigdo am Ende eine Erfolgsmeldung gebracht haben, zu sehen hier:
http://wwwedit.heise.de/ct/ftp…te/vdr3/bilder/jigdo4.jpg
Häufige Fehlerursache sind CD-RW-Rohlinge - dann bitte mal CD-R versuchen.
(Nur als Info: Ich habe vorhin das Image extra nochmal von unserem Server gesaugt und es mit allen Optionen aktiviert installieren lassen ... also direkt aus dem Image, ohne jigdo installiert und die "fehlenden" Pakete online holen lassen. Hat geklappt.)
Gute Besserung ans Söhnchen
Peter
Einfach mal die Debian-Pakete-Suche bemühen, die führt einen dann meist zum Ziel, wenn man schon einen Datei- oder Programmnamen kennt:
Die genannten Programme sollten sich durch Installation dieses Paket beschaffen lassen.
Peter
ZitatIch will nur die /tmp/deboot.log sichern. Aber alle per cp erzeugtegen auch umbenannte sind nach dem Neustart (für Netzzugriff) weg.
Nach /install kopieren - da hängt während der Installation die spätere root-Partition (/). (Bitte nicht in /install/tmp - das ist nach dem Booten leer ;))
Peter
ZitatAlso die install läuft ja s.o. noch ein Stück weiter, es taucht 3 mal das Fenster....fehlgeschlagen.... auf.
Wie lautet die erste Meldung konkret, was steht in dem Fenster? (Warnungen, die bei der Grundinstallation in einem Fenster "vorbeilaufen" sind normal).
ZitatDann rebooot von HD, es erscheint lilo aber ohne VDR-Eintrag. Wenn ich das Linux wähle, schließt er die OS-installation ab mit PW-Abfrage. Das tuts auch.
Es erscheint immer nur ein Linux-Eintrag - vdr steht im Lilo-Menü nicht. Das ist also normal.
ZitatAber wie kann ich nur die deboot.log aus /tmp sichern bis zum Neustart? Erstellte Kopien da von sind ja nach Neustart weg.
Wenn die Installation einwandfrei durchläuft, kopiert sie nach dem ersten Teil die Datei in das Installationssystem nach /var/log/deboot.log und sollte da zu ernten sein.
Peter
Wichtig ist, dass man VDR anhält /etc/init.d/vdr stop, dann die Datei /var/lib/vdr/remote.remote-event.conf löscht und dann VDR wieder startet (/etc/init.d/vdr start). Wenn das nicht klappt, dann ist das remote-Plugin nicht installiert, würde ich sagen. Ob das der Fall ist, lässt sich wie folgt überprüfen:
dpkg -s vdr-plugin-remote
Hilft auch das nicht, dann wären Auszüge aus den log-Dateien hilfreich, kurz nachdem VDR bzw. das System gestartet worden ist.
Nachtrag: Möglich wäre auch, dass das Plugin zwar installiert ist, aber aus dem Debian-Bestand stammt und aufgrund eines anderen Patchlevel nicht geladen wird. Ob das der Fall ist, zeigt die Ausgabe von /etc/init.d/vdr restart.
Je nach sources.list müsste sich das mit einem apt-get update; apt-get install vdr-plugin-remote beheben lassen - das Paket müsste von ftp.heise.de bzw. e-tobi.net kommen.
Peter
Die gepostet root.env ist leider nicht hilfreich. Die deboot.log-Datei sollte verraten, was schief geht oder wo es hängt. Die liegt im ersten Teil der Installation in /tmp/ im zweiten Teil in /var/log.
Im ersten Installationsteil stehen, ftp, scp und smbclient zur Verfügung, um eine/die Datei auf ein anderes System im Netz zu bringen.
Fragen zu den geschilderten Problemen:
- bei einigen bleibt das online Aktualisieren der Installation bei 33% hängen: Wie ist die Netzanbindung (Router, ISDN, Modem)? Geht danach z.B. noch ein ping www.heise.de?
- klappt es denn ohne online Update mit der Installation?
- stimmen die md5sums des ISO-Image mit den veröffentlichen überein?
btw: 192.168.0.0/24 ist eine alternative Schreibweise für die Netzmaske 255.255.255.0 (dafür braucht es mynet).
Peter
Das liest sich so, als würde das Online-Aktualisieren der Intallationsroutinen beim Herunterladen des tar- Archivs schon stecken bleiben. Warum das passiert, habe ich leider keine Idee.
In diesem Fall (CD-Image 3.06 und Online-Update auf Stand 3.06) hat das online Aktualisieren aber ohnehin keinen Nutzwert - es kommt nix neues.
Vielleicht einfach mal ohne online-Update versuchen?
Peter
Wie in einem Artikel der aktuellen c't versprochen, steht ab sofort das aktuelle ISO des c't-VDR 3 zum freien Download bereit. Aktuelles ISO heißt, inklusive aller soweit behobenen Fehler (derzeitiger Stand 3.06). Es gibt sowohl das Image als auch jigdo-Dateien, um die CD aus dem c't-Special auf den aktuellen Stand zu bringen.
Download-Link und jigdo-Dateien stehen auf der Projektseite:
www.heise.de/ct/ftp/projekte/vdr3/
Danke an alle hier, die mit konstruktiven Anmerkungen beim Ausmerzen von Fehlern geholfen haben. Ich werde hier weiterhin Augen und Ohren aufsperren, aber wer sicher gehen will, dass mich eine Information erreicht, schreibt am besten auch an ctvdrbug@ctmagazin.de und die einschlägigen Entwicklerlisten.
Wer es nicht allzu eilig hat, geduldet sich noch ein wenig: Eine Version 3.1 ist in Arbeit, die einen moderneren Schnappschuss der Debian-Sarge-Pakete und VDR-Pakete enthält und einige Details in der Installation umsortiert (ein Update von einer 3.0x-CD via jigdo auf 3.1 bedeutet z.Zt. Downloads von zirka 40 MByte).
Peter
dpkg-reconfigure linuxtv-dvb-modules-2.4.27-ctvdr-1 startet erneut das Skript, das nach vorhandenen DVB-Karten sucht. Die 1.6 braucht ein anderes Frontend-Modul als die 1.3.
Peter
Zitatgibt es mit jigdo nun eine möglichkeit diesen Kernel in das image zu bekommen, damit er direkt damit lädt? damit ich die normale Netzwerkinstallation durchführen lassen kann?
Nein. Das würde nur Sinn machen, wenn auch das installierende Knoppix auf 2.6 basiert. Die Installation wird 2.6 deshalb auf absehbare Zeit nicht lernen.
Warum nicht offline installieren (die fehlenden Dateien und den zum Donwload bereitstehenden Kernel 2.6 mit den module-init-tools ggf. auf einem USB-Stick)?
Um welche Netzwerkkarte handelt es sich eigentlich?
Peter
Ich habe mal in das keybdev-Modul den Patch von Oliver Endriss eingebaut, der den störungsfreien Parallelbetrieb des remote-Plugin mit einer USB-Tastatur erlaubt (ohne Patch "prellen" die Tasten). Hier auf meiner Testkiste hat es geklappt. Allerdings musste ich die Datei /var/lib/vdr/remote.remote-event.conf-Datei umschreiben, nämlich event0 durch event1 ersetzen. Die anhängende Datei gehört nach dem Dekomprimieren nach /lib/modules/2.4.27-ctvdr-1/kernel/drivers/input/keybdev.o (die alte würde ich zur Sicherheit vorher kopieren). Nach einem Reboot sollten sich remote-Plugin und USB-Tastatur nicht mehr stören.
Peter
Die neue Fernbedienung läuft in der Tat nicht mit der alten Konfigurationsdatei. Ich habe mal eben schnell eine neue gemacht (über die Belegung einzelner Tasten kann man sicher streiten). Die Datei hängt an.
Einfach mit gunzip auspacken und in /var/lib/vdr kopieren (ersetzt dort die gleichnamige Datei). Vorher muss VDR beendet werden (/etc/init.d/vdr stop).
Falls eine USB-Tastatur am System hängt, muss die Datei bearbeitet werden und das event0 in jeder Zeile zum Beispiel durch event1 ersetzt werden.
Wem die Belegung nicht behagt, kann leicht eine neue erzeugen, indem er VDR stoppt, die obige Datei (/var/lib/vdr/remote.remote-event.conf) löscht und VDR startet. Bei installiertem remote-Plug-in startet dann der Lernmodus. Bei der Aufforderung, Tasten festzuhalten, schön geduldig sein
Peter
