HDTV-Tuning

Hi,

nachdem mir bei Spiderman mein Multiswitch einen Strick durch die Rechnung gemacht hat, war ich gestern bei "Panic Room" dabei - allerdings mit Fehlern

Mein System: SuSE 9.2, Duron 1300 m. 256 MByte RAM, VDR 1.3.23, Plugins u.a. Text2Skin, jedoch StarTrek (=Default)-Skin ausgewählt (wg. ungeklärtem hohem System-Load auf manchen Systemen - weiß nicht, ob ich auch davon betroffen bin). vdradmind.pl habe ich per kill ausgeschaltet. Aufgenommen mit einer Nova-s, Primary ist eine Nexus.

Leider ist nach dem System-Log der Puffer 4x auf 100% vollgelaufen (11:40, 44:38, 1:05:31, 1:24:32). Im Syslog stehen lediglich PID-Änderungen drin, ich kann also nicht genau sehen, ob es doch noch irgendetwas neben VDR gab, das dafür gesorgt hat, dass die Platte nicht schnell genug schreiben konnte.

Daher: Wo könnte ich den Puffer vergrößern und würde das überhaupt Sinn machen bei 256 MByte RAM? Gibt´s ansonsten noch andere Tipps oder Möglichkeiten, den VDR ruhiger machen bzw. performanter zu machen (EPG-Scan nur dafür ausschalten???)? Mich wundert auch die gewisse Regelmäßigkeit. Ist es vielleicht das Schreiben der epg.dat alle 10 Minuten?

Ich weiß, die Fragestellung ist recht pauschal, aber vielleicht hat ja jemand ein paar grundlegende Tipps in dieser Richtung...

Zum Abschluss noch ein Ausschnitt aus dem ProjectX-Log (Version 0.82.0.05b; habe ein paar Cut-Marks gesetzt). Sieht das bei Euch, die eine "korrekte" Aufnahme haben, auch so chaotisch aus? Der AC3-Ton scheint auf jeden Fall Müll zu sein...

...
--> AC-3/DTS Audio 
!>  9 PTSs ausgelassen im Strom
Audio PTS: erstes Paket 10:40:26.058, letztes Paket 12:58:22.762
Video PTS: Start 1.GOP 10:40:27.307, Ende letzte GOP 12:58:22.427
-> passe Audio an Video-Zeitlinie an
!> Synchronisationswort fehlt bei Pos.: 40092, @ 00:00:00.000
!> Synchronisationswort gefunden bei Pos.: 40096
-> Ursprungsformat: AC-3, CM, 2/0(2.0), 48000Hz, 256kbps @ 00:00:00.000
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 87384
!> Synchronisationswort fehlt bei Pos.: 87386, @ 00:00:01.312
!> Synchronisationswort gefunden bei Pos.: 88408
-> Ursprungsformat: AC-3, CM, 3/2lfe(5.1), cm-3.0dB, sm-3dB, 48000Hz, 448kbps @ 00:00:01.312
!> 22 Frame(s) (704ms) eingefügt @ 00:00:01.376
!> 4 Frame(s) (128ms) eingefügt @ 00:00:02.400
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 16936684
!> Synchronisationswort fehlt bei Pos.: 16936686, @ 00:05:02.336
!> Synchronisationswort gefunden bei Pos.: 16938476
!> 15 Frame(s) (480ms) eingefügt @ 00:05:02.432
!> 4 Frame(s) (128ms) eingefügt @ 00:05:03.232
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 20591540
!> Synchronisationswort fehlt bei Pos.: 20591542, @ 00:06:08.032
!> Synchronisationswort gefunden bei Pos.: 20593332
!> 19 Frame(s) (608ms) eingefügt @ 00:06:08.128
!> 4 Frame(s) (128ms) eingefügt @ 00:06:09.056
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 31951236
!> Synchronisationswort fehlt bei Pos.: 31951238, @ 00:09:31.136
!> Synchronisationswort gefunden bei Pos.: 31953028
!> 21 Frame(s) (672ms) eingefügt @ 00:09:31.264
!> 4 Frame(s) (128ms) eingefügt @ 00:09:32.256
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 39212460
!> Synchronisationswort fehlt bei Pos.: 39212462, @ 00:11:41.184
!> CRC1 Prüfung fehlgeschlagen bei Pos.: 39214252
!> Synchronisationswort gefunden bei Pos.: 39216044
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 39489036
!> Synchronisationswort fehlt bei Pos.: 39489038, @ 00:11:45.280
!> Synchronisationswort gefunden bei Pos.: 39490828
!> 1 Frame(s) (32ms) eingefügt @ 00:11:45.312
!> CRC1 Prüfung fehlgeschlagen bei Pos.: 39494420
!> Synchronisationswort fehlt bei Pos.: 39494422, @ 00:11:45.376
!> Synchronisationswort gefunden bei Pos.: 39496212
!> 1 Frame(s) (32ms) eingefügt @ 00:11:45.408
!> CRC2 Prüfung fehlgeschlagen bei Pos.: 81120308
!> Synchronisationswort fehlt bei Pos.: 81120310, @ 00:24:06.720
!> Synchronisationswort gefunden bei Pos.: 81122100
-> Ursprungsformat: AC-3, CM, 2/0(2.0), 48000Hz, 256kbps @ 00:24:06.720
!> 21 Frame(s) (672ms) eingefügt @ 00:24:06.848
!> 4 Frame(s) (128ms) eingefügt @ 00:24:07.904
...

