Bildruckeln: buffer usage läuft voll

Dr. Seltsam · 27. November 2005

tja, da ständig überall Baustelle ist, ist die Rückverfolgung nicht so einfach...

Ich habe 2 Theorien:

-es ist mit 2.6.14 besser geworden ggü. 2.6.12

-es lag/liegt an vdr, denn meine zwischenzeitlichen Experimente mit dem alten 1.0.1-Treiber und Kernel 2.4.32 brachten nach meiner Erinnerung damals keine Besserung

Da ich aber auch beim alten DVB-Treiber die Firmware (Dpram/Root) aktualisiert hatte, kann es natürlich auch die FW gewesen sein.

Oder eine Kombination aus allem

Flasher_84 · 27. November 2005

Hallo,

ich kämpfe mit den gleichen Problemen!

Zum Einsatz kommt bei mir der Kernel 2.6.14 + 2621 Firmware.
Bei AC3 on läuft der Buffer wesentlich schneller voll, als wenn ich AC3 deaktivere.
Aber nach ein paar Minuten ist auch bei AC3 Off ruckeln angesagt....

Dr. Seltsam · 27. November 2005

Hast Du es mal mit der Kernel boot option "elevator=anticipatory" versucht? (Tipp von rollo)

Flasher_84 · 27. November 2005

Gerade getestet!

Funktioniert leider nicht so recht. Jedesmal wenn das Ruckeln anfängt, beendet der VDR nun die Wiedergabe und schaltet auf das normale Fernsehen um

Gruß,

Flasher

Dr. Seltsam · 27. November 2005

