driver buffer overflow

    Moin!


    Seit dem Upgrade von Lenny auf Squeeze habe ich gelegentlich mit solchen Problemen zu tun (vorzugsweise wenn es auf der Festplatte eng wird):


    Mar 22 18:38:00 hund vdr: [2290] buffer usage: 90% (tid=2289)
    Mar 22 18:38:21 hund vdr: [2290] buffer usage: 100% (tid=2289)
    Mar 22 18:39:48 hund vdr: [2290] ERROR: driver buffer overflow on device 1


    Resultat: Kurze Aussetzer in der Aufnahme. Früher kam das nie vor.

    Heute das Fiasko: Die Aufnahme wurde sogar abgebrochen :(


    Leider habe ich nichtmal einen Plan, wo ich nach der Ursache suchen soll.


    May 10 21:35:17 hund vdr: [3961] buffer usage: 60% (tid=3959)
    May 10 21:35:20 hund vdr: [3961] buffer usage: 70% (tid=3959)
    May 10 21:35:20 hund vdr: [3961] buffer usage: 60% (tid=3959)
    May 10 21:35:20 hund vdr: [3961] buffer usage: 70% (tid=3959)
    May 10 21:35:21 hund vdr: [3961] buffer usage: 80% (tid=3959)
    May 10 21:35:22 hund vdr: [3961] buffer usage: 90% (tid=3959)
    May 10 21:35:22 hund vdr: [3961] buffer usage: 100% (tid=3959)
    May 10 21:35:50 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:35:52 hund vdr: [3959] ERROR: skipped 11 bytes to sync on TS packet on device 1
    May 10 21:36:39 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:40 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:40 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:36:41 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:42 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:42 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:36:43 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:44 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:44 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:36:45 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:46 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:47 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:36:48 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:49 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:49 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:36:50 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:51 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:51 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 21:36:52 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 21:36:54 hund last message repeated 2 times
    (usw., usf.)
    May 10 23:10:00 hund vdr: [3967] recording thread ended (pid=2149, tid=3967)
    ...
    May 10 23:11:00 hund vdr: [3961] ERROR: driver buffer overflow on device 1
    May 10 23:11:00 hund vdr: [2149] PANIC: watchdog timer expired - exiting!
    May 10 23:11:00 hund vdr: [2149] radio: delete cRadioAudio
    May 10 23:11:01 hund vdr: [2261] KBD remote control thread ended (pid=2149, tid=2261)
    May 10 23:11:01 hund vdr: [3959] ERROR: TS packet not accepted in Transfer Mode
    May 10 23:11:02 hund vdr: [2260] radiocheck thread ended (pid=2149, tid=2260)
    May 10 23:11:02 hund vdr: [2259] radioimage thread ended (pid=2149, tid=2259)
    May 10 23:11:02 hund runvdr: restarting VDR

    Moin!


    Die Karte ist eine Hauppauge Nexus-S, also SD-FF.
    Der betroffene Sender war gestern ARD Eins Festival. Probleme machen z.B. auch (teilweise?) die Dritten Programme.
    Nachträglich habe ich im syslog noch entdeckt, daß es auch zum "driver buffer overflow" kommt, wenn gar keine Aufnahme läuft. Was bedeutet das denn? Ich dachte, der overflow würde bedeuten, daß der VDR seine Daten nicht schnell genug wegschreiben kann.

    Wenn eine Aufnahme beendet ist, schaltet VDR nicht den transfer-Mode wieder ab. Das geschieht erst, wenn das Programm gewechselt wird. Gerade wegen dieser Geschichten gibt es ja den full-ts-mod.

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Hallo


    wer erklärt mir mal warum der Buffer überläuft obwohl die CPU nix zu tun hat?


    Und vorallem:
    Was ich dagegen tun kann :)


    neustart VDR und ein Warmstart des Rechners halfen nichts.


    Es ist eine(!) FF Nexus 2.1 DVB-S, vorher hatte ich vdr 1.6 und zwei FF laufen und so etwas nur beobachten können, wenn ich 3 oder 4 Timer hatte ("soetwas" meint: Klötzchen, pochen und lückenhafter im Ton, z.Zt. asynchron).


    Femon 1.7.18 funktioniert auch nicht, da der Speicher zu klein ist (siehe anderes post)


    Hat es evtl. Sinn die FF Karte wegzuwerfen (es funktioniert mit dem 1.7.18 eh nur die eine FF) und
    eine Nividia mit MPEG und 2 Budget DVBS Karten zu nehmen?




    edit:
    Das Teil ist aumbedienbar:


    Bei mir kam der Ärger nach Umstieg auf Linux 3 und Wechsel von TT FF S2300 zu C2300 und das hat geholfen:


    Code
    # echo "options saa7146_vv max_memory=255" >> /etc/modprobe.d/dvb.conf
# echo "options budget_core bufsize=1024" >> /etc/modprobe.d/dvb.conf


    Für diese Hardware:



    Mit dieser PCI- Konfiguration (ohne gibts grüne Blitze im Bild):


    Code
    install budget_av /usr/bin/setpci -f -s 00:06.0 latency_timer=40 ; /usr/bin/setpci -f -s 00:0d.0 latency_timer=20 ; \