Bei ca. 11:40 gab´s einen Aussetzer, bei 24:06 den ersten Schnittpunkt in ProjectX, und die anderen???

Hi burki,

DMA ist eingeschaltet, Chipsatz ist von SiS. Mich wundert der Abstand zwischen den Aussetzern - fast immer ein Vielfaches von 10 Minuten. Und das deutet IMHO entweder auf einen Cron-Job hin (müsste was im syslog stehen) oder eben das Schreiben der epg.data - sind schließlich über 800 Kanäle (inklusive ein paar Leichen).
Auch komisch finde ich, dass im Syslog überhaupt etwas von angepassten PIDs/CAs steht, denn wenn die Nova aufgenommen hat, hätte ja die Nexus den Kanal-Scan durchführen müssen, und das tut sie ja im Normalfall nicht (sonst wäre ja plötzlich das Bild weg...).
Wenn ich epgscan auf 0 setze, wird dann auch die epg.data nicht mehr geschrieben?

Ich habe auch schonmal vor ein paar Wochen 40 Minuten Euro1080 aufgenommen - ohne Aussetzer. Das kann Zufall sein, dass da nix passiert ist, oder die Platte war einfach nicht so defragmentiert. Letzteres soll ja bei ext2/ext3 keine Rolle spielen. Und wie gesagt: Dann wären die Aussetzer unregelmäßiger.

P.S.: In der Tat geht´s mir nur um die Aufnahme. Die Wiedergabe läuft natürlich auf einem schnellen PC.

Hi,

hier mal die hdparm-Daten:

/dev/hdb: = video1 bei mir und die größere Platte:
Timing cached reads: 468 MB in 2.01 seconds = 233.10 MB/sec
Timing buffered disk reads: 58 MB in 3.11 seconds = 18.63 MB/sec

/dev/hda: = video0 bei mir, und auf dieser Platte liegen auch VDR & Co
Timing cached reads: 584 MB in 2.00 seconds = 291.61 MB/sec
Timing buffered disk reads: 38 MB in 3.11 seconds = 12.23 MB/sec

Die hda ist "nur" eine 5.400, also IMHO kein Wunder, wenn sie etwas langsamer ist.
Für beide Platten wird UltraDMA100 angezeigt, am Primary Slave hängt noch ein Brenner mit UDMA33.

Allerdings muss ich Dir Recht geben mit der Aussage, dass doch irgendetwas faul ist:

Mar 27 21:59:40 linux vdr[4836]: low disk space while recording, trying to remove a deleted recording...
Mar 27 21:59:42 linux vdr[4836]: removing recording /video0/Panic_Room/2005-03-26.21.55.50.99.del
Mar 27 21:59:42 linux vdr[4836]: removing /video1/Panic_Room/2005-03-26.21.55.50.99.rec/001.vdr
Mar 27 21:59:47 linux vdr[4859]: channel 22 (EuroNews) event 22:00 'Nachrichten' status 4
Mar 27 21:59:47 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/001.vdr
Mar 27 21:59:47 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/index.vdr
Mar 27 21:59:48 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/002.vdr
Mar 27 21:59:53 linux vdr[4836]: removing /video1/Panic_Room/2005-03-26.21.55.50.99.rec/003.vdr
Mar 27 21:59:59 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/003.vdr
Mar 27 21:59:59 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/004.vdr
Mar 27 22:00:05 linux vdr[4836]: removing /video1/Panic_Room/2005-03-26.21.55.50.99.rec/005.vdr
Mar 27 22:00:11 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/005.vdr
Mar 27 22:00:11 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/006.vdr
Mar 27 22:00:17 linux vdr[4836]: removing /video1/Panic_Room/2005-03-26.21.55.50.99.rec/007.vdr
Mar 27 22:00:23 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/007.vdr
Mar 27 22:00:23 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/008.vdr
Mar 27 22:00:28 linux vdr[4856]: changing pids of channel 69 from 701+701:702:204 to 901+901:902:204
Mar 27 22:00:32 linux vdr[4836]: removing /video1/Panic_Room/2005-03-26.21.55.50.99.rec/009.vdr
Mar 27 22:00:38 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/009.vdr
Mar 27 22:00:38 linux vdr[4836]: removing /video0/Panic_Room/2005-03-26.21.55.50.99.del/010.vdr
Mar 27 22:00:45 linux vdr[4836]: PANIC: watchdog timer expired - exiting!

Ich denke, es ist unnötig zu sagen, dass die laufende Aufnahme damit Schrott war. Und beim Brennen geht das System auch in die Knie.

