Kaputte VDR Aufzeichnungen bei "hoher" PCI Bus Last

Habe gerade einen Sack Platten mit an den VDR Server gehaengt. Wenn da jetzt auf den Platten Last von sagen wir mal > 350 MByte/sec ist (auf einer 8-lane PCIe SATA Karte, habe da bisher bis 900MByte/sec gesehen), dann sehe ich bei mir Aussetzer in den VDR Aufnahmen - DD Cine S2 V6.5 mit vier Tunern - aber selbst, wenn nur einer aufnimmt. Aufzeichnung auf SSD, die an einem anderen PCI controller haengt (onboard). CPU langweilt sich ( > 50% CPU frei), Nice hilt nicht.

An was fuer Stellschrauben koennte man da noch rumschrauben ? Gibts da irgendwo prioritaeten fuer PCI(e) devices ? Kann man bei den Cine S2 groessere Buffer anlegen ? Hat der VDR selbst noch relevante Parameter ?

Danke!

Danke danke.

Im moment kriege ich das Problem ja schon mal gerade wieder nich reproduziert *sigh*.

Gibt es denn irgendwas an diagnose im VDR was einem helfen wuerde festzustellen, das Aufzeichnungen "paketverluste" haben ? Hab mich noch nicht so mit dem TS Format beschaeftigt, kann mich aber auch nicht erinnern, das ich da irgendwas im VDR gesehen haette. Selbst irgendein programm, was das post-mortem z.b. von der aufzeichnung macht. Wuesste vom manualeintrag z.b. nicht, ob dvbsnoop sowas kann (wohl eher nicht).

Ich befuerchte ja mal, das die daten zwischen der DVB Karte und dem VDR Prozess verloren gehen. Schliesslich hat die DVB Karte ja auch nur einen begrenzten ringpuffer, und so wie ich das verstehe muss der VDR da ja wohl kontinuierlich daten von lesen.

Frueher hatte ich tatsaeclich problem das VDR nicht all seine aufzeichnungen speichern konnte, vor allem wenn da auf mehreren Kanaelen gleichzeitig aufgenommen wurde. Aber mit SSD ist das halt kein Thema mehr....

Zitat von jsffm

Schau mal danach:

Code

vdr3-2 vdr-2.5.1 # vdr-checkts
Usage: vdr-checkts [OPTIONS] RECORDING_DIR

  -m errors, --max-errors=ERROR Stop scanning if error count reaches ERROR
  -h,        --help             print this help and exit

Super. Vielen Dank. Mal direkt in meine Verarbeitungskette einbauen.

Das verrueckte ist, das ich vor 2 Stunden mal einen Plattentest gemacht habe, und dann gestoppt, aber trotzdem hat der VDR immer noch Probleme mit gestoertem Bild, selbst 2 Stunden spaeter. VDR neu starten, Problem ist weg. Sowas nervt halt, weil es halt so aussieht als ob sich da was im VDR verklemmt hat.

Aber halt auch keine ring buffer overflows im syslog. buffer stats bei 3..5%. Keine syslogs die ein problem erkennen lassen wuerden.

Jo, aber genau das sehe ich nicht. Und ich weiss ja wie ich das immer frueher gesehen hab, wenn was im system nicht stimmte (VDR seit 2008 ;-).

Aka: das ist jetzt wieder ein neues Problem fuer mich.

Im anderen Forum wurde mir noch 'ionice' empfohlen... Mal gucken.

"Es bleibt schmierig (TM)" *sigh*

Den neuen plattencontroller und neue Platten entfernt.. Problem immer noch da.

Probiert, mit 'ionice' vdr auf maximale real-time prio zu bringen. ionice kann keine parameter mit leerzeichen, also kann man damit nicht vdr starten. Also einen eigenen vdr starter geschrieben, der den ionice system call macht. Hat aber nix gebracht.

Also fern gesehen und geschaut wann genau das Bild anfing Bildfehler zu haben, und es korrelierte mit kernel meldungen:

mceusb 2-1.6.1.1:1.0: Error: urb status = -32

Super. mceusb IR empfaenger im startup deaktiviert. Jetzt habe ich hoffentlich sehr wenig continuity fehler... schaun mer mal.

Aber mal so als frage:

In der quelle von vdr-checkts ist ein netter patch drin um direkt beim recording die continuity errors zu tracken. Wurde da jemals diskutiert, den patch in mainline VDR reinzutun ? Ich faende das toll, wenn das drin waere.

naja, der recording patch wie auch das vdr-checkts macht pro TS paket (188 byte) wohl < 20 CPU instruktionen, das ist vernachlaessigbar.

Lass es 200 instruktionen sein, selbst damit ist man unter 1 million/sekunde fuer einen 10 Mbps TS stream.

interessanter waeren weitere ideen, warum da immer noch einige aufnahmefehler sind, aka: discontinuities.