/sbin/modprobe dvb_ttpci ; /sbin/modprobe --ignore-install budget_av
install saa7134 /sbin/modprobe budget_av ; /sbin/modprobe --ignore-install saa7134


    Die Standardgrösse der Puffer (modinfo 32MB/192KB) sind zu klein für mehrere saa7146- Karten und die FF noch dazu als Dekoder für die Budget-Karten,
    schon bei 2 Aufnahmen auf dem gleichen Transponder auf der FF reagiert das OSD über tvtime träge und bei ner
    3. auf einer der budget- Karten gibts dann die buffer overflows, Gestotter bishin zu timeout waiting in LoadBitmap, av7110_send_fw_cmd error :(


    Tja, wohl doch nicht, ARD/ZDF senden einfach mit zu hoher Videobitrate:



    Und wenn noch OSD-Bedienung dazukommt dann steht vdr am mutex von dvb_usercopy() bis zu 10sek an laut latencytop.
    Was soll denn bitte die Sinnlosaktion, Talkshows und 50er- Jahre content mit 6Mbit/s MPEG2 zu senden? :§$%
    Das macht das Bild kaum sichtbar besser und verschwendet nur Speicherplatz für Aufnahmen und DVD-Rohlinge.


    Da es dafür wohl diesen Full-TS- Mod gibt und sowieso nicht viele die TT / Nexus CA mit 256qam überhaupt zum sauberen Empfang gebracht haben,
    kann ich mir den Aufwand, den dvb-ttpci oder vdr dafür aufzubohren wohl sparen, und soll ja angeblich eh nix nützen wegen diesem viel zu kleinen Puffer- RAM.


    Jetzt ist mir auch klar warum kabelbw die ARD/ZDF alle auf 256qam verschoben hat, und ich darf jetzt alle ARD/ZDF- Sender auf die Budget dvb-c mit
    "CA ID" 2 in der channels.conf setzen.

    Quote from woppr

    Die Standardgrösse der Puffer (modinfo 32MB/192KB) sind zu klein für mehrere saa7146- Karten


    Quote from woppr

    Da es dafür wohl diesen Full-TS- Mod gibt

    Nein. Das Problem hat sich mit dem neuen (alten) Mainboard mit Intel PCI- bridges
    DVB-C PCI Karte via PCIe->PCI Riser läuft auf AT3ION-T
    hier jetzt auch erledigt, 2 rec streams von ARD/ZDF + OSD- Bedienung über die TT C2300, Latencytop mit Kernel 3.6.5:


    Code
    Cause                                            	Maximum 	Percentage
[dvb_usercopy]                                	247,5 msec      	6,5 %
Opening file                                  	242,0 msec      	8,1 %
[av7110_osd_cmd]                               	98,5 msec      	4,6 %


    PCI- latency s und buffer- Parameter wieder auf defaults.

    Das war wohl etwas vorschnell, spät abends übermüdet, und zu früh gefreut, der hat gestern ARD/ZDF Sender von der Medion 7134 aufgenommen, nicht von der TT C2300:



    Leider doch wieder reproduzierbar, gerade auf die Sportschau mit Sofortaufnahme geschalten und:



    Mit DD- Ton ist es besonders schlimm, geht erst wieder flüssig wenn VDR aus dem transfermode schaltet, Schade :(

    Eine SD-FF ohne Full-TS-Mod ist imho nur als Nur-Ausgabe-Device brauchbar - außer bei Sendern mit geringer Bitrate.
    Sollte sich doch mittlerweile herumgesprochen haben...


    CU
    Oliver

    Die Bandbreite hab ich bei der Sportschau vorhin nicht mit dvbsnoop mitgemessen.
    Laut debug logs siehts aus als käme er nicht mehr beim buffer leeren nach weil der Mutex von dvb_usercopy() von recx, play, OSD, etc, überbelegt ist und dann gibts natürlich den buffer overrun.


    Ich ersetz nächste Woche die knc1 c mal Versuchsweise durch ne 2. TT C2300 oder/und die Medion 7134 durch die TT S2300, mit der S2300 zusätzlich nur als Ausgabedevice (CAID, --outputonly wirkt global für alle FF- Karten) von oben im alten System wars besser oder die Lösung mit BCM crystalhd am pci-e port, wird wohl das beste sein und bringt mir dann auch etwas HDTV- Support.


    Aber ich glaub wir haben kein Support für crystalhd im VDR? Höchstens mit sxfe über libxine...? Na mal sehen.

    Die Bandbreite ist bei Sportübertragungen oft besonders hoch. DD-Ton benötigt mehr Bandbreite als normaler Ton.


    Bei einem Kabeluser fungiert eine DVB-S FF automatisch als reines Ausgabe-Device, daher hattest Du die Probleme damit nicht. Bei einer DVB-C FF mußt Du dafür sorgen, daß VDR den Tuner der Karte nicht verwendet.


    CU
    Oliver

    Quote from UFO

    Bei einer DVB-C FF mußt Du dafür sorgen, daß VDR den Tuner der Karte nicht verwendet.


    Wäre natürlich das Sicherste, aber mit den Privaten gings bei KabelBW mit dem alten System, erst bei Aufnahmen von ARD/ZDF- Sendern wurde es kritisch bis zur Blockade.


    Für dvb-s hab ich natürlich immer nur die Medion 7134 benutzt und die TT S2300 zuletzt mit --outputonly und für dvb-c jahrelang die KNC1, mit der Siemens D1121(?) als output,
    deswegen hatte ich diese buffer- Probleme nicht, wie Du gesagt hast.

    Quote from C-3PO


    Keine Ahnung. - Aber wozu die Experimente? Besorge Dir für ~35€ eine vernünftige Grafikkarte (z.B. eine GT520) und gut is. ^^


    Das wird doch sicher nix mit dem alten pci-e 1.0/1.0a 1x Slot auf dem alten iBase board (siehe Link zum riser-thread) und schon gar nicht über Flachbandriser 1x -> 16x?
    Dutzende Ärgerberichte.
    Da müsst ich erst USB3- Kabel besorgen.


    Aber danke für die Option.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login