Auch wenn ich hier Firefox öffne o.ä. reagiert VDR bei Steuerung über Fernbedienung (Nexus-IR-Emfpänger) für einen Moment nicht - als würden Festplattenzugriffe das System total ausbremsen.
Das System geht kurz auf 100% CPU-Last hoch. Der physikalische Speicher ist fast immer voll, Swap-Memory bei rund 65 MByte - vielleicht macht das dem System zu schaffen...

Board ist übrigens ein Asrock K7S8XE+ - nachdem das K7S5A überhaupt nicht vernünftig wollte, ist das mein zweiter (und letzter?) SiS-Versuch. Sah ja bis jetzt ganz gut aus - auch wenn SuSE 9.0 die DMA-Modi wie beim älteren Chipsatz nicht auf Anhieb korrekt setzen wollte. Hier gibt´s mit SuSE 9.2 beim Booten jedoch keine Fehlermeldungen mehr.

Videotext läuft nicht, nur Text2Skin 1.0, TVonscreen und MediaMVP. In der crontab ist nur was für "daily" eingetragen, aber keine stündlichen Kommandos.

Sonst noch Tipps?

Jörg

Hi burki,

Filesystem ist ext3, VDR hat bis vorhin noch 10 Stunden Platz angezeigt - sooo wenig ist das auch nicht :), aber es war schon weitaus leerer.
Dateisystem ist nicht korrupt (regelmäßiger Check beim Hochbooten) - also tippe ich auch auf die Controller - und das dürfte ein Kernel-Update bedeuten, oder? Bei SuSE 9.2 ist "nur" 2.6.8 drin.
Vorhin nochmal mit der KDE-Systeminfo gecheckt, was die Tasks so verbrauchen. VDR liegt da beim schneiden bei rund 10% - das ist der Task, der angeblich am meisten verbraucht - aber die Systemleistung ist bei 100%. Noch ein Hinweis mehr wohl, dass da was mit den IDE-Zugriffen nicht stimmt.

Grüße

Jörg

Eichbaum:
Danke für den Richtwert. Auch wenn ich denke, dass die CPU-Power auch stark den Durchsatz beeinflusst, werde ich etwas Googlen und schauen, ob ein Kernel-Update gemacht werden muss, welche Version etc.
Mein letzer Kernel-Update-Versuch unter SuSE 9.1 lief zwar einigermaßen, aber CD-Automount etc. wollte nicht mehr so, so dass ich etwas vorsichtig damit bin bzw. erst mal ein Image mache...

P.S.: Liest hier zufällig auch jemand, der ein K7S8XE+ hat oder auch ein anderes Board mit SiS748 + 964-Chipsatz? Was sagt Euer hpdarm?

Jörg

Hi,

um nicht gleich einen neuen Kernel installieren zu müssen (in den Changelogs bis 2.6.11 habe ich auch nichts wirklich Revolutionäres gefunden), habe ich mal Knoppix 3.8 eingelegt - das verwendet Kernel 2.6.11 (weiß nicht, welche Subversion). Nach einem hdparm -d1 bleibt bei der /dev/hda alles beim Alten (übrigens Seagate), die /dev/hdb (Samsung 80 GByte, 7200) steigt jedoch von 20 auf 25 MByte/s. Setze ich jetzt noch ein hdparm -u1 /dev/hdb geht´s auf 30 MByte/s hoch, bei /dev/hda bleibt´s aber immer noch auf dem alten Wert.

Kann ich die u1-Option wirklich verwenden? Die Manpages machen einem da wirklich Angst wg. möglicher Datenverluste etc.
Scheint mir fast so, als müsste ich das inzwischen nicht mehr ganz neue Asrock K7S8XE+ gegen ein noch älteres Epox 8K9AI mit KT400 tauschen, das hier noch rumliegt, damit das endlich funktioniert...

Umso frustrierender, dass ich das Board extra auf Empfehlung gekauft habe: http://www.vdrportal.de/board/thread.php?threadid=12795&sid=&hilight=k7s8XE

Grüße

Jörg

Hi,

habe in der letzten Woche in einer Nacht-und-Nebel-Aktion das SiS-Board gegen ein Epox 8K9AI mit Via KT400-Chipsatz getauscht. Während sich auch diesmal bei der ersten Platte nicht viel getan hat, rennt die zweite jetzt wirklich mit 30 MByte/s - und die Aufnahme gestern zeigt in den Logs keine Buffer Overflows mehr.
Allerdings habe ich auch diesmal sicherheitshalber die /video0-Parition der langsamen Platte mit Aufzeichnungen aus /video1 der schnellen Platte gefüllt, damit er nur auf die schnelle Platte aufnimmt, vdradmind gekillt und die LAN-Verbindung zum Windows-PC unterbrochen, damit nicht vielleicht Samba zwischenreinfunkt.

Aber wie schon beim SiS-Board ging auch hier etwas nicht auf Anhieb: der Netzwerkanschluss (Via-Rhine II). Zwei Stunden rumprobiert (auch wieder u.a. mit Knoppix) und schließlich eine interne Netzwerk-Karte eingebaut - dann ging auch das problemlos.

Aber dennoch bin ich etwas angesäuert - das nächste Mal teste ich ein neues Board sofort auf seine Performance unter Linux...

Grüße

Jörg