Posts by poggenpower

    Hallo Zusammen,


    weil es schwierig ist bei Problemen mit dem eventlircd dem Problem auf den Grund zu gehen, hier ein paar Tips, die mir geholfen haben.


    Natürlich sollte man erst einmal folgendes gelesen haben:
    http://www.yavdr.org/documentation/0.5/de/ch02s03.html


    Wenn Du eine spezielle Fernbedienung wie die Rii mini i25 nutzt, dann kümmert sich eventlircd nicht automatisch drum.


    Am einfachsten überprüft man, welche Input devices von eventlircd gelesen und an den VDR weitergegeben werden mit:



    Damit sieht man, welche Prozesse diese devices benutzen. In diesen Fall ist 1865 die Prozess ID des Eventlircd.


    Wenn man hier sieht, dass eventlircd sich nicht um die Events kümmert sollte man ein Blick auf die UDev Regeln in:

    Code
    1. /lib/udev/rules.d/98-eventlircd*


    schauen.
    Wenn das eigene Device nich berücksichtigt wird, (Eigenes Device findest Du mit lsusb, cat /proc/bus/input/devices) ist es vielleicht nötig UDEV beizubringen das Device an Eventlircd zu hängen.
    Das macht ihr am besten mit einer eigenen Datei.
    Hier mein Beispiel:



    Ob es nötig ist auf eine Eigene Eventmap, wie im obigen Beispiel zu verweisen oder einfach auf eine bestehende, musst Du schauen.


    Vielleicht helfen diese Infos weiter.


    Gruß
    Thomas

    Moin,


    nach dem Kernelupdate auf 2.6.38-16-generic ließ sich zwar das Kernelmodul, wie beschrieben übersetzen, aber es wurde nicht beim Start bzw. einstecken der Karte erkannt.
    Geholfen hat das Umsteigen auf einen neuen Codezweig.
    Wie in http://www.dvbshop24.com/index.php/topic,10604.0.html funktioniert der Code für den 3.x-er Kernel. Der ist allerdings nicht mehr unter dem Link erreichbar.
    Hier http://www.dvbsky.net/Support.html wird man fündig. Ich habe die Version media_build_bst_121102</big> verwendet.


    Weiter sollte man auch die Firmware von der Seite in /lib/firmware ablegen.


    Danach lief bei mir das ganze wieder.


    Viele Grüße
    Thomas

    Hallo Albert,

    Gib mal hier in Forum im Suchfeld (oben rechts) Unicable ein. Nicht vergessen: Du musst danach auf dem grünen Pfeil daneben rechts klicken. :wow

    Wenn man diese Suchfunktion benutzt, findet man leider nix zu der besagten Fehlermeldung.
    Daher einfach mein Artikel, damit jemand anderes mehr Glück beim suchen hat.


    Ich wollte nicht simpel bekannt geben, dass jetzt Raider jetzt Twix heisst.


    Gruß
    Thomas

    Hallo,


    hier ein Stück Hinweis, weil ich gerade drüber gestolpert bin.
    Mit dem Update auf VDR Version 1.7.22 wird das Unicable Zeugs in SCR umgetauft.
    Genaueres findet ihr unter:
    http://www.vdr-wiki.de/wiki/in…Single_Cable_Distribution
    bzw.
    http://www.vdr-wiki.de/wiki/index.php/Unicable-patch


    Nach den Update müsst ihr sowohl die diseqc.conf anpassen (U durch S ersetzen), als auch die Datei unicable.conf in scr.conf umbenennen.
    Wenn ihr letzteres nicht macht, wirft der VDR folgende Fehlermeldung:


    ERROR: no free SCR entry available for device 1


    Weil er nicht weiss, auf welcher Frequenz er auf dem Kabel lauschen soll.
    Die Fehlermeldung bekommt ihr natürlich auch, wenn ihr gar nichts konfiguriert habt. ;-)
    Also die scr.conf noch mal checken!


    Gruß
    Thomas

    Da das oben beschriebene bei mir nicht funktioniert hat, hier meine Lösung:


    Es gibt zwei Einstellungen, die Verändert werden müssen, das Einfachste ist zwei GUIs installieren.Zum einen das Tool "obconf" (aptitude install obconf) um die Einstellungen von Openbox zu verändern. Hier wirkt sich in den meisten Fällen wirkt sich hier nur die Einstellung für den Window-Titel aus, denn unter X wir rel. streng zwischen Windowsmanager und Anwendung unterschieden.
    Der Firefox wiederum benutzt wie viele andere auch das GTK Framework zur Darstellung seiner Fensterelement.
    Hier hilft das Tool "gtk-chtheme" (erst installieren). Einfach in der untersten Zeile die Schriftart ändern. Die anderen Einstellungen würden sich nur auswirken, wenn der Windowsmanager auch auf GTK beruhen würde.


    Ach ja die Openbox-Settings musst Du als root durchführen, also "sudo obconf". Die anderen Settings machst Du unter dem User, den Du bei der Installation angelegt hast und den Du auch für den SSH Login benutzt.


    Da die beiden Tools eine grafische Oberfläche haben, musst Du einen X-Server haben. Also entweder hast Du auf Deinem Windows etwas installiert und machst einen ssh -X user@vdr oder Du startest einen XTerm auf dem VDR selbst (Menu - 6 - 4 - 1).


    Bei mit sind Schriftgrößen zwischen 18 und 20 gut lesbar.


    Gruß
    Thomas

    Hallo,


    ich habe einfach mal die Entwickler der Treiber für obige Karten geschrieben und sie haben mir einen Patch und die Version der Sourcen von linuxtv.org geschickt.
    Damit konnte ich bei mir auch die Treiber noch mal erfolgreich bauen ohne einfach die kompletten Sourcen von dvbkey zu nutzen.


    Gibt es einen Weg und Willen diesen Patch auch dem yaVDR einzuverleiben?


    Die Entwickler haben schon zugestimmt die Sourcen auch in den Upstream zu geben. Müssen sie auch auch. Ist ja GLP ;-)


    Wenn hier vielleicht der ein oder andere den Treiber getestet hat, würde ich auch Kontakt zu linuxtv.org aufnehmen, dass der Patch auch hier einfließt.
    Oder ließt hier vielleicht sogar ein LinuxTVler hier mit!


    Gruß
    Thomas

    Soweit waren wir ja auch schon. Deshalb ja der Ansatz mit der Initrd. Da die Skripte reinmachen, dann braucht auch nichts gemountet werden. Wenn man eine extra-Initrd dafür vorhält, dann hält sich der Pflege-Aufwand auch in Grenzen.

    Das war ja auch meine Idee, nur nach der Untersuchung, ist der Aufwand nicht trivial, denn die pm-utils scripte sind recht umfang reich und mir einem reinen Kernel-Mode-S4 ist mein System nicht sauber suspended.
    Das pm-hibernate script will auf die Platte schreiben. Braucht bash und perl.
    PM-hibernate greift auf Devices zu, die erst mit dem Start von UDEV existieren.
    uswsusp benötigt noch ein paar Dinge mehr.


    Das alles in eine intird zu frickeln ist doch eine ganze Menge Aufwand, davon mal ganz abgesehen, dass dann jeder Fehler mit einer kernel panic endet und man kein Logfile hat, macht das Leben auch nicht einfacher.


    Daher habe ich mich für den alternativen init-Zweig entschieden.


    Das kein richtiger unmount gemacht wird halte ich auch nicht für so tragisch. Zum einen wird ja eine journaling FS eingesetzt und zum anderen sind die Änderungen man FS hier nicht kritisch, so dass keine wichtigen Informationen verloren gehen sollten.


    Gruß
    Thomas

    Update,


    ein alternatives /etc/init-Verzeichnis kann ich jetzt ansprechen. Der --confdir Parameter wird nur akzeptiert, wenn noch kein anderes Init läuft.


    Das habe ich gebaut:

    • Das ganze wird einfach über einen Kernelparameter beim booten angesprochen init=/sbin/init-s4.
    • init-s4 ist ein shellscript, dass init mit /etc/init-s4 als Config startet.1
    • nach /etc/init-s4 habe ich die notwendigsten conf's kopiert.
    • Das System startet in einer Minimalkonfiguration, ohne zusätzliche Module zu laden.
    • Es gibt eine s4.conf, die das System automatisch auf der Platte einfriert.

    Vorteile aus meiner Sicht.

    • kein Eingriff in die bestehenden init-Scripte
    • einfach zu warten, da eigens Verzeichnis, kein backen und aktualisieren eine initrd
    • Das Haupt-System wird sauber herunter gefahren. Alle Trigger etc. werden abgearbeitet.
    • Einfacher Start, Grundgerüst ist schon für den Poweroffkernel gebaut. Es muss nur eine Grub-Konfig in /etc/grub.d abgelegt werden.
    • Da das Orignal System gebootet wird, stehen alle Anpassungen auch im S4 zur Verfügung. Packetupdates müssen nicht portiert werden.

    Nachteile

    • Das System wird einmal mehr gebootet, aber nicht beim starten, sondern beim Beenden, was zu tollerieren ist.
    • Das System moutet auch im s4 die Platten RW, damit die Scripte laufen. Die werden nicht sauber unmouted. Da aber an wenig läuft, kann auch wenig kaputt gehen. man könnte noch drüber nachdenken, ein FS drüber zu legen, wie bei den Live-CDs, dass passieren die Änderungen nur im RAM, man hat dann aber auch kein logging.

    Was noch zu tun wäre

    • Script bauen, dass für den aktuellen Kernel einen angepassten Eintrag im Grub erzeugt.
    • Config und Templates bauen, die das ganze in die yaVDR Logik integrieren.
    • Paket bauen.

    Bevor ich hier in Schönheit sterbe, hier die Frage an die Experten. Was haltet ihr von der Lösung ist das was, was in den yaVDR integriert werden kann/soll? Will jemand mal testen? Kann mir jemand bei der Anpassung für den yaVDR helfen (WFE, Templates, Paket)
    Gruß
    Thomas

    ich hab hier indertat nicht den besten empfang, bei hd kanälen sagt femon 45%, gut femon is ja nur ein schätzeisen, aber könnte schon möglich sein, das hier der fehler liegt. Greifst du über ssh zu, oder konfigurierst du den Rechner lokal? ssh ist nämlich kaum nutzbar, wenn der fehler auftritt.


    Noch ne andere Sache, wie siehts eigentlich mit support für linux-media aus? Die Treiber bauen ja leider nur bis Kernel 38.



    Hi,
    schaust Du Dir das Log in einem TTY auf dem System an? Damit kannst Du Dir das ganze lahm legen, wenn mehr Events kommen, als das TTY darstellen kann, kommt Du in IO Probleme.
    Das ganze per SSH oder WFE anzusehen ist da ressourcenschonender, auch wenn man das erst mal nicht denkt.


    Gruß
    Thomas

    thl@lenz:~$ sudo init --confdir /etc/init
    init: invalid option: --confdir
    Try `init --help' for more information.
    thl@lenz:~$


    Der Parameter funktioniert bei mir nicht. Auch auf einem "normalen" Ubuntu nicht. Hat jemand eine Idee?


    Ahh jetzt ja, ein --session scheint zu helfen, dann startet Init auf jeden Fall.
    Doof ist nur, dass der Parameter von den Entwicklern als "nur für Testzwecke" gekennzeichnet ist.


    Mal sehen, wie weit ich komme.


    Gruß
    Thomas

    Ich habe seit ein paar Tagen zunehmend folgende Fehler. Erst dachte ich es seinen noch Auswirkungen des Sturms, aber jetzt bin ich mir nicht mehr sicher, ob es nicht doch ein Problem ist.
    Mein Fernseher mit eigenem DVB-S2 Receiver macht keinen Ärger.


    Hier die Fehler die ich habe:

    Code
    1. TS continuity error (6)
    2. Jan 8 00:52:05 poempel vdr: [3340] PES packet shortened to 5790 bytes (expected: 6158 bytes)
    3. Jan 8 00:52:06 poempel vdr: [3340] TS continuity error (7)


    Das in Schüben. Dabei bleibt das Bild mit Artefakten stehen. Interessant ist, dass die empfangene Größe oft 5790 oder 5606 Byte sind.


    Hat jemand eine Idee, an welchem Ende die Daten verloren gehen? Eher von der Schüssel zur DBV Karte oder von der Karte über USB zum VDR?


    Gruß
    Thomas