Beiträge von gabe

    Ich habe gestern mal die Zeitsynchronisation per Transponder im VDR-Menü Einstellungen->EPG deaktiviert. Ist schwer zu sagen, aber ich glaube es ist dadurch besser geworden. Jedenfalls hatte ich gestern nur einen Hänger. Wobei Hänger bedeutet: Befehl(e) wurde(n) nach deutlicher Verzögerung von ein paar Sekunden ausgeführt.


    Das Befehle gar nicht ausgeführt werden, habe ich nur, wenn ich nicht gut genug auf den IR-Empfänger ziele oder wenn die Batterien der Fernbedienung langsam den Geist aufgeben.


    Finde das ganze etwas seltsam. Wieso stört die Zeitsynchronisation? Und außerdem ist LIRC zwar installiert, benutze ich aber nicht, sondern verwende einfach nur das Remote-Plugin für den IR-Empfänger der Nexus-S.


    Hat sonst noch jemand was dazu rausgefunden. Würde nämlich ungerne auf die Zeitsynchronisation verzichten.


    Bye, gabe!

    Das liegt daran, dass die meisten Kauf-DVDs mit CSS verschlüsselt sind. In diesem Forum ist es untersagt, Beschreibungen zur Installation der notwendigen Bibliotheken zu liefern. Deshalb kann ich dir leider nicht helfen. Ich sag nur soviel dazu, dass ct-vdr mit Online-Installation oder Jigdo-Unfree-Update das kann.


    Der Entwickler von LinVDR lässt diese absichtlich aus rechtlichen Gründen weg. Siehe auch http://linvdr.org/wiki/wikiabu…d.php?pagename=LinVDR-FAQ
    unter der Frage "Das Abspielen von DVDs funktioniert nicht".


    Sorry, das ich dein Problem nicht lösen kann, aber wenigstens weißt du nun genauer, woran es liegt.
    Bye, gabe!

    Hallo Leute!


    Hab ein Problem mit meinem VDR (ct-Distribution v3.06). Und zwar reagiert er zwischenzeitlich nicht auf Tastendrücke auf der Fernbedienung. Nach ein paar Sekunden führt er dann aber alle Befehle aus. Und nun die Frage: warum reagiert der VDR manchmal nur verzögert auf die Fernbedienung?


    An der Hardware kann es nicht liegen, da ich früher einen ct-VDR 2.06 am laufen hatte, aber nie diese Probleme auftraten. Hatte auch gedacht, dass irgendwas aus dem Netz den VDR kurzzeitig blockiert (samba, ssh). Aber das Problem tritt unabhängig davon auf, ob ein anderer PC läuft oder nicht.


    Habe noch vdradmin im Visier, aber früher lief der auch ohne Probleme mit. Hat jemand eine Idee oder ein ähnliches Problem?


    Bye, gabe

    Zitat

    Original von TomG
    Mit cdfs hatte ich auch noch nie Probleme. Bei mir geht es mit dem ct-VDR-Kernel 2.4.27 und dem dazu gehörigen cdfs-Modul-Paket. Mit vdrcd habe ich es aber noch nicht probiert.


    Bei mir sieht es ähnlich aus. Habe einfach für das CD-Laufwerk zwei Mountpoints angegeben (z.B. /mnt/cdrom und /mnt/cdaudio). Den ersten habe ich als Dateisystem auto oder iso???? gegeben und dem zweiten cdfs. Dann habe ich beide beim MP3-Plugin als Quellen in der conf eingetragen und kann so neben Daten-CDs mit MP3s auch Audio-CDs mounten und ohne Probleme wiedergeben. Hatte das ganze mit 'nem ct-vdr 2.06 am laufen.


    Bye, gabe

    Hab es gestern Abend nochmal probiert, aber auch ein realmode_poweroff hat nichts bewirkt. Also bleibt wohl nur der Umweg über den Poweroff-Kernel. Das Debian-Paket mit NVRAM-wakeup 0.97-4 ließ sich aber problemlos installieren und FORCE_REBOOT=yes arbeitet perfekt.


    Danke für deine Bemühungen. Ist zwar nicht die perfekte Lösung, aber besser als mein Hack.
    Bye, gabe!

    Danke für die vielen Zustimmungen, aber ich wollte eigentlich nur nochmal festhalten, wie der Stand ist. Aber wenigstens bin ich mit der Meinung nicht alleine.


    Für mich steht fest: an nvram-wakeup selber liegt es nicht. Das ist ein fantastisches Programm und funktioniert ohne Probleme.


    Mit der Option apm=realmode_poweroff habe ich auch schon erfolglos probiert, aber ich habe da auch so viele verschiedene Schreibweisen gefunden: realmode_poweroff, realmode-poweroff und real-mode-poweroff. Weis jetzt nicht genau, ob ich es schon mit Unterstrich probiert habe. Teste ich aber nochmal. In welcher Doku könnte man nachlesen, welche Schreibweise richtig ist? (bin bei Linux noch nicht so lange dabei)


    Die neue Version 0.94-4 hab ich jetzt auch bei e-tobi gefunden. Für alle, die nach was ähnlichem suchen: http://www.e-tobi.net/vdr/sarge/testing/binary/backports/


    Bye, gabe

    Also nochmal zusammengefasst: mit und ohne --directisa wird die Zeit völlig richtig gesetzt. Also der Zugriff auf die Speicherbereiche ist möglich. Außerdem müsste er dann bei einem Testlauf auch eine Fehlermeldung bringen. Gestartet habe ich NVRAM immer über die Konsole (also von Hand). Wenn es da klappt, kann ich das dann ohne Probleme in das VDR-Addon einbauen.


    Starten tue ich meinen normalen VDR mit

    Code
    apm=poweroff noapic acpi=off


    in der lilo.conf (ja, ich hab danach auch lilo ausgeführt). Also mit ACPI und zu fest schlafen legen hat das nichts zu tun. Schlafen wird der übers APM gelegt. Aber das war bei meinem ct-vdr 2 auch so.


    Ein Reboot bringt in dem Sinne überhaupt nichts. Wenn ich VDR wieder normal boote und dann ausschalten lasse, wacht er auch nicht mehr auf. Wenn ich ihn aber gleich nach dem Reboot während der BIOS-Meldungen mit dem Gehäuseschalter ausschalte, dann wacht er zur angegebenen Zeit ohne Probleme auf. Weiterhin kann ich mit dem Shutdown-Kernel der ct-VDR-Distribution den Rechner auch ausschalten lassen und er wacht erfolgreich auf.


    Zusammenfassend: Ja, mein Rechner schläft zu "tief" ein, wenn ich ihm im normalen VDR-Betrieb ausschalten lasse. Der einzigste Unterschied zwischen Poweroff-Kernel und VDR-Kernel ist die Version: Poweroff v2.4.18 und VDR v.2.4.27. Ob es genau am Kernel liegt oder an einer kleinen Änderung in dem APM-Modul ... keine Ahnung.


    Wie gesagt, ich habe es jetzt so eingerichtet, dass ich den Reboot für den Poweroff-Kernel erzwinge und dann funktioniert es auch. Mich würde aber interessieren, was in diesem anders gemacht wird als im normalen Kernel und ob man das vielleicht in den normalen Kernel auch übernehmen kann um den unnötigen Reboot zu umgehen.


    Die Option FORCE_REBOOT="yes" für die /etc/vdr/vdr-nvram-wakup.conf kannte ich noch nicht. Werde ich aber mal ausprobieren, damit ich mir vielleicht den Hack im Shutdown-Hook des NVRAM-Addons sparen kann. Habe aber noch nvram-wakeup v0.97-1 oder v0.97-3. Geht es dort auch? Habe auf der Projektseite auch noch keine Version 0.97-4 gefunden.


    Danke für eure Bemühungen,
    gabe

    Das ganze scheint ein Problem vom APM im Kernel zu sein. Habe mir mal den Power-Off-Kernel installiert und dann folgenden Test manuel gemacht:


    1. Aufwachzeit mit nvram-wakeup setzen
    2. shutdown -r now für Reboot
    3. im Lilo Power-Off-Kernel gebootet
    -> Aufwachen funktionierte


    Vergleicht man die Kernel-Versionen so ist der Power-Off ein 2.4.18 und der ct-vdr-Kernel ein 2.4.27 (oder so ähnlich)


    Jedenfalls arbeiten beide mit dem APM-Power-Off, aber rufen unterschiedliche Effekte hervor. Das klassische Reboot-Problem von NVRAM ist es auch nicht, weil ich mit dem ct-vdr 2 keinerlei Reboot benötigte. Außerdem bringt ein Reboot auch nichts, wenn ich den 2.4.27-Kernel boote und dann ausschalten lasse. Dann funktioniert das aufwachen trotzdem nicht.


    Also bleibt nur der Umweg über den Reboot mit dem Power-Off-Kernel. Dazu muss man in der Datei /usr/share/vdr/shutdown-hooks/S90.nvram-wakeup noch das manuelle ausführen des Reboots eintragen. Einfach bei "case $PIPESTATUS in" für den Fall 0 einfach noch

    Code
    echo "SHUTDOWNCMD=\"$SPECIALSHUTDOWN\""

    einfügen und den dafür notwendigen Parameter

    Code
    SPECIALSHUTDOWN="lilo -R PowerOff ; shutdown -r now"

    in /etc/vdr/vdr-nvram-wakeup.conf eintragen.


    Falls jemand noch einen besseren Weg findet, würde ich mich freuen, darüber informiert zu werden,
    gabe

    Na soweit ich die ct-vdr-changelog verstanden habe, soll dieser Patch ja bei der Version 3.06 enthalten sein. Habe aber auch von vielen anderen gelesen, dass sie ähnliche Probleme mit nvram-wakeup und ct-vdr 3 haben, aber hab noch keine Lösung gefunden.


    Habe auch mal folgendes probiert:
    1. Aufwachzeit mit nvram-wakeup setzen
    2. shutdown -r now für Reboot
    3. manuell ausgeschalten mit Knopf am PC
    -> Aufwachen funktionierte


    Ein anderer Versuch:
    1. Aufwachzeit mit nvram-wakeup setzen
    2. shutdown -r now für Reboot
    3. nach dem Reboot shutdown -h now für Ausschalten
    -> Aufwachen funktionierte nicht


    Das Ergebnis habe ich auch schon in anderen Threads gelesen: Scheint also an der Art und Weise zu liegen, wie Linux den Rechner ausschaltet. Hat sich da irgendwas geändert??? Weiß jemand, wie man da eventuell andere "Methoden" testen könnte?


    Bin für jede Hilfe dankbar,
    gabe

    Vielleicht noch als Hilfe die Debug-Ausgabe von NVRAM. Setze mit dem Aufruf die Aufwachzeit auf 11 Minuten:


    Scheint soweit eigentlich okay zu sein, oder?

    Hallo zusammen!


    Habe heute den neuen ct-vdr in der aktuellsten Version (3.06) und aktualisiert mit jigdo installiert. Danach funktioniert NVRAM-Wackup nicht mehr. Früher mit dem ct-vdr 2 konnte ich problemlos mit --directisa arbeiten. Jetzt wacht er einfach nicht mehr auf. Laut ct-changelog sollte dieser Fehler aber in der Version 3.06 behoben sein, da dort ein Kernelpatch für den Zugriff auf höhere Speicherbereiche fehlte.


    Hat jemand eine Ahnung, wie ich das ganze gelöst kriege? Oder ein anderer Ansatz: wie prüfe ich, ob Zugriff auf die Speicherbereiche möglich ist (also der Kernelpatch auch wirklich enthalten ist)?


    gabe

    Welche Version von ct-VDR ist das denn? Ich habe die Version 2.06 mit einer Nexus-S Revision 2.1 oder 2.2 problemlos zum laufen bekommen.


    IR-Plugin??? Gibt es das überhaupt? Also ich verwende definitiv das Remote-Plugin für die original Happauge Nexus-Fernbedienung.


    Was sagt "evtest /dev/input/event0" und "evtest /dev/input/event1"? Vielleicht gibt es da ja Anhaltspunkte.


    Und mehrere DVB-Karten stecken auch nicht im System?



    Bye, gabe!

    Also ich verwende:


    1. Windows Explorer zum Kopieren ;)
    2. ProjectX zum Demultiplexen (http://www.lucike.info/page_projectx.htm) Das repariert auch ggf. kleine Aufnahmefehler und verhindert Asynchronitäten
    3. Mpeg2Schnitt zum Schneiden (http://www.mdienert.de/mpeg2schnitt/)
    4. Ifo-Edit zum Erstellen der DVD-Dateien (http://www.ifoedit.com/) Hinweis: IfoEdit bietet viele Funktionen, aber hierfür braucht man nur die "Author New DVD" aus dem Menü "Author DVD"
    5. DVD brennen



    Mit (S)VCD kenne ich mich aber nicht so aus. Da müsste dann anstatt Ifo-Edit ein anderes Programm her, welches den Datenstrom auch dementsprechend neu kodiert. Aber die Vorgehensweise bleibt ähnlich wie hier.



    Viel Erfolg beim Schneiden,
    gabe

    Zitat

    Original von Nachzügler
    Lösung 2 funktioniert nicht. Bei einem Test im Windows-Rechener hatte ich das gleiche Phänomen, da die Audio-Daten schon im PCM-Format an die Soundkarte übergeben werden. Dort ist der Codec in aktion. Evtl. funktioniert es mit AC3, das konnte ich aber nicht testen.
    Was funktioniert ist die Aufzeichnung des MPEG2-Streams und die Wiedergabe über Grafik- und Soundkarte.


    Ja, das es bei Windows nicht funktioniert ist klar, da die DVB-Karte ja mit einem Loopthrough-Kabel an die Soundkarte angeschlossen wird (jedenfalls bei mir). Ich dachte aber, dass es bei VDR auch anders ging, aber wahrscheinlich ist das wirklich nur bei AC3 der Fall.


    Wünsch dir aber noch viel Erfolg beim Bieten (Ebay) und beim Löten.


    Bye, gabe

    Wenn ich es richtig verstehe, dann geht nur die Audio-Ausgabe nicht mehr? Aber sonst läuft noch alles? Also da bieten sich für mich zwei Möglichkeiten:


    1. Nutzung der Karte als Zweitkarte und Kauf einer neuen Erstkarte.
    2. Weitere Nutzung der Karte, aber mit einer zusätzlichen Soundkarte zur Audioausgabe.


    Ansonsten würde ich denken, dass so eine Lötaktion mit einer relativ hohen Wahrscheinlichkeit nur noch mehr Schaden macht. Und dann ist man doch auch bloß bei Möglichkeit 1 nur ohne Zweitkarte.


    Wo man so einen Chip beziehen kann, weiß ich leider auch nicht, sorry. Kann dir also nicht wirklich helfen, wollte bloß versuchen, ein paar Alternativen aufzuzeigen.


    Bye, gabe

    riverphoenix: Ich denke, sowas ist sicherlich möglich. Das wäre auch meine absolute Traumvorstellung. Aber das ist alles eine Frage der Freizeit, des Geldes und der eventuell vorhandenen Komponenten. Ich persönlich baue auch gerade meinen VDR in ein Desktop-Gehäuse um. Ist besser als das ganze in 'nem schnöden Midi-Tower rumstehen zu haben. Hatte auch nach verschiedenen Gehäusen geguckt, aber die meisten ansprechenden Gehäuse brauchen MicroATX oder ähnliches. Und da ich meinen alten PC mit ATX-Board recyclen wollte, ist sowas nicht möglich. Klar, wenn man alles komplett neu kauft, kann man sich gleich daran orientieren, aber meiner Ansicht nach wird es dann auch schnell sehr teuer. Für mich war es einer der Vorteile von VDR, dass ich mit einer FF-DVB-Karte, einer neuen Festplatte und zwei leisen Lüftern meinen Festplattenrecorder auf die Beine stellen konnte bzw. kann (arbeite noch dran). Und vielleicht hat Dr. Seltsam auch noch genügend Komponenten rumliegen, die er gerne verwerten möchte.

    Also eine 80GB-Platte hätte ich da glaube ich problemlos zum Laufen bekommen. Meine "128GB" Platte läuft auch ohne Problem, nur dass ich sie als 160 GB Platte gekauft habe. Aber wie beschrieben, handelt es sich dabei um andere Probleme, als man beim 32GB-Bug (und bei 6x gab's glaub ich auch noch einen) hat. Genaugenommen ist es kein Bug sondern die Grenze der Spezifikation. Hatte allerdings auch schon früher Bios-Updates gemacht (bin bei Version 1007 und die Beta ist 1010 oder 1011 glaube ich) durch die die anderen Bugs wahrscheinlich schon behoben wurden.

    Hab mich mittlerweile auch relativ schlau zu dem Thema gemacht bzw. verstehe immer mehr die Zusammenhänge zwischen dem gelesenen (den Beitrag hatte ich natürlich schon über die Suche gefunden). Hier mal meine Erkenntnisse zusammengefasst.


    Normalerweise ist es richtig, und Linux müsste mehr als 128GB adressieren können. Davon bin ich eigentlich auch ausgegangen, als ich mir die Platte gekauft habe. Und eigentlich hätte ich auch mehr Probleme beim Booten erwartet. Jedenfalls ging der erste Boot problemlos. Ungewohnt war nur das leise Zugriffsgeräusch :D


    Bei der 128GB-Grenze handelt es sich diesmal aber wirklich um eine Hardware-Grenze und nicht um einen Hardware-Bug wie bei 32GB und so. Das liegt an der Adressierung mit 28Bit. Da 2^27 gleich 128*1024*1024 sind (und wahrscheinlich ein Bit für Parität oder so, keine Ahnung) können physisch einfach nicht mehr Bytes angesprochen werden. Abhilfe schafft der Wechsel zur 48Bit-Adressierung. Hierbei werden einfach zweimal 28Bit hintereinander gesendet (wo die übrigen 8Bit bleiben, weiß ich auch nicht, sicherlich irgendwelche Verwaltungsdaten). Wenn das Bios booten kann (also Boot-Partition in den ersten 128GB liegt), dann kann Linux diese Geschichte per Software machen.


    Soweit zur Theorie. Aber in der Praxis scheint das ganze dann doch etwas problematischer zu sein. Hier scheint ein Hardware-Bug im Chipsatz vorzuliegen, der die Zweite gesendete Adresse als Extra-Adresse ansieht. Oder anders ausgedrückt: all das, was man über 128GB adressiert, wird einfach Modulo 128GB angesprochen, so dass man seine bestehenden Daten überschreibt, wenn man auf Bereiche über 128GB zugreift.


    Lustigerweise scheint man sich damals schon dessen bewusst gewesen zu sein, da ich gelesen habe, dass neuere Revisionen des Chipsatzes korrekt arbeiten. Im Linux Kernel wurde die 48Bit-Adressierung auch mal für das P5A freigegeben. Als sich dann herausstellte, dass es da zu Problemen (also Datenfehlern) kam, wurde sogar die Revision geprüft, und nur für bestimmte ist dann der Zugriff über 128GB freigegeben.


    Soweit zu meinen Erkenntnissen. Angaben sind natürlich ohne Gewähr. Habe mich aber mittlerweile damit abgefunden, dass es nicht geht, da es scheinbar auch nicht durch ein Bios-Update nachrüstbar ist. Nur das P5A funktioniert halt so gut mit NVRAM-Wackup, so dass ich dann lieber auf die 30GB verschenkten Platz verzichte. Wenn man sich den Preisunterschied zwischen einer 120GB und einer 160GB anguckt (bei meiner ca. 10 Euro), dann kann man damit auch leben.


    Ich danke trotzdem allen, die versucht haben mir zu helfen.
    Bye, gabe!