hab`s trotz des Eintrages der Kerneloption heute Abend bei Pro7 gehabt. Nach einer Stunde Aufzeichnung müllt das Log voll mit buffer usage 60-70% und (gottseidank nur 1 x ) 90% und "Zwangsleerung"

ollo · 28. November 2005

... dito, das Problem besteht immernoch

Gruß, ollo

Flasher_84 · 28. November 2005

Hallo,

habe gerade die Firmware 2622 getestet.
Das Problem scheint dort nicht mehr so stark aufzutreten. Zumindest dauert es jetzt mit aktiviertem AC3 viel länger bis das Ruckeln beginnt.

Mit welchem Befehl fragt ihr denn den Bufferstatus ab?
Oder schraubt ihr nur den Debuglevel des VDR's hoch und schaut im error.log nach?

Gruß,

Flasher

Dr. Seltsam · 28. November 2005

das schreibt sich von selbst ins log, ohne dass es irgendeines Tricks bedarf

drops · 1. Dezember 2005

habe das gleiche problem. System siehe Signatur. Hatt hier schon jmd. ne Lösung gefunden.
gruß
drops

ollo · 3. Dezember 2005

Hallo,

nochmal zum Thema. Es muß meiner Meinung nach am Transfermode des VDR liegen, wobei die Probleme nur sichtbar werden, wenn mit hoher Bitrate empfangen wird und parallel aufgezeichnet wird (eben im Transfermode). Da ich DVB-C nutze, liegen die meisten Sender mit mehr als 4Mbit/s Datenrate an.

Ich verwende aktuell FW2622 mit den Modifikationen in transfer.c und dvbosd.c. Damit kommt es häufig zu Rucklern und Tonaussetzern (ca. alle 5 min) und gelegentlich zu Bufferoverflows (ca. alle 30min).

Wenn ich die Bufferreserve wieder einschalte, dann habe ich Probleme mit Ton & Bild sofort.

Ich habe jetzt in transfer.c die "TRANSFERBUFSIZE" von (2) auf (4) MB erhöht und beobachte...

Gruß, Ollo

Dr. Seltsam · 3. Dezember 2005

ich hatte das Problem auch in der vdr mailing list gepostet, aber komischerweise fast keine Resonanz erhalten. Der einzige Tip war

Zitat

you could try commenting out the fdatasync() calls in tools.c:
cUnbufferedFile::Write() and Close() and see if anything changes. They should
affect directly only the thread calling Write()/Close(), but fdatasync could
block for several seconds...

ich muss zu meiner Schande gestehen, dass ich das noch nicht weiter verfolgt habe, da ich nicht sicher bin, was genau ich am Quellcode ändern muss...

Die Erhöhung auf 4 MB habe ich mal in einem HDTV-Patch gesehen. Da komme ja auch größere Datenmengen- vielleicht ist das die Lösung.

Die Kunst ist wohl, den buffer genauso schnell zu leeren (Schreibgeschwindigkeit auf Platte ?) wie er vollläuft.

LinTV-Fan · 3. Dezember 2005

Bei mir trat es auf nachdem ich Kernel 2.6.13.4 montiert habe ...

Beim LiveTV Ruckler bei hohen Bitraten
(gleiches Problem wie bei mplayer mit hohen Bitraten und lavc>5000)

Beim Ansehen einer solchen Aufnahme tritt es auch auf.

Wenn ich die Aufnahme aber auf einem PC sehe existieren die Ruckler nicht.

Es muss also beim Transfer in die MPEG Hardware der DVB Karte passieren ...

PS: Wenn es mit 4MB Karten nicht passiert .. wo kann man eine modifizierte kaufen ?? (Aber eine mit einem guten Tuner und J2)

ollo · 3. Dezember 2005

... also die 4MB allein machen es auch nicht

Aber ich habe spaßenshalber mal den "laptop_mode" aktiviert (echo 1 > /proc/sys/vm/laptop_mode), der u.a. dafür sorgt, daß seltener auf die Platte geschrieben wird, dafür aber größere bursts.

Das scheint Linderung zu bringen, keep testing....

Die Platte ist schnell genug & DMA ist aktiv:

# hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 912 MB in 2.00 seconds = 454.93 MB/sec
Timing buffered disk reads: 138 MB in 3.02 seconds = 45.70 MB/sec

Gruß, Ollo

ollo · 4. Dezember 2005

... ok, laptop_mode aktiviert und 4MB transferbuffer scheint erstmal eine Lösung zu sein, jedenfalls konnte ich gestern einen Film aufnehmen und parallel dazu einen anderen auf dem gleichen Transponder schauen ohne daß es dabei zu Bild- oder Tonstörungen kam

Gruß, Ollo

Dr. Seltsam · 4. Dezember 2005

ich habe zunächst mit 2MB und der von Artur Skawina in der ML vorgeschlagenen Änderung (http://www.linuxtv.org/piperma…2005-November/006393.html) getestet.

In tools.c sieht es jetzt so aus

Code

int cUnbufferedFile::Close(void)
{
  if (fd >= 0) {
     if (ahead > end)
        end = ahead;
     if (begin >= 0 && end > begin) {
        //dsyslog("close buffer: %d (flush: %d bytes, %ld-%ld)", fd, written, begin, end);
        if (written)
        posix_fadvise(fd, begin, end - begin, POSIX_FADV_DONTNEED);
        }
     begin = end = ahead = -1;
     written = 0;
     }
  int OldFd = fd;
  fd = -1;
  return close(OldFd);
}

Alles anzeigen

sowie

Code

ssize_t cUnbufferedFile::Write(const void *Data, size_t Size)
{
  if (fd >=0) {
     off_t pos = lseek(fd, 0, SEEK_CUR);
     ssize_t bytesWritten = safe_write(fd, Data, Size);
     if (bytesWritten >= 0) {
        written += bytesWritten;
        if (begin >= 0) {
           if (pos < begin)
              begin = pos;
           }
        else
           begin = pos;
        if (pos + bytesWritten > end)
           end = pos + bytesWritten;
        if (written > WRITE_BUFFER) {
           //dsyslog("flush buffer: %d (%d bytes, %ld-%ld)", fd, written, begin, end);
           if (begin >= 0 && end > begin)
              posix_fadvise(fd, begin, end - begin, POSIX_FADV_DONTNEED);
           begin = end = -1;
           written = 0;
           }
        }
     return bytesWritten;
     }
  return -1;
}

Alles anzeigen

Habe dann gleichzeitig drei Aufnahmen von ZDF, 3sat und Pro7 (alle in AC3) gestartet und dabei direkt ZDF live laufen lassen. Resultat:
Nach ca. 4 Minuten lief der buffer wieder über.

Danach habe ich zusätzlich den buffer auf 4MB erhöht. Bei gleichen Testbedingungen liefer buffer dann nach 15 Minuten über.

Nächster Test: vdr mit 2 MB buffer, die Änderungen in tools.c sind immer noch drin, laptop mode ist an:
Buffer läuft nach 20 Minuten voll.

Das gleiche nochmal mit 4MB, nun läuft der buffer wieder nach 4 Minuten voll.

nee, das scheint alles nix zu nützen...

Dr. Seltsam · 4. Dezember 2005

nächstes Experiment: vdr-1.3.37, normaler 2MB buffer, ohne die o.g. Änderungen in tools.c
aber: Diesen patch http://www.linuxtv.org/piperma…2005-November/006337.html eingespielt und die Schreibstrategie auf 0 gesetzt.
Immerhin: alle 3 Aufnahmen laufen seit einer halben Stunde, ohne dass bisher der buffer überlief.

Da ich nicht neu gebootet habe, ist wohl der laptop-modus auch noch an...

ollo · 5. Dezember 2005

... und, wie ging's aus?

Übrigens kann man den laptop_mode auch wieder einfach ausschalten:

echo 0 > /proc/sys/vm/laptop_mode

Von dem UnbufferedFile patch habe ich auch schon gelesen, scheint was vernünftiges zu sein ...

Gruß, Ollo

xian · 5. Dezember 2005

Hi,
mein VDR crasht auch immer wieder wenn von ARD ne Aufnahme anlaufen soll nach 1-2 Minuten. Hab das Problem nur bei ARD! Wenn der VDR vorher läuft und dann auf ARD umschaltet um dort die Aufnahme zustarten crasht er zu 99% sicher, wenn er automatisch hoch fährt um die Aufnahme zustarten klappt es zu 50% stürzt dann aber beim Beenden der Aufnahme zu 99% ab...

Chris

Dr. Seltsam · 5. Dezember 2005

Zitat

Original von ollo
... und, wie ging's aus?

tja, beim 2. Experiment lief der Buffer dann wieder nach 20min. über. Aber der Patch bringt offenbar schon etwas. 3 gleichzeitige Aufnahmen + Live TV sind ja auch schon extrem.

rdnzl · 11. Dezember 2005

Hallo,

Ich teste auch gerade den o.g. Patch. Dazu wäre es wissenswert, was der Parameter Write Strategy (0-2) bewirkt.... ???

Ich kann erkennen, daß bestimmte Codesequenzen über
" && Setup.WriteStrategy!=1 "
ausgeklammert werden, also nur bei 0/2 ausgeführt werden.

Gibt es Infos dazu ???

MfG

Bildruckeln: buffer usage läuft voll

Jetzt mitmachen!

Teilen