ZitatOriginal von jeremia
kleini:
Ich hab's genauso gemacht. Ist noch ziemlich unfein, wa?
Ich setze es immer in die /etc/default/vdrdevel hinein, dann bleibt es auch nach einem update intakt.
Ulrich
edit: nächste Mal lese ich den ganzen thread bevor ich antworte, versprochen.
ZitatOriginal von ingouk
ich habs versucht. nur leider meckert vdrconvert nun das es keine audiospuren gibt.allerdings habe ich bemerkt das vdrsync die spuren nun anders benennt und have das auch so in der vdrconvert.dvd.conf angepasst:
aus bd.ac3 habe ich vdrsync.ac3 gemacht und bei den c0 und c1 ebendso.
muss ich noch was aendern? hab auch den pfad in vdrconvert.conf angepasst der auf vdrsync.pl zeigt.
Ingo
Hallo,
wenn ich es mir recht überlege habe folgendes gemacht:
1. altes vdrsync + vdrconver -> klappt nicht
2. burn-plugin installiert und nochmal probiert -> klappt auch nicht
grübel -> auf vdr-portal gesucht, Hinweis auf vdrconvert erhalten
3. neues vdrsync + burn-plugin -> klappt 
Dass die Kombination neues vdrsync + vdrconver weiterhin Probleme machen kann, daran habe ich gar nicht gedacht. Sorry.
Ulrich
Schon mal das vdrsync von http://vdrsync.vdr-portal.de/releases/vdrsync-050322.tgz probiert?
ZitatChanges 22nd of March, 2005
vdrsync.pl:
----------
- just another attempt to handle ac3 streams, that have changed again in
vdr-1.3.23
Ulrich
----------------------
edit: zumindest bei mir funktioniert es.
Ich habe folgendes bei mir probiert:
- jumpplay abgeschaltet: Das Problem bessert sich
- firmware 261c verwendet: es "klemmt" weniger aber dafür ist der Ton oft und deutlicher asynchron.
- NPTL check herausgenommen (und NPTL eingeschaltet): sieht gut aus, allerdings muss ich noch etwas testen ob eventuell andere Probleme auftreten.
Ich verwende übrigens ct-vdrdevel auf Debian testing mit Kernel 2.6.11.5. Hardware MSI Hermes 651 mit nova + nexus.
Ulrich
-----------------------------
edit:
NPTL löst das Problem auch nicht wirklich: jetzt verwende ich den vdr 1.3.17.
falls es dich beruhigt: ich habe ähnliche Probleme.
Aussetzer beim Abspielen (die Aufnahmen sind in Ordnung): er scheint sich irgendwie zu verklemmen (nach einem vor-/zurückspulen verschwindet das Problem).
Wenn ich mich recht erinnere trat das Problem nicht mit der alten Firmware auf (dann gibt es aber auch kein ac3).
Ulrich
ZitatOriginal von thorsten.gehrig
Klaro - wenn ich das gescripted kriege - und die Boot-Partition gescripted zu unmounten / backupen / remounten kriege ich nicht hin
Du müsstes ein Reserversystem auf der Platte haben (irgendwo hinten auf der Platte, 1/2 Gbyte reichen völlig). Zeitgesteuert könntest du einen Reboot auslösen, der das zweite System genau einmal booted bootet (grub-reboot, mit lilo geht es aber auch). Dieses Zweite System kann dann partimage passend aufrufen. Noch ein reboot und das Hauptsystem läuft wieder.
Ulrich
Ich gestern folgendes ausprobiert:
mit 'cp -avu / /mnt' habe ich eine identische Kopie der Root-Partition erstellt. Danach habe ich nur das nötigste angepasst (/etc/fstab, grub) und das kopierte System (zweite Platte) gebootet. Dieses System läuft jetzt seit fast 24 Stunden ohne Absturz.
Anscheinend gibt es also einen wichtigen Unterschied, ob man Debian Testing neu installiert oder ein altes CT auf Debian Testing updatet. Was der Unterschied ist und warum er zu ständigen Abstürzen führt: keine Ahnung. Die üblichen Verdächtigen (Kernel, Module etc.) habe ich eigentlich ausgeschlossen.
Ulrich
Ich habe die Kabel an den Festplatten vertauscht -- ohne Wirkung. Also entweder hat eine Festplatte einen seltsamen Defekt, der bei längerer Inaktivität zum Absturz des Systems führt (ohne Eintrag in den Log-Dateien) oder bei einer Debian-Neuinstallation wird doch etwas anders gemacht, was zu den Problemen führt -- oder etwas ganz anderes.
Ich komme frühestens am Wochenende dazu etwas neues auszuprobieren.
Ach so: ich habe keine WLAN-Karte im Rechner.
Ulrich
Ich hatte gestern versucht per hdparm auf udma2 zu schalten -- auch ohne Erfolg.
Kann sich eigentlich eine Platte zu Tode langweilen und dabei das System mit herunterreißen? (wenn ich das neue System boote und vdr nicht läuft, ist auf hdc nichts los)
Ulrich
ZitatOriginal von gabe
Auch wenn das jetzt vielleicht ein bisschen seltsam klingt: wenn du einfach mal die beiden Platten vertauchst?
So seltsam klingt das gar nicht, viel mehr bleibt auch nicht übrig. Vorher werde ich allerdings die Kabel der Platten tauschen (hda ist mit einem 80-pol Kabel angeschlossen und läuft daher mit udma5, hdc nur mit einem 40-pol Kabel und läuft mit udma2).
Allerdings werden im normalen Betrieb immer beide Platten benutzt (auf hdc liegt /var/lib/video.00, auf hda /var und /home -- der Rechner arbeitet auch als File/Mailserver).
Nur / und ein swap-Bereich ist auf beiden Platten vorhanden (sowie ein unbenutztes /var und /home auf hdc)
Schaun wer mal, bis jetzt hat die neue Installation durchgehalten (mit CONFIG_DRM_SIS=y).
Ulrich
--------------------------------------------------------------------------------------------------------------------
Tja das wars dann, gerade eben hat es ihn erwischt. Jetzt läuft wieder die alte Installation.
Nun,
nachdem der Rechner heute nacht per cron in das neue System gebootet hat hat er nur eine gute Stunde durchgehalten. Allerdings war die Konfiguration des DSL-Zuganges fehlerhaft (ich versuche beide Systeme syncron zu halten, dabei ist mir ein Fehler unterlaufen) das führte dazu, dass jede Minute der ppp neu gestartet wurde -- denkbar das dies den Absturz verursacht hat.
Das habe ich beseitigt -- mal sehen ob er den Tag durchhält.
Wenn nicht, gehen mir langsam die Optionen aus:
- die Bioseinstellungen werden naturgemäß nicht angetastet
- der selbe Grub startet die Systeme
- auf beiden Systemen ist der gleiche Kernel installiert
- auf beiden Systemen ist der gleiche Vdr, Lirc-Module etc. installiert
- alle systemnahen Programme (Hotplug, Module-Init-Tools, ...) sind in gleichen
Versionen installiert.
Eigendlich bleiben dann nur noch die Platten über ?(.
Das kann ich kaum glauben (kein Interrupt-Sharing bei den Platten ...)
Ulrich
StayCool: Nicht wirklich, auch nach Installation der console-tools gab es einen Abgang, obwohl mittlerweile alle hardware/kernel-nahen Aspekte bei der alten(=laufenden) und neuen(=crashenden) Installation gleich sind :wand.
Mein nächster Versuch ist es einen Kernel zu verwenden, beim dem CONFIG_DRM_SIS=y gesetzt ist.
(Zitat auf www.winischhofer.net: "Kernels >= around 2.6.3 do not need sisfb any longer for DRI memory management. The SiS DRM driver has been updated and features a memory manager of its own (which will be used if sisfb is not compiled). So unless you want a graphical console, you don't need sisfb.")
Diesen setze ich zunächst auf dem alten (=sicher laufenden System) ein. Irgendwann heute abend werden ich dann auf das neue System wechseln. So Ende der Woche kann ich dir sagen, ob es etwas gebracht hat. (Ist halt wirklich zäh, durch ausprobieren einen Fehler zu finden, der vieleicht zweimal pro Tag eventuell aber auch nur zweimal pro Woche auftritt)
Ulrich
Im Paket
http://www.e-tobi.net/vdr/sarg…drconvert_0.1.1-4_all.deb
befindet sich die folgende Datei :
/usr/lib/vdrconvert/bin/.vdrconvert.sh.swp
Ist das korrekt so? Und wenn ja, welche Funktion hat diese Datei?
Ulrich
Ist zwar eigendlich blödsinning sich selber zu antworten, ich mache es aber trotzdem in der Hoffnung anderen Leuten zu helfen die Probleme mit ihren Kenwoods haben (und Suchfunktionen benutzen können!):
Ersatzfernbedienungen zu Kenwoods gibt es bei Franke Electronic.
Allerdings hat dies mein Problem nicht gelöst, das Problem lag beim Receiver (das dieser Defekt zu dem Zeitpunkt auftrat, als jemand auf die Fernbedienung getreten hatte, war nur ein dummer Zufall).
Der IR-Empfänger ist wohl bei einigen älteren Kenwoods nur per kalter Lötstelle auf die Platine hinter der Frontplatte gelötet. Dies führt nach einiger Zeit zu Ausfällen.
Dies kann relativ leicht selbst behoben werden:
- Gehäusedeckel abnehmen (8 Schrauben vorher lösen), die Vorderseite ist unter der Front eingehackt -> hinten anheben, nach hinten wegziehen
- Frontplatte lösen (vorher die 4 Schrauben an der Unterseite lösen)
- die drei Kabelverbindungen lösen (eventuell kann man aber auch das etwa empfindliche Flachbandkabel rechts drin lassen)
jetzt hat man die Front in der Hand, bei der Sicht auf der Platine von innen liegt bei meinem Exemplar der IR-Empfänger etwa 3cm von der Mitte des einzigen Chips entfernt (in Richtung rechts-oben). Es sind drei Pins, die im Gegensatz zu den meisten anderen Pins, nicht umgebogen sind. (Wenn man den Emfänger nicht findet kann man auch mit einer hellen Lampe die Vorderseite anstrahlen, dann sieht man auch wo der Empfänger liegt).
Nachlöten, zusammenbauen, läuft.
Ulrich
Hallo,
den xxv finde ich klasse und angesichts der Tatsache, dass er noch recht neu ist, funktioniert er hervorragend.
Mir ist folgendes aufgefallen:
- der Vdr löscht nicht immer alte Timer wenn diese abgearbeitet wurden. Kann man eventuell eine Funktion einbauen, dass Timer die weit in der Zukunft liegen (z.B. 25 Tage) einfach gelöscht werden (plugin)?
- in der gleichen Kerbe geht eine weiterer Vorschlag: Ich nehme z.B. logo per Autotimer auf, das führt zu sehr vielen Einträgen in der Timertabelle. Könnte man den Autotimer eventuell so konfigurieren, das z.B. keine events eingetragen werden die weiter als z.B. 2 Tage in der Zukunft liegen bzw. mehr als z.B. 3 Events pro Autotimer?
-------
edit: wo ich so darüber nachdenke -- gibt es das Feature vieleicht schon (zweiter Radibutton)? Ich hatte das so interpretiert, das man die nächtliche Wiederholung ausblenden kann. Muss ich mir nochmal ansehen.
-------
Beides soll dazu dienen, die Timertabelle übersichtlicher zu machen.
Ansonsten ist mir eine kleiner Fehler aufgefallen. Ich habe einen Autotimer neu angelegt: "enterprise" auf "Sat.1". Kurioserweise wurde auch "enterprise" auf "Sat.1 A" (Österreich?) gefunden. Beim editieren des Autotimers ist dieser Effekt verschwunden.
Ulrich
Eine meine Theorien ist, dass der shared-mem VGA im Hermes eine Macke hat (bzw. vom Bios nicht korrekt initialisiert wird). Gründe für diese Vermutung:
- Wenn der shared-bereich sehr klein eingestellt wird (z.B. 4MB) liefert memtest86 reichlich Fehler und der Rechner wird extrem instabil (Abstürze schon beim Booten).
- Ggf. hilft der Framebuffer bei Stabilitätsproblemen:
http://www.vdr-portal.de/board/thread.php?threadid=4361
- Ich habe nach Unterschieden in der neuen und alten Installation gesucht: soviel ist nicht mehr übrig: Bei der neuen installation habe ich die console-tools als vermeintlich unnütz weggelassen, allerdings werden von /etc/init.d/console-screen.sh einige Einstellungen vorgenommen (screen-blanking, DPMS, font). Denkbar, dass es daran liegt.
Schaun wer mal, ob der Rechner heute nacht wieder eine Pause einlegt ...
Ulrich
ZitatOriginal von StayCool
als glücklicher (neuer) Debianer bin ich von SuSE auf Sarge umgestiegen. Leider habe ich das Problem das mein Hermes P-651 regelmäßig einfriert. Dies betrifft einen Zeitraum von 1/2 bis mehrere Stunden bei Inaktivität (kein Zugriff via Konsole bzw. ssh).
Ich habe (nach Einbau einer zweiten Platte anstelle des dvd-Laufwerks) auch Stabilitätsprobleme mit dem Hermes P-651. Der Effekt ist ganz seltsam: boote ich das alte System läuft alles, boote ich das neu installierte System (auf der zweiten Platte) bleibt er irgendwann stehen (anscheinen insbesondere dann, wenn er überhaupt nichts zu tun hat).
Ich habe alles mögliche ausprobiert: u.A. auch den Kernel der alten Installation benutzt -- ohne Erfolg.
Denkbar, dass es gar nicht an ACPI/Kernel/Bios liegt, sondern an sonstigen installierten/nichtinstallierten Programmen (console-tools? ntp-server?).
Ulrich
Ich würde an deiner eher apt-proxy verwenden.
ZitatOriginal von BigDiSt
Das Ding ist nur, die lernt nix, und taugt daher nicht zum steuern der Lautstärke über TV/Receiver.
Apropos Lernfähig: Es gibt doch Bauanleitungen für kombinierte Lirc Sender/Empfänger. Es sollte doch möglich sein soetwas wie eine Kodeumsetzung zu bauen (Vdr/Lirc empfängt Kode z.B. für Lautstärke höher und sendet dann denn passenden Kode zum Receiver).
Ist soetwas schon mal gemacht worden? Wenn ja: dann braucht man doch gar keine teure lernfähige Fernbedienung.
Ulrich
