Beiträge von TeeRose

    Ich kann die cAudioRepacker wunderbar reproduzieren: Aufnahme auf hda starten und gleichzeitig "mkfs.ext3 /dev/hdc1" aufrufen. Dann rappelt es nur so von cAudioRepacker-Fehlern - mehrere die Sekunde und das kontinuierlich.


    Ich habe auch die Kernel-Einstellungen
    CONFIG_HZ_1000=y
    CONFIG_HZ=1000
    probiert. Allerdings kann ich die Fehler wie gerade beschrieben reproduzieren. Muss ich evtl. noch etwas auswählen (Scheduler)?

    CeBe:


    Ich habe mittlerweile den 2.6.14er Kernel und ebenfalls die Proble mit der hda. Diese Probleme begleiten mich aber schon seit einigen Kernel-Versionen (deutlich vor 2.6.13).


    Oder meintest du speziell die Kombination dma_intr-Fehler der hda und anschließendem cAudioRepacker-Fehler?

    Nachdem ich seit einigen Tagen die 2. Festplatte (hdc) als einiziges Gerät am Secondary IDE-Port abgehängt habe, treten die Fehler nur noch sporadisch auf.


    cTS2PES tritt vereinzelt beim Beenden einer Aufnahme auf und hat lediglich ein bis drei Fehler:

    Code
    Nov  1 20:16:00 vdr vdr[2140]: file writer thread ended (pid=2140, tid=-1288701008)
    ov  1 20:16:00 vdr vdr[2140]: cTS2PES got 0 TS errors, 1 TS continuity errors

    Ich denke, ich kann das erst einmal vernachlässigen. Was heißt die Meldung eingentlich?


    cAudioRepacker tritt ebenfalls nur noch vereinzelt auf. Interessanterweise in folgendem Zusammenhang:

    Code
    Oct 31 20:53:02 vdr /USR/SBIN/CRON[5997]: (mail) CMD (  if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi)
    Oct 31 20:53:02 vdr kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
    Oct 31 20:53:02 vdr kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
    Oct 31 20:53:02 vdr kernel: ide: failed opcode was: unknown
    Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 54 bytes to sync on next audio frame
    Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 386 bytes to sync on next audio frame
    Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame


    Kann mir jemand sagen, was meine Platte hda da für ein Problem hat? DMA ist aktiviert und smartctl hatte bei den letzten Sichtungen nichts ergeben. Da werde ich heute abend aber noch mal genau schauen.

    Der Patch funktioniert mit vdr 1.3.34.


    Wende ich aber

    Code
    > zcat ../vdr-1.3.34-enAIO-2.6.diff.gz | patch -p1
    > zcat ../noepg_0.3-1.3.29.diff.gz | patch -p1


    an, kommt beim 2. Patch:

    Und patche ich in umgekehrter Reihenfolge, kommt beim 2. Patch:

    Dr.Nop:
    Seit einigen Wochen kämpfe ebenfalls mit den Symptomen dieses Threads
    und
    seit einigen Wochen habe ich eine 2. Platte (hdc) im System. Ich hatte die Platte geschenkt bekommen (war in einem RAID), da sie evtl. defekt ist. Ich habe sie lowlevel formatiert und mit smartctl untersucht. Vorerst scheint alles zu laufen mit der Platte. smartd meldet auch nichts aufregendes.


    Meine Idee war auch schon, die Platte wieder zu entfernen. Leider kann ich nicht mehr überprüfen, ob die Fehler zeitgleich zur Inbetriebnamhe der 2. Platte anfingen.


    Gestern habe ich jedoch von
    Kernel 2.6.13 / vdr 1.3.34 (2 Patches) / Firmware 261f
    auf
    Kernel 2.6.12 / vdr 1.3.27 vanilla / Firmware 261f
    gedowngraded. Ich hatte ebenfalls die Treiber des 2.6.13er Kernel in Verdacht. Eine erste Auswertung zeigt immer noch:

    Code
    Oct 27 22:01:20 vdr vdr[6915]: transfer thread ended (pid=6915, tid=-1367340112)
    Oct 27 22:01:20 vdr vdr[6915]: cTS2PES got 0 TS errors, 104 TS continuity errors
    Oct 27 22:01:20 vdr vdr[6915]: cTS2PES got 0 TS errors, 31 TS continuity errors
    Oct 27 22:01:20 vdr vdr[6915]: cTS2PES got 0 TS errors, 19 TS continuity errors
    Oct 27 22:01:20 vdr vdr[6915]: buffer stats: 145136 (6%) used


    Der Ausbau der 2. Platte ist nach deinem Hinweis definitiv der nächste Versuch.


    Willst du die Platte zukünftig draussen lassen oder hast du schon eine Idee, wie du sie und den vdr ohne Fehler zum Laufen bekommst?


    Viele Grüße,
    TeeRose

    Habe ein ähnliches Problem wie grandmasterb10:


    Ich lade die EPG-Daten von "das vierte" über infosat und dann über tvmovie2vdr 0.5.6. In den Datenfiles von Infosat sind Einträge von "das vierte" vorhanden, auch meldet tvmovie2vdr, das es 116 Einträge gefunden hat, aber im EPG von VDR ist nichts vorhanden.


    Ciao,
    TeeRose

    Hi winni,


    ich will das jetzt nicht bestimmen, aber was aktuell im EPG vom vdr drin ist, ist doch das für vdr gültige, egal ob besser, länger oder schlecht und kürzer.


    Wenn ich mittels grüner Taste die Sendungen aufrufe und zu der entsprechende gehe und mir die Info anzeigen lasse, kommt die aktuell aus der epg.conf. Warum also nicht aus bei epgsearch immer diesen Eintrag drüber bügeln? Wäre doch konsequent, zumal es in epgseach auch keine Editmöglichkeit für diesen Eintrag in der timers.conf gibt. Bei vdradmin sieht das anders aus. Da kann man die Daten ja beim Anlegen der Timer selbst pflegen.


    Bleibt trozdem die Frage, wie du es machen könntest. Es gibt ja bestimmt VDR-User, die vdradmin und epgsearch benutzen. Ich selbst habe beides laufen, nutze aber bei vdradmin nichts von den Timer-Funktionalitäten.


    Ciao,
    TeeRose

    Das neue Feature, welches die EPG-Beschreibung in den Timer schreibt, finde ich sehr gut.


    Allerdings ist mit dabei etwas aufgefallen. Bei bereits bestehenden Timern wird die Info bei dem halbstündigen epgsearch-Lauf nicht hinzugefügt oder aktualisiert.


    Ich gehe davon aus, dass das Plugin generell schon die Timer aktualisiert, es kann sich ja eine Uhrzeit verschieben.


    Jetzt wäre es doch schön, wenn das Plugin die EPG-Beschreibung auch in allen Timern aktualisiert.


    Warum?
    Ich benutzte epginfosat und tvmovie2vdr, um den EPG anzureichern. Dazu rufe ich täglich erst infosatepg auf und importiere via tvmovie2vdr, wobei ich den EPG lösche (ist ne Konfig-Einstellung in tvm2vdr). Anschließend schaltet ein Skript noch mal alle Transponder bis zum Kanal 200 durch und liest somit weitere EPG-Daten ein, die im Infosat nicht enthalten sind. Dadurch kann es passieren, dass ich durch den Sender einen EPG-Eintrag für z.B. in 7 Tagen erhalte, der noch nicht in infosat enthalten ist. epgseach programmiert eine Timer mit der EPG-Beschreibung vom Sender, die eher mager ist. Wenn an einem der folgenden Tage die Sendung auch in Infosat verfügbar ist, wird ein "besserer" Eintrag in den EPG des vdr geschrieben. Schön wäre, wenn epgsearch den EPG-Eintrag im Timer dann aktualisieren würde.


    (Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.)


    Viele Grüße
    TeeRose

    Hi HFlor,


    die Daten stammen dann aus der timer.conf, oder? vdradmin speichert z.B. im letzten Feld in der Datei die Daten aus dem EPG. Bei epgsearch wird das nicht gemacht.


    Ich habe bisher immer beim Drücken auf OK den Timer zum Ändern geöffnet. Ich probiere das aber mal. Die Daten des EPG werden nicht aufgerufen.

    Hallo IcyA1,


    ja, ich habe zwei Sat-Kabel am Multiswitch für die zwei Karten im VDR.


    Es scheint wohl so zu sein, dass der vdr sich einige Male restartet hat und dabei nicht alle Kernel-Module entladen hat.
    Bei mir werden die DVB-Treiber beim Restart entladen und neu geladen. Beim Entladen hatte ich das Modul budget_ci nicht entfernt, sodass sich einige andere Module ebenfalls nicht entladen haben. Beim Neustart wurde dann vermutlich die Budget nicht neu initialisiert.
    Nach der Änderung habe ich mein Problem nicht mehr beobachet.

    Hallo zusammen,


    ich habe diverse Autotimer und schaue deahalb öfters die Timerliste an.
    Dort finde ich es sehr unschön, dass in der Lite nicht die Möglichkeit besteht, die EPG-Daten aufzurufen um mehr über die Sendung zu erfahren und sie evtl. zu deaktivieren.


    Habe ich womöglich ein Feature von VDR übersehen?
    Gibt es einen Patch dafür?
    Sollte so eine Funktion nicht standardmäßig in den vdr?


    Viele Grüße
    TeeRose

    Hallo zusammen,


    nachdem ich seit kurzem zwei TV-Karten (FF und Budget) habe, habe ich eine Verständnisfrage zum VDR.


    Ich habe zwei sich überschneidende Aufnahmen auf zwei Trnaspondern, z.B.:
    1. ARD 20:00 - 20:16 Uhr
    2. ZDF 20:12 - 21:55 Uhr


    Ablauf im VDR:
    20:00 Uhr: Aufnahme 1 startet auf der Budget, die der VDR ja als erstes für eine Aufnahme bevorzugt. Der VDR lässt mich alle Programme umschalten, da die FF mit dem Ausgang zum TV frei ist.


    20:12 Uhr: Aufnahme 2 startet auf der FF, da ja die Budget belegt ist. Der VDR lässt sich nur noch innerhalb des ZDF-Transponders umschalten.


    20:16 Uhr: Aufnahme 1 endet auf der Budget. Aufnahme 2 läuft noch auf der FF.


    Wie geht es jetzt nach 20:16 Uhr weiter? Merkt der VDR, dass die Budget frei ist und verlagert das Aufnehmen der 2. Aufnahme von der FF auf die Budget? Dann müsste ich ja wieder alle Progamme auf der FF sehen können.


    Ich frage deshalb, da es manchmal so war. Ich habe auch schon erlebt, das lediglich eine Aufnamhe lief und ich nicht mehr den Transponder wechseln konnte.


    Meine Vermutung dabei ist jedoch, dass der VDR einen Restart hingelegt hat und die Bufget nicht neu initialisiert wurde. Evtl nicht alle Treiber korrekt entfernt. Da muss ich wohl mal ein Logging einrichten.


    Viele Grüße
    TeeRose

    Wenn ich den Fehler reproduzieren will und statt im Lilo zu warten dann ins Bios gehe, erfolgt kein Suspend.


    Tja, dann vielleicht ein Bios downgrade?!?
    Oder als Workaround: bei jedem Boot setzte ich gleich als erstes die Wakeup-Zeit mit nvram-wakeup auf disable. Naja, ob das dann wirksam ist oder ich evtl erst einen Reboot brauche muss ich gleich mal testen...


    ...So, Test gemacht. Ich habe im Init-Skript des vdr (bei mir rc2.d/S01vdr) ein

    Code
    nvram-wakeup -d -C /etc/nvram-wakeup.conf

    eingefügt. Damit konnte ich den Suspend nicht reproduzieren :).


    Aber so richtig gefällt mir die Lösung noch nicht - falls sie dauerhaft funktionieren sollte. ich hatte nämlich auch schon mal den Fall, dass ich einige Sekunden vor dem eigentlichen, programmierten Wakeup den Rechner manuell gestartet habe und er dann während des Boot-Prozesses in den Suspend gegangen ist. Dieses Risiko wäre mit der Lösung oben weiterhin vorhanden.