Squeeze - SD-vdr 1.7 mit FF Karte ruckelt während Aufnahmen und im Timeshift

  • Im Timeshift, und vermutlich auch während anderer Aufnahmen, ruckelt die Wiedergabe mit vdr 1.7 und debian Squeeze
    Der Lenny vdr 1.6 auf der gleichen Hardware macht das nicht.


    Die FF-Karte wird nur zur Wiedergabe benutzt, aufgenommen wird auf der DVB-T Budget.


    Nichts Signifikantes in den Logfiles, wonach könnte ich denn suchen?
    Irgendein bekanntes Problem?


    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

  • aragorn


    Hmm, wenn ich das so lese würde ich am ehesten auf die Festplatte und/oder Filesystem tippen.

    • Wie ist die HDD angebunden?
    • Welches Filesystem, wie montiert (mount options)?
    • Wie sieht der SWAP aus wenn es ruckelt? Wird etwas ausgelagert?
    • Generelle IRQ Verteilung?
    • Und als letztes, recht abwegig, ich weiß, aber Du hast wohl eine K8 CPU drin, die den Speichercontroller auch mit Q'n'C/powernow runtertaktet. Evtl. mal zu Verifizierung den Takt der CPU oben halten, nicht das es ein Problem beim Memory-Transfer gibt?

    Regards
    fnu

    HowTo: APT pinning

    • Wie ist die HDD angebunden?
      - SATA
    • Welches Filesystem, wie montiert (mount options)?
      - ext3 - um kompatibel zu Lenny zu bleiben (grub, video)
    Code
    # <file system> <mount point>   <type>  <options>   	<dump>  <pass>
    proc        	/proc       	proc	defaults    	0   	0
    # / was on /dev/sda3 during installation
    UUID=acbf45dc-9469-4a07-b588-382b752788a3 /           	ext3	errors=remount-ro 0   	1
    # swap was on /dev/sda2 during installation
    UUID=8eab4a07-e669-4517-a1d5-31a789c06af8 none        	swap	sw          	0   	0
    
    
    /dev/sda7   	/var/lib/video.00   ext3  defaults  	0   	2


    • Wie sieht der SWAP aus wenn es ruckelt? Wird etwas ausgelagert?
      - initial nicht, später (nach 30 Tagen uptime) sehr wenig
    • Generelle IRQ Verteilung?
      - ???, ist der Standard-Kernel von Squeeze. Dachte, dass das mit ACPI automatisch geht und keine Rolle spielt. no probs m. Lenny
    • Und als letztes, recht abwegig, ich weiß, aber Du hast wohl eine K8 CPU drin, die den Speichercontroller auch mit Q'n'C/powernow runtertaktet. Evtl. mal zu Verifizierung den Takt der CPU oben halten, nicht das es ein Problem beim Memory-Transfer gibt?
      - habe ich mit cpufreqd ausgeschlossen, auch wenn ich die CPU manuell auf 2.2GHz festsetze, ruckelt es

    Im Rahmen meiner Tests habe ich nach ewiger Zeit mal wieder einen Monitor angeschlossen, und die Desktop-Performance (Mozilla etc) ist auch unter aller Kanone.
    Ebenso das Einspielen von Paket Updates. Fühlt sich an wie nach einem Update von XP nach Vista auf alter Hardware.
    Das kann doch eigentlich gar nicht sein auf einem fast frisch installierten Debian System...


    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

  • Mal den VDR 1.6 unter Squeeze versucht? Wenn du nur FF-Karte und kein HD nutzt, macht das ja keinen Unterschied. Oder möchtest du .ts-Aufnahmen haben?


    Andy

  • Hi,


    bei mir tritt das gleiche Problem auf.


    Seit einigen Jahren hatte ich einen vdr 1.6 mit etch x86 als DomU und SLES11 x86_64 als Dom0 problemlos betrieben. Da es für etch ja schon längere Zeit der Support abgelaufen ist, habe ich Squeeze x86_64 mit e-tobi Repository installiert. Ich betreibe eine FF-Karte und Budget-Karte über PCI-Passthrough.


    Im Log kann ich sehen, dass sehr häufig buffer-usage Meldungen und manchmal als Ring Buffer Overflow Fehler auftreten. Am Plattenzugriff kann es eigenlich nicht liegen. Hier das hdparm Ergebnis für das Volume mit den Aufzeichnungen.


    Code
    root@vdr:/debian# hdparm -Tt /dev/xvdd
    
    
    /dev/xvdd:
     Timing cached reads:   3802 MB in  2.00 seconds = 1905.04 MB/sec
     Timing buffered disk reads: 190 MB in  3.02 seconds =  62.93 MB/sec


    Der XEN Host ist auch nicht sehr belastet. Wo kann ich noch nach der Ursache forschen?



    Joesy

  • Wie sehen diese Logs mit den Buffer Overflows aus, kannst du mal ein Beispiel posten?
    Und dann noch eine blöde Frage - wo muss ich das Logging anstellen, um das bei mit nachstellen zu können?


    zu den .ts Aufnahmen - ich habe jetzt natürlich schon welche, kann ich die mit vdr 1.6 auch abspielen?
    Gibt es ein vdr 1.6 repositorry bei e-tobi, ich habe in der Tabelle keinen Hinweis darauf gefunden (squeeze = experimental = 1.7)


    Die Wiedergabe der FF ruckelt im Übrigen auch bei beliebiger Aufnahme, es muss noch nicht mal timeshift sein, trotzdem keine auffälligen Logs.


    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

  • Könnte alles schlechte Plattenperformace sein. Check mal dmesg / syslog nach Meldungen, wie er die Platten erkennt und anspricht.


    Wie hoch ist denn die CPU-Last, wenn der VDR Aussetzer hat?


    Versuch mal ein hdparm -t /dev/sda, das gibt eine grobe Vorstellung von der Plattenperformance.


    Gruß,


    Udo

  • Unter /var/log/user.log sehe ich die buffer overflows, anscheinend treten diese bei mir häufig in Verbindung mit dem streamdev-plugin auf.


  • Der vdr braucht jetzt auch fast den gesamten Speicher, ist das neuerdings normal (siehe Screenshot)?


    Nachtrag zu hdparm:


    Code
    root@vdr:~# hdparm -t /dev/sda
    
    
    /dev/sda:
     Timing buffered disk reads: 270 MB in  3.01 seconds =  89.65 MB/sec


    An der Platte wird's wohl nicht liegen...


    vg, aragorn

    Bilder

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

    Einmal editiert, zuletzt von aragorn ()

  • Das mit dem Speicher würde ich nicht überbewerten, kann sein, dass das bloß gecachete Plattendaten sind. Der VDR scheint ja lange zu laufen, und den Rechner für sich allein zu haben, also kann er auch den Speicher nutzen, wenn ihn sonst keiner braucht. Übermäßig geswappt wird ja nicht.


    Plattenperformance ist ok, würde ich erst mal als Fehlerursache ausschließen.


    Gruß,


    Udo

  • Langsam nervt's - da passt doch irgendetwas nicht mehr in vdr 1.7 mit der FF Karte.
    Ich habe Bildstörungen, und danach ist der Ton asynchron.


    stelle mal zur Diskussion:
    - neue Firmware?
    - Buffer?
    - FF Karte als plugin, statt wie bisher im vdr enthalten
    - Kernel - Problem
    - .ts-Files - irgendetwas anders bei der Wiedergabe


    - zeitlich nicht in direktem Bezug zu den Fehlern, aber die einzigen EInträge im syslog:

    Code
    May 23 20:11:17 myvdr vdr: [2131] read incomplete section - len = 3698, r = 76
    May 23 20:11:40 myvdr vdr: [2131] read incomplete section - len = 3556, r = 392


    Worauf beziehen sich diese?


    Fragen:
    Kann ich den Treiber der FF-Karte dazu bringen, mehr debug-Meldungen auszugeben?
    Kann ich den vdr dazu bringen, mehr debug-Meldungen auszugeben?
    Beides n.M. ohne diese selbst zu bauen.


    Einen neuen Kernel zu bauen, der bootet, wie z.B. 2.6.38, ist mir auch noch nicht geglückt.
    Früher war das etwas einfacher, oder ich hatte einfach zu viel Zeit...
    Einen vdr 1.6 für squeeze mit allen Plugins scheint es nicht mehr zu geben, richtig?



    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

    Einmal editiert, zuletzt von aragorn ()

  • Ich kann dir nur sagen, dass die FF mit easyVDR 0.9 (VDR 1.7.18 ) ootb völlig stabil und problemlos läuft.


    Also deine Vermutungen mit FW, dvbsddevice, Kernel oder ts-files sind nicht das Problem


    Aber die 0.9 ist noch Alpha und die Plugins kaum getestet.


    Andy

  • Welche Firmware-Version und welcher Treiber laufen?


    Es sollte sich mittlerweile herumgesprochen haben, daß TS-Aufzeichnungen (VDR 1.7.x) gegenüber PES (1.6.x) gewisse Updates erfordern...


    CU
    Oliver

  • Ich beobachte das Problem hier bei 2 Systemen:

    • beide benutzen Debian Squeeze mit e-tobi Repositories (nicht die vdr-devel-Variante)
    • beide nutzen FF Satellitenkarten als Ausgabegerät
    • Als Empfangsgeräte werden unterschiedliche DVB-T USB und PCI Geräte verwendet.
    • Der DVB-T Empfang ist manchmal etwas schwach.
    • Firmware der ff-Karte: dvb-ttpci-01.fw-fb2624
    • Das eine ist ein 32- und das andere ein 64-Bit System.
    • vdr (1.7.18/1.7.18)
    • dvbsddevice (0.0.4)
    • linux 2.6.32-5


    Symptome:

    • zeitweise viele der "buffer usage" Meldungen mit gelegentliche "driver buffer overflow" Meldungen
    • selten "read incomplete section" Meldungen
    • Der Ton beginnt zu "schreddern" und bleibt hinter dem Bild zurück.
    • Es gibt dann irgendwann Bildstörungen.
    • Umschalten des Kanals oder Springen in der Wiedergabe synchronisiert die Signale.
    • Der Speicherverbrauch des langlaufenden vdr-Prozesses ist verdächtig groß.


    Ich bin derzeit ein wenig ratlos.

  • Version und Logs:




    Kernel ist STD 2.6.32-5 aus squeeze, falls die darin enthaltenen DVB Treiber schon zu alt sind, bitte um Hinweis.
    Die Firmware müsste m.W. die neuste sein, die verfügbar ist - fb2624


    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

  • Firmware fb2624 ist aktuell, der Treiber des 2.6.32er Kernels ist aktuell genug für TS-Wiedergabe.


    Bitte noch die Ausgabe von "hdparm -tT /dev/xxx" (xxx = Festplatte für Aufzeichnungen) und "cat /proc/interrupts" posten.


    Mir kommt es so vor, als wäre der Linux-Kernel weniger performant als früher. Kann es nicht näher beziffern, aber mein Produktivsystem "fühlt" sich neuerdings mit 2.6.35.10 langsamer an als früher mit "2.6.30.x". Wobei ich selbstverständlich immer den gleichen Treiber verwende. Muß ich mal bei Gelegenheit verifizieren.


    CU
    Oliver


  • Symptome:

    • Der Ton beginnt zu "schreddern" und bleibt hinter dem Bild zurück.
    • Es gibt dann irgendwann Bildstörungen.
    • Umschalten des Kanals oder Springen in der Wiedergabe synchronisiert die Signale.


    Ich bin derzeit ein wenig ratlos.


    Hi jungs,


    wollte mal meinen senf dazugeben. Ich hatte bis vor kurzem auch noch über meine tt2300c dvbc-ff karte geschaut und hatte genau die gleichen probleme wie zitiert. Diese hatte ich mit mld2.0 (vdr 1.6) noch nicht und kammen erst mit der umstellung auf mld 3.0:
    vdr >=1.7.16
    dvbsddevice als ausgabe
    neuste fw (aber natuerlich alle fw probiert weil ich die vermutet hatte)


    bei nur livetv ist es nicht aufgefallen, wenn man aber live +aufnahme hatte oder 2aufnahmen auf dem gleichen transponder sind beim wiedergeben immer wieder diese fehler in der aufnahme oder im livebild passiert. ich hatte das dann immer auf diese 12mbit beschränkung (falls es das ist was ich im hinterkopf habe) zurückgeführt.


    nun erstaunlich: ich nutze die karte weiterhin einzige änderung: dvbsddevice gegen vdr-sxfe + tvout meiner grafikarte ersetzt -> so habe ich keine fehler mehr im livebild oder in aufnahmen (mehrfach).


    vllt hilft meine erfahrung ja weiter


    greetz MarMic

    SZVDR HD: Intel e5300@1,2ghz - Gigabyte GA-EP41-UD3L - 2GB ddr2 800 - Gainward G210 512mb - Silverstone LC16MR - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing


    WZVDR HD: Intel g1610@1,6ghz - Intel DH61BE - Scythe Big Shuriken 2 - 4GB ddr3 1333 - Asus GT610 1024mb - Chieftec Hi-Fi HM-02 - Tevii s480 - Astra 19,2 - MLDHD-5.4 testing

  • ok, nochmal hdparm:


    Code
    vdr:~# hdparm -tT /dev/sda
    /dev/sda:
     Timing cached reads:   1890 MB in  2.00 seconds = 944.88 MB/sec
     Timing buffered disk reads: 272 MB in  3.01 seconds =  90.30 MB/sec



    hmm, die disk i/o würde ich mal als gut genug erachten.
    Aus den Interrupts werde ich nicht schlau, außer dass der saa7146 der FF sich keinen teilt.


    die PCI Latency These finde ich sehr interessant und in sich schlüssig, dem werde ich mal nachgehen und berichten.


    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse


  • bei nur livetv ist es nicht aufgefallen, wenn man aber live +aufnahme hatte oder 2aufnahmen auf dem gleichen transponder sind beim wiedergeben immer wieder diese fehler in der aufnahme oder im livebild passiert. ich hatte das dann immer auf diese 12mbit beschränkung (falls es das ist was ich im hinterkopf habe) zurückgeführt.


    Genau das Bandbreitenproblem hätte ich an der Stelle auch als Ursache genannt. War die Karte Full-TS-Gemoddet?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!