Beiträge von TeeRose

    Also, meine channes.conf ist sehr voll (>1300 Kanäle, aber fast alles Müll), könnte ein Hinweis sein. Den epgscan von VDR habe ich deaktiviert.


    Epgsearch hatte ich auch schon in Verdacht, aber das Scannen der Autotimer ist laut syslog immer recht kurz. Da kann solch eine Beeinträchtigung sicher nicht her rühren. Allerdings habe ich den Verdacht, dass diese Lirc-Beeinträchtigung vermehrt auftritt, wenn ich bei epgsearch z.B. in den Senderlisten für "jetzt" oder "nächste" rum scrollen will.


    In der Tat verfolgt mich das Phänomen auch schon diverse Kernel-, VDR-, Lirc- und Plugin-Versionen. Deswegen kann ich auch nicht sagen, ob es dirket an einer Umstellung gelegen hat. Mittlerweile nervt es doch arg und der WAF sinkt :(

    Ich benutze den IR-Einschalter von www.atric.de. Dort ist ein TSOP1736 oder TSOP1738 verbaut. Allerdings habe ich mittlerweile drei Empfänger parallel geschaltet, damit ich aus den verschiedenen Räume den VDR steuern kann. Das klappt auch sehr gut.


    Doch manchmal scheint wirklich der lircd zu blockieren. Ich drücke quasi im Sekunden-Dauerfeuer die up-Taste. Er verschluckt dann sämtliche Tastendrücke. Irgendwann nimmt dann der lircd die Signale entgegen und schaltet um. Ein paar wenige Tastendrücke hat er dann gequeued. Der Programm springt dann von 1 in schneller Folge auf auf z.B. Programm 7. Aber viele, viele der Tastendrücke hat er "verpennt".

    Hallo zusammen,


    ich beobachte seit längerem schon ein merkwürdiges Phänomen. Grundsätzlich läuft mein VDR sehr stabil und die Anbindung der Fernbedieung über lirc klappt gut.


    Doch manchmal reagiert der VDR minutenlang nicht auf die Fernbedienung. Irgendwann geht es dann wieder, ohne dass ich am System irgendwas neu starte oder einen Prozess kille. Ich habe versucht, das Problem einzukreisen, mir gehen aber die Ideen aus.


    Gestern war die Load des System z.B. 0.31, was ja - auch bei meinem System (siehe Signatur), nicht viel ist. Lirc lief und irw parallel gestartet protokollierte keine Tastendrücke. Im Syslog gibt es keinerlei Hinweise.
    Nach ca. 3-4 Minuten hat dann auf einmal irw einen Tastendruck protokolliert und der VDR regiert prompt auf die Fernbedienung.
    Der VDR hat nichts aufgezeichnet oder eine Aufnahme abgespielt. Das System war auch nicht mit anderen Tasks beschäftigt.


    Hat jemand vielleicht einen Idee, woran es liegen kann?


    Viele Grüße
    TeeRose

    Hallo,


    der Parameter heißt:

    Code
    InitialVolume = 255


    Ich hatte in meiner runvdr immer eine Zeile vor dem eigentlichen Start des vdr hinzugefügt, die so beim Rechnerstart die Lautstärke auf 255 setzt. Aber wie oben schon erwähnt, ist das seit einigen Versionen nicht mehr nötig, habe ich aber trotzdem noch drin.


    Code
    # Lautstaerke in der Config auf Maximun setzen
    sed -e "s/CurrentVolume = .*/CurrentVolume = 255/" -i /etc/vdr/setup.conf


    Viele Grüße
    TeeRose

    Hallo,


    früher war im BigPatch mal enthalten, dass beim Beenden noch der EPG geschrieben wurde. Dies ist für mich wichtig, da ich täglich um 5.00 Uhr den EPG (erst Infosat und dann noch durch die Channel zappen) scanne.


    Seit einiger Zeit vermisse ich in der vdr.c den Patch, der die Zeile mit dem Cleanup einfügt:


    Code
    Exit:
    
    
      PluginManager.StopPlugins();
      Schedules::Cleanup(true);
      cRecordControls::Shutdown();


    Frank99, kannst du das bitte wieder aufnehmen? Das wäre super.


    Viele Grüße
    TeeRose

    Fehlalarm, burn kommt jetzt nur bis ca. 1.5GB und bleibt an folgender Stelle hängen, ohne dass ich weiß, was los ist. Die Prozesse sind noch da, aber es tut sich nichts mehr:


    Hallo zusammen,


    ich habe jetzt mal mein Verzeichnis /tmp gelöscht, welches auf einer Partition mit nur ca. 130 MB freiem Platz war.
    Dann habe ich einen Link von /tmp auf /data/video0/tmp gelegt, also ein Verzeichnis in meiner Video-Partition, welche noch zig GB freien Platz hat.


    ...und siehe da, jetzt läuft meine ansonsten gescheiterte Zusammenstellung, und das mit Requantisierung. :)


    Von Dauer will ich aber diese Frickel-Lösung mit dem umgebogenen /tmp nicht haben. Also muss ich mal die Einstellungen in den Skripten rund um burn prüfen.
    1. Im vdrburn-dvd.sh ist mehrfach /tmp in den einzelnen Befehlen (beim render), was vermutlich nicht das Problem ist.
    2. Da wäre im vdrsync.pl eine Variable für tmp: $tmp_dir. Vermutlich kann ich damit etwas bewirken. Habe ich aber noch nicht getestet.


    Oder kann ich irgendwo in einer config zum Plugin burn etwas einstellen?
    Es gab ja mal die Config-Datei .../conf/plugins/burn/vdrburnscript.conf.
    In wie weit dort welche Parameter noch gültig sind, steht leider in keinem aktuellen Readme. Schön wäre es, wenn man dort ein alternatives tmp angeben kann. Dann braucht man nicht die vdrsync.pl zu ändern.


    Viele Grüße
    TeeRose

    Hallo zusammen,


    ich habe die zwei Tipps (Patch von Thomas und Änderung von hjwd) von oben ausprobiert, aber leider ohne Erfolg für meinen Fehler.


    Der Requantisierungsfaktor ist nun <>1.12. Aber dennoch bleibt das Requantisieren in dem Beispiel bei 40MB stehen.


    Kann das evtl. daran liegen, dass per Default das Verzeichnis /tmp für irgendwelche Dateien herhalten muss. Meine root-Partion (mit /tmp) hat allerdings nur noch 131 MB frei.
    Allerdings benutzt burn auch mein Verzeichnis /data/video0/.vdr-... und zusätzlich liegen Dateien in /tmp/.


    PS: Ich habe mir auch den neuesten Snapshop aus dem burn-cvs gezogen, wie im VDR-Wiki zum burn-Plugin erwähnt:

    Code
    cvs -z3 -d:pserver:anoncvs@vdr-developer.org:/var/cvsroot co burn


    Aber auch hier bleibt mein Brennversuch stehen.
    Und ich habe gesehen, dass Thomas Patch wohl schon eingearbeitet ist. :)


    Viele Grüße
    TeeRose

    Hallo,
    ich habe jetzt mal von 128Mb auf 640MH Hauptspeicher aufgerüstet. Allerdings bricht der burn-Vorgang immer noch ab, wenn ich z.B. wie hier 5 Star Trek Folgen auf eine DVD bringen will und burn das Requantsieren aufruft:



    Die Prozesse rund um burn hängen, sind aber noch da:


    Woran kann das liegen?


    Viele Grüße
    TeeRose

    LordJaxom:


    Gibt es hier schon eine Lösung von dir zum burn-Plugin?


    Bei mir bleibt mit burn-0.1.0-pre2 immer die Konvertierung stehen, sobald ich soviel auf eine DVD quetschen will, dass das requatisieren notwendig wird. DVD erstellen ohne requant geht problemlos.


    Ich habe ebenfalls nur 128 MB RAM.


    Viele Grüße
    TeeRose

    Hallo,


    meine knapp über zwei Jahre alte Samsung SV1203N muckt jetzt auch rum:


    - Mein VDR will ständig die eine Partition hda5 (95GB, ext3) mit fsck überprüfen bzw. ich soll das manuell machen
    - Bein Booten wird manchmal nicht der DMA Modus gesetzt. Ein Hotfix-Skript von mir überprüft das nun alle 5 Minuten.
    - Das Checktool shdiag hat bisher die Platte noch nicht erkannt, kann aber am Rechner liegen. Ich muss das noch einmal testen


    Deshalb wollte ich jetzt mal bei Samsung auf der Webseite http://www.samsungindia.com/sc…lace/hdd_replace_wcms.asp überprüfen, ob ich noch Garantie bei Hersteller habe. Leider sagt mir die Webseite, dass die S/N und die P/N nicht in der Datenbank ist.
    Was ist da los?
    Hat jemand von euch ähnliches bemerkt?


    Viele Grüße
    TeeRose

    Hallo Winni,


    ein ähnliches Feature wie die maximale Vorhaltezeit in Tagen für z.B. Nachrichten habe ich beim Shutdown in einem Skript eingebaut. Als Feature in epgsearch finde ich die Idee sehr gut.


    Ich möchte kurz ein weiteres Feature anregen, was evtl. einige User für sinnvoll halten könnten.


    Ich habe in meinen Aufräumskript eine Routine, die die Anzahl Aufnahmen in einem Unterverzeichnis begrenzt. D.h. ich nehme z.B. Sandmännchen immer in ein Verzeichnis auf. Das Skript schaut also bei jedem Shutdown nach, ob dort mehr als 4 Aufnahmen existieren. Wenn es mehr gibt, dann wird halt die älteste gelöscht. So habe ich immer einen gewissen Vorrat.
    Wenn das ganze in epgsearch integriert werden sollte, müsste die Löschroutine so intelligent sein, dass keine Aufnahme verworfen wird, die gerade geschaut wird.


    Viele Grüße
    TeeRose

    Nachdem ich die beiden Platten als hda und hdb am ersten IDE-Port mit einem 80poligem Kabel habe, sind die Fehler zurückgegeangen, aber noch nicht komplett eliminiert. Ich betreibe die beiden Platten nun mittels "hdparm -X68 ..." nun im UDMA-4-Modus.


    Kernel ist nach wie vor 2.6.14.

    Ich habe einiges probiert:


    hdparm -c3 ... bringt nichts bei mir.


    hdparm -X68 ... kann ich nicht einstellen, da gibt es im syslog die Meldung "kernel: ide0: Speed warnings UDMA 3/4/5 is not functional". Ich werde mal zwei 80polige IDE Kabel besorgen, um auf UDMA-4 gehen zu können. Vielleicht ist das die Lösung.


    Dann habe ich noch probiert, die Platten am IDE umzubauen:
    Platte 1 (hda) & Platte 2 (hdc): Fehler mit Meldung cAudioRepacker
    Platte 1 (hda) & Platte 2 (hdd): Fehler mit Meldung cAudioRepacker
    Platte 1 (hda) & Platte 2 (hdb): noch keine Fehler nach Tests, die bisher reproduzierbar waren. Ich benutze nach wie vor 40polige Kabel. Vielleicht ist bei meinem Borad irgendwas mit dem 2. IDE-Port nicht in Odnung.

    Ich werde die letzten beiden Tipps mal probieren.


    Wenn ich den UDMA-Modus ändere, brauch ich dann bei Einstellungen > UMDA-2 nicht auch ein 80-adriges IDE-Kabel?
    Mein Board kann zumindest Ultra-ATA/66, also UDMA-4 mit 66,6 MByte/s.


    Meine derzeitge Einstellung der beiden Platten ist "hdparm ... -c1". Kann dass vielleicht die Ursache sein? Der Modus 3 scheint eine Synchronisierung zu sein, die etwas mehr Ressourcen frisst, aber stabiler sein könnte. Deute ich die man page von hdparm richtig?

    Code
    -c     Query/enable  (E)IDE  32-bit I/O support.  A numeric parameter can be used to enable/disable 32-bit
           I/O support: Currently supported values include 0 to disable 32-bit I/O support, 1 to enable 32-bit
           data transfers, and 3 to enable 32-bit data transfers with a special sync sequence required by many
           chipsets.  The value 3 works with nearly all 32-bit IDE chipsets, but incurs  slightly  more  over-
           head.   Note  that  "32-bit" refers to data transfers across a PCI or VLB bus to the interface card
           only; all (E)IDE drives still have only a 16-bit connection over the ribbon cable from  the  inter-
           face card.