video stream broken - cAudioRepacker

efp · 27. Mai 2006

Hallo,

Ich habe eine Nexus CI Rev2.3 Karte mit AlphaCrypt Modul und Premiere Karte drinnen.
Alles funktioniert soweit gut, bis auf das kleine detail, daß VDR pro Tag 2-3 abstürzt und so die aufnahmen zerhackt.

Linux verwende ich Suse 10.0 was soweit super hinhaut. Kernel + Kernel module wurde nicht verändert.

diese parameter starte ich vor vdr1.4.0

export LANG=de_DE.iso8859-1

modprobe -v dvb-ttpci budgetpatch=1
modprobe -v budget_patch
modprobe -v videodev
modprobe -v v4l1_compat
modprobe -v v4l2_common
modprobe -v saa7146
modprobe -v video_buf
modprobe -v saa7146_vv
modprobe -v dvb_core
modprobe -v ves1x93

so schauts under " lsmod | grep dvb" aus

dvb_ttpci 124284 18
dvb_core 112828 3 budget_patch,budget_core,dvb_ttpci
l64781 24964 1 dvb_ttpci
saa7146_vv 72320 1 dvb_ttpci
saa7146 36744 4 budget_patch,budget_core,dvb_ttpci,saa7146_vv
ves1820 23556 1 dvb_ttpci
stv0299 29704 2 budget_patch,dvb_ttpci
tda8083 23556 2 budget_patch,dvb_ttpci
stv0297 25856 1 dvb_ttpci
sp8870 24716 1 dvb_ttpci
firmware_class 28672 2 dvb_ttpci,sp8870
ves1x93 24068 2 budget_patch,dvb_ttpci
ttpci_eeprom 19200 2 budget_core,dvb_ttpci
i2c_core 42112 12 budget_patch,budget_core,dvb_ttpci,l64781,ves1820,stv0299,tda8083,stv0297,sp8870,ves1x93,ttpci_eeprom,saa7134

hier die Error Log

May 26 08:45:00 linux vdr: [8219] executing '/video/command.sh before "/video/Colditz_(Colditz)/2006-05-26.08.45.99.99.rec"'
May 26 08:45:00 linux vdr: [8219] record /video/Colditz_(Colditz)/2006-05-26.08.45.99.99.rec
May 26 08:45:00 linux vdr: [8219] creating directory /video/Colditz_(Colditz)
May 26 08:45:00 linux vdr: [8219] creating directory /video/Colditz_(Colditz)/2006-05-26.08.45.99.99.rec
May 26 08:45:00 linux vdr: [8219] recording to '/video/Colditz_(Colditz)/2006-05-26.08.45.99.99.rec/001.vdr'
May 26 08:45:00 linux vdr: [12316] file writer thread started (pid=8219, tid=12316)
May 26 08:45:00 linux vdr: [12317] recording thread started (pid=8219, tid=12317)
May 26 09:17:11 linux vdr: [8224] channel 1 (PREMIERE 1) event Fri 26.05.2006 09:25-11:05 'Colditz (Colditz)' status 2
May 26 09:17:41 linux vdr: [8224] channel 1 (PREMIERE 1) event Fri 26.05.2006 09:25-11:05 'Colditz (Colditz)' status 4
May 26 09:21:15 linux vdr: [8224] channel 7 (PREMIERE 7) event Fri 26.05.2006 09:25-11:30 '21 Gramm' status 2
May 26 09:21:45 linux vdr: [8224] channel 7 (PREMIERE 7) event Fri 26.05.2006 09:25-11:30 '21 Gramm' status 4
May 26 09:28:28 linux syslog-ng[5477]: STATS: dropped 0
May 26 09:28:55 linux vdr: [8224] channel 5 (PREMIERE 5) event Fri 26.05.2006 09:30-10:55 'Partyalarm - Finger weg von meiner Tochter (My Boss's Daughter)'
status 2
May 26 09:29:24 linux vdr: [8224] channel 5 (PREMIERE 5) event Fri 26.05.2006 09:30-10:55 'Partyalarm - Finger weg von meiner Tochter (My Boss's Daughter)'
status 4
May 26 09:29:50 linux vdr: [8224] changing pids of channel 5 from 1279+1279:1280=deu:32 to 1279+1279:1280=deu,1281=deu:32
May 26 09:40:45 linux vdr: [8224] channel 6 (PREMIERE 6) event Fri 26.05.2006 09:50-11:25 'Revolver' status 2
May 26 09:41:14 linux vdr: [8224] channel 6 (PREMIERE 6) event Fri 26.05.2006 09:50-11:25 'Revolver' status 4
May 26 09:46:08 linux vdr: [12317] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 26 09:46:08 linux vdr: [12317] cAudioRepacker(0xC1): skipped 572 bytes while syncing on next audio frame
May 26 09:46:08 linux vdr: [12317] cAudioRepacker(0xC0): skipped 1148 bytes while syncing on next audio frame
May 26 09:46:08 linux vdr: [12311] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 26 09:46:08 linux vdr: [12311] cAudioRepacker(0xC1): skipped 572 bytes while syncing on next audio frame
May 26 09:46:08 linux vdr: [12311] cAudioRepacker(0xC0): skipped 1148 bytes while syncing on next audio frame
May 26 09:46:34 linux vdr: [8219] connect from 127.0.0.1, port 13154 - accepted
May 26 09:46:34 linux vdr: [8219] closing SVDRP connection
May 26 09:46:39 linux vdr: [12316] ERROR: video data stream broken
May 26 09:46:39 linux vdr: [12316] initiating emergency exit
May 26 09:46:39 linux vdr: [8219] emergency exit requested - shutting down
May 26 09:46:39 linux vdr: [12317] recording thread ended (pid=8219, tid=12317)
May 26 09:46:39 linux vdr: [12316] file writer thread ended (pid=8219, tid=12316)
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 3 TS continuity errors
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 2 TS continuity errors
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 2 TS continuity errors
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 4 TS continuity errors
May 26 09:46:39 linux vdr: [8219] buffer stats: 228044 (4%) used
May 26 09:46:39 linux vdr: [8219] timer 1 (2 0845-1025 'Colditz (Colditz)') stop
May 26 09:46:39 linux vdr: [8219] executing '/video/command.sh after "/video/Colditz_(Colditz)/2006-05-26.08.45.99.99.rec"'
May 26 09:46:39 linux vdr: [12311] transfer thread ended (pid=8219, tid=12311)
May 26 09:46:39 linux vdr: [12313] TS buffer on device 1 thread ended (pid=8219, tid=12313)
May 26 09:46:39 linux vdr: [12312] buffer stats: 122952 (5%) used
May 26 09:46:39 linux vdr: [12312] receiver on device 1 thread ended (pid=8219, tid=12312)
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 3 TS continuity errors
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 2 TS continuity errors
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 2 TS continuity errors
May 26 09:46:39 linux vdr: [8219] cTS2PES got 0 TS errors, 4 TS continuity errors
May 26 09:46:39 linux vdr: [8219] buffer stats: 223344 (10%) used
May 26 09:46:39 linux vdr: [8219] saved setup to /video/setup.conf
May 26 09:46:40 linux vdr: [8223] tuner on device 1 thread ended (pid=8219, tid=8223)
May 26 09:46:40 linux vdr: [8224] section handler thread ended (pid=8219, tid=8224)
May 26 09:46:40 linux vdr: [8219] cleaning up schedules data
May 26 09:46:40 linux vdr: [8219] exiting
May 26 09:46:40 linux vdr: [8219] emergency exit!

Vielen Dank!

SvenGWK · 27. Mai 2006

Ein ähnliches Problem habe ich auch , mit Aufnahmen auf Pro7 und ZDF.
Speziell die "Blockbuster" werden in einer hohen Qualität gesendet, wenn dann noch AC3 mit an ist, ist´s ganz vorbei.
Jetzt hab ich es erstmal abgeschaltet, so scheint es zu laufen.
Hab allerdings noch keinen "fetten" film erwischt an dem ich es wirklich testen konnte.
Zu dem Thema gibt es auch einen thread, da wurde die FF Karte verdächtigt die Ursache zu sein.
Ich habe selber allerdings zusätzlich den Verdacht das es auch an den PC´s liegen könnte die manchen (ich z.B.) verwenden.
Hab das hier mal beschreiben: Rechner zu lahm? Fehler bei AC3...
, hat aber auch noch keiner geantwortet.

efp · 27. Mai 2006

SvenGWK,

Würde mich echt wundern, wenn das daran liegen würde.
Lasse das ganze auf einem Pentium 3,8 Ghz HT laufen. Festplatte ist auch neu SATA. 1 Gig Ram ist drinnen.
Obwohl ich schon einen Thread gelesen habe, wo probleme mit SATA berichtet worden sind.

Bei der Aufnahme läuft VDR etwas mit 1% und 1% Memory - also eigentlich schläft der computer fast ein

hdparm -tT /dev/sda1
/dev/sda1:
Timing cached reads: 2016 MB in 2.00 seconds = 1007.94 MB/sec
Timing buffered disk reads: 168 MB in 3.01 seconds = 55.77 MB/sec

linux:/video # /sbin/hdparm -q -k1 -q -c1 -q -u1 -q -M128 /dev/sda1
HDIO_SET_32BIT failed: Invalid argument
HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
HDIO_SET_KEEPSETTINGS failed: Inappropriate ioctl for device
HDIO_SET_ACOUSTIC failed: Inappropriate ioctl for device

läuft alles auf reiserfs.

Dolby/AC3 und extra Sprachestreams die sonst noch ausgesendet werden brauch ich eigentlich überhaupt nicht. Die verwenden nur Platz

vernichte die normalerweise beim konvertieren in eine mpeg2
/usr/bin/vdrsync.pl -mpeg2 -ignore bd,c1,c2,c3 001.vdr

mauerspecht · 28. Mai 2006

efp: Du hast ja schon meine Antwort an SvenGWK gelesen. Die hdparm Sachen funktionieren bei SATA noch nicht alle, sollte auf deinem System sowiso schnell genug sein.

Hast du ein Board mit PCI Express? Dann könnte der nomale PCI Bus benachteiligt sein.

Ich habe auch solche Probleme, seit ich mit CI ISH Grundverschlüsselelt empfange häufiger. Da ist die Kette CI CAM Smartcard vermutlich ein Stolperstein wo es manchmal hängt.

AC3 kannst du schon bei der Aufnahme ignorieren, die Option ist im Setup vermutlich unter DVB zu finden.

efp · 28. Mai 2006

mauerspecht

keine ahnung hab noch nie von "PCI Express" gehört. Wo kann ich das rausfinden.

Weißt du zufällig in welcher Datei ich ac3 gleich bei der aufnahme ignorieren kann? Hör ich heute zum ersten mal, daß das überhaupt geht

Danke

efp · 28. Mai 2006

mauerspecht

also in der einzigen datei wo ich überhaupt was über "ac3" gefunden habe ist remux.c

aber keine ahnung wie ich da genau das ac3 recording rausnehmen kann!?

efp · 28. Mai 2006

mauerspecht

in dvbdevice.c gibt es "SetTransferModeForDolbyDigital" und das ist auf "true"
wenn ich das auf "false" setze würde das dann hinhauen?

SledgE · 28. Mai 2006

ich kenne das auch seit dem ich auf kernel 2.6.x umgestiegen bin.
vorher mit dem 2.4.20 ist das auf identischer hardware *niemals* passiert.
allerdings hatte ich dabei auch den vdr auf den neuesten stand gebracht wobei der sprung nicht sehr groß war.
das problem muß entweder mit dem 2.6er kernel oder dem neuen dvb-treibermodel zu tun haben.
je größer die transferierte datenmenge der dvb über dem pci-bus desto schlimmer wird es.
ich habe lange am kernel geschraubt bis ich es halbwegs im griff hatte.
mittlerweile dropt es gelegendlich noch ein paar bytes wenn ich mehrere sender mit hoher datenrate gleichzeitig über eine einzelne ff-dvb aufnehme.
ansonnsten tritt das prb. nicht mehr auf und so schlimm das der vdr crasht war es bei mir auch nie.

efp · 28. Mai 2006

SledgE
an welchen teilen vom kernel 2.6.x hast du rumgeschraubt weißt du das noch? jedes detail is sicher hilfreich.
Danke.

SledgE · 28. Mai 2006

ich nutze den 2.6.13-2,vorher war der 2.4.20 und 2.4.24 am laufen.
den timer habe ich auf 250hz setzen müssen und gleichzeitig das preemtion des kernels auf mittel.
beide einstellungen hatten auswirkungen und ich hatte verschiedene kombinationen durchprobiert.
desweiteren hat der pci-latency-timer im bios einen einfluß gehabt.
das handling des pci-buses läuft auf meinem board mit dem 2.6er ganz anders als vorher mit dem 2.4er.
mit dem 2.6er hat außer dem ide-controller und der grafikkarte jedes andere pci-gerät den cycle des pci-latency-timers.
dabei müßte die dvb eigendlich einen wesendlich höheren wert an taktzyklen bekommen.
unter 2.4 und auch unter windows beträgt dieser immer 255 clocks,mit 2.6 sind dann aber 32 colcks.
das baord trägt einen sis748,southbridge weiß ich nicht mehr aber es ist die letzte revision für den athlon xp mit sata onboard.
neuere kernels habe ich seitdem nicht wieder installiert da alles zufriedenstellend läuft,eventuell wurde bzgl. des problems nochmal was geändert.

efp · 28. Mai 2006

SledgE :
ok hab im Bios PCI Latency Timer von 32 auf 248 (war das maximum) gesetzt.

mal schauen ob das was bringt - sonst werd ich wahrscheinlich nicht um ein kernel recompile rumkommen.

efp · 28. Mai 2006

des weitern war im Bios ein Eintrag "PCI Express" den ich auf "PCI" umgeändert habe.

SvenGWK · 28. Mai 2006

Und, hat es was genutzt?
Ich werde mir erstmal einen schnelleren Proz zulegen.
Habe das mal beobachtet, es reicht schon während einer Aufnahme den VDR-Admin aufzurufen um Fehlermeldungen zu produzieren.
Die Prozessorlast hängt dann bei 100%.
Ein PII 400 ist wahrscheinlich doch nicht so das wahre.

efp · 28. Mai 2006

SvenGWK
da bei mir die fehlermeldungen nicht gleich kommen kann das etwas dauern.
in spätenstens ein paar tagen werd ich mit sicherheit sagen können ob es geklappt hat oder nicht. werde auf jedenfall in diesem thread posten.

SledgE · 28. Mai 2006

so einfach ist es nicht.
der timer im bios gilt für alle pci-devices welche keinen eigenen wert anfordern.
pci-devices mit hohem datentransferaufkommen benötigen immer einen höheren wert damit sie schnell genug ihre datenmengen transferieren können.
da der pci-bus im multiplexverfahren arbeitet verändert sich auch die "rundenzeit" und damit die zeiten für alle anderen pci-devices.

kurz:
alle pci-geräte hängen zusammen an einem einzigen parallelen bus.
jedes gerät besitzt die fähigkeit sich "tod" zu stellen und so zu tun als ob es nicht vorhanden wäre.
in einer endlosschleife wird nun jedes gerät für eine gewisse zeit aktiv geschaltet und kann mit der cpu kommunizieren wärend alle anderen geräte abgeschaltet sind.
nach dem das erste gerät eine bestimmte zeit (=bestimmte anzahl taktzyklen des buses)aktiv war wird es deaktiviert und das nächste kommt drann.
so geht es der reihe nach um bis alle geräte durch sind und dann geht es mit dem ersten gerät wieder von vorne los.
das geht so schnell das praktisch alle geräte scheinbar gleichzeitig arbeiten können.

daraus ergibt sich das jedes gerät eine bestimmte anzahl taktzyklen zum datentransfer zur verfügung hat,gefolgt von einer wartepause.
die wartepausen hängen nun davon ab wie viele pci-devices vorhanden sind (schleifen größe) und wie lange die anderen geräte jeweils aufgeschaltet sind(anzahl der pci-takte für jedes gerät).

vereinfaches beispiel zur verdeutlichung:

7 pci-devices mit je 32 clocks: jedes gerät kann 32 clcks daten transferieren und muß 192 clcks warten bis es wieder drann ist
7 pci-devices mit je 255 clcks: jedes gerät kann 255 clcks daten transferieren und muß 1530 clcks warten.

durch setzen des latencytimers im bios auf große werte verlängert sich die schleife erheblich und die wartepausen vergrößern sich entsprechend.
das kann wiederum negative effekte bewirken und insgesammt verlängert sich die reaktionszeit aller geräte.
idealerweise hängt jedes gerät nur so lange am bus wie es benötigt um seine daten zu transferieren und die pausen vollständig durch datenpuffer überbrücken kann.
die schleife des controllers ist programmierbar.
das bios setzt die grundwerte und der rest ist aufgabe des betriebssystems.
auch andere programme können den scheifentimer setzen.
unter linux gibt es zum beispiel "setpci" welches das einstellen der taktzyklen für jedes pci-gerät in gewissen grenzen ermöglicht.
busmastering und irqs habe ich mal außen vor gelassen,ich wollte nur das prinzip verdeutlichen.

lange schreibse,kurzer sinn.
wenn das ändern des pci-latencytimers im bios keine abhilfe schafft muß man über das os oder hilfsprogramme wie setpci eingreifen um eine optimale funktion des buses zu erreichen.

der eventtimer der 2.4er kernels war fest auf 100 hz eingestellt soweit ich das mitbekommen habe.
ab dem 2.6er sind auch einstellungen von 250 hz und 1000 hz mgl.
das preempting wirkt sich auf die priorität der hardwareprozesse gegenüber den userprozessen aus.

ich bin der meinung das irgendwas am dvb-treiber faul ist weil dieser dem pci-controller offenbar nicht veranlaßt die richtigen betriebsparameter einzustellen.
es könnte natürlich auch genausogut am kernel selber liegen.
je mehr pci-devices vorhanden sind desto kritischer wird es,deshalb alle unbenötigten devices im bios abschalten.

SledgE · 28. Mai 2006

falls du den latencytimer gezielt für deine dvb-karten(n) setzen möchtest:

lspci -v

-zeigt dir deine geräte und die aktiven parameter an

setpci -v -s <vendor-id> latency_timer=xx

-setzt den timer für das spezielle gerät, vendor-id siehe lspci-ausgabe,xx= hexadezimalwert für die anzahl clocks

bsp.: setpci -v -s 00:0d.0 latency_timer=ff

-setzt das device 00.0d.0 auf 255 clcks

falls es damit funzt kannst du den befehl einfach in eines der startscripte wie rc.local oder so eintragen und gut isses.

efp · 28. Mai 2006

SledgE

lspci hat auch gezeigt was du schon gesagt hast, der wert ist der gleiche den ich im Bios gesetzt habe!

lspci -v
.....
00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH: Unknown device 000e
Flags: bus master, medium devsel, latency 248, IRQ 193
Memory at 00000000febff000 (32-bit, non-prefetchable) [size=512]
......

also was ich gemacht hab ist

setpci -v -s 00:09.0 latency_timer=ff

lspci -v
.....
00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH: Unknown device 000e
Flags: bus master, medium devsel, latency 255, IRQ 193
Memory at 00000000febff000 (32-bit, non-prefetchable) [size=512]
......

(änderung hat funktioniert)

sinnvollerweise wäre es vielleicht clever die Latency beim bios wieder auf 32 zurückzusetzen? So, daß nur die DVB Karte die höhere Latency hat?

Danke!

SledgE · 28. Mai 2006

ja genau,versuche mal nur die clocks für die dvb-karte(n) hochzusetzen und beobachte dann das systemlog.
um die sache zu beschleunigen kannst du ja mal mehrere aufnahmen mit einer karte gleichzeitig starten.
bei zwei oder drei aufnahmen ist die karte bzw. der saa7146 schon am limit so das hier schnell fehler auftreten sollten wenn es immer noch nicht paßt.

efp · 29. Mai 2006

Danke für deine Bemühungen hat soweit recht gut ausgesehen, bis jetzt grad ...

May 29 22:10:00 linux vdr: [7643] Title: 'Keine halben Sachen 2' Subtitle: 'Actionkomýie'
May 29 22:10:00 linux vdr: [7643] executing '/video/command.sh before "/video/Keine_halben_Sachen_2/2006-05-29.22.10.99.99.rec"'
May 29 22:10:00 linux vdr: [7643] record /video/Keine_halben_Sachen_2/2006-05-29.22.10.99.99.rec
May 29 22:10:00 linux vdr: [7643] creating directory /video/Keine_halben_Sachen_2
May 29 22:10:00 linux vdr: [7643] creating directory /video/Keine_halben_Sachen_2/2006-05-29.22.10.99.99.rec
May 29 22:10:00 linux vdr: [7643] recording to '/video/Keine_halben_Sachen_2/2006-05-29.22.10.99.99.rec/001.vdr'
May 29 22:10:00 linux vdr: [9303] file writer thread started (pid=7643, tid=9303)
May 29 22:10:00 linux vdr: [9304] recording thread started (pid=7643, tid=9304)
May 29 22:10:00 linux vdr: [9305] receiver on device 1 thread started (pid=7643, tid=9305)
May 29 22:10:00 linux vdr: [9306] TS buffer on device 1 thread started (pid=7643, tid=9306)
May 29 22:37:41 linux vdr: [7648] channel 2 (PREMIERE 2) event Mon 29.05.2006 22:45-00:25 'Suspect Zero - Im Auge des Mýders (Suspect Zero)' status 2
May 29 22:38:12 linux vdr: [7648] channel 2 (PREMIERE 2) event Mon 29.05.2006 22:45-00:25 'Suspect Zero - Im Auge des Mýders (Suspect Zero)' status 4
May 29 22:57:56 linux vdr: [7648] channel 4 (PREMIERE 4) event Mon 29.05.2006 23:15-00:10 'Six Feet Under - Gestorben wird immer (Six Feet Under)' status 2
May 29 22:58:26 linux vdr: [7648] channel 4 (PREMIERE 4) event Mon 29.05.2006 23:15-00:10 'Six Feet Under - Gestorben wird immer (Six Feet Under)' status 4
May 29 23:12:27 linux vdr: [7643] connect from 127.0.0.1, port 24980 - accepted
May 29 23:12:27 linux vdr: [7643] closing SVDRP connection
May 29 23:20:26 linux vdr: [7648] channel 1 (PREMIERE 1) event Mon 29.05.2006 23:25-01:00 'Anatomie einer Entfhrung (The Clearing)' status 2
May 29 23:20:59 linux vdr: [7648] channel 1 (PREMIERE 1) event Mon 29.05.2006 23:25-01:00 'Anatomie einer Entfhrung (The Clearing)' status 4
May 29 23:24:53 linux vdr: [7648] channel 7 (PREMIERE 7) event Mon 29.05.2006 23:30-01:00 'Schachmatt' status 2
May 29 23:25:25 linux vdr: [7648] channel 7 (PREMIERE 7) event Mon 29.05.2006 23:30-01:00 'Schachmatt' status 4
May 29 23:32:09 linux vdr: [9304] cAudioRepacker(0xC0): skipped 312 bytes while syncing on next audio frame
May 29 23:32:40 linux vdr: [9303] ERROR: video data stream broken
May 29 23:32:40 linux vdr: [9303] initiating emergency exit
May 29 23:32:40 linux vdr: [7643] emergency exit requested - shutting down
May 29 23:32:40 linux vdr: [9304] recording thread ended (pid=7643, tid=9304)
May 29 23:32:40 linux vdr: [9306] TS buffer on device 1 thread ended (pid=7643, tid=9306)
May 29 23:32:40 linux vdr: [9305] buffer stats: 156604 (7%) used
May 29 23:32:40 linux vdr: [9305] receiver on device 1 thread ended (pid=7643, tid=9305)
May 29 23:32:40 linux vdr: [9303] file writer thread ended (pid=7643, tid=9303)
May 29 23:32:40 linux vdr: [7643] cTS2PES got 0 TS errors, 1 TS continuity errors
May 29 23:32:40 linux vdr: [7643] cTS2PES got 0 TS errors, 1 TS continuity errors
May 29 23:32:40 linux vdr: [7643] buffer stats: 156792 (2%) used
May 29 23:32:40 linux vdr: [7643] timer 1 (5 2210-2350 'Keine halben Sachen 2') stop
May 29 23:32:40 linux vdr: [7643] executing '/video/command.sh after "/video/Keine_halben_Sachen_2/2006-05-29.22.10.99.99.rec"'
May 29 23:32:40 linux vdr: [7643] saved setup to /video/setup.conf
May 29 23:32:40 linux vdr: [7647] tuner on device 1 thread ended (pid=7643, tid=7647)
May 29 23:32:40 linux vdr: [7648] section handler thread ended (pid=7643, tid=7648)
May 29 23:32:40 linux vdr: [7643] cleaning up schedules data
May 29 23:32:40 linux vdr: [7643] exiting

....

Bios Latency ist auf 32
Latency wird über setpci für die Karte auf 255 erhöht
letztes update von firmeware ist drauf. Suse 10.0 hatte in /usr/lib/hotplug/firmware davor "dvb-ttpci-01.fw-261f" ... nun "dvb-ttpci-01.fw-2622"

gestartet wird das ganze mit (buget patch hab ich weggelassen, weil es keine budget karte ist)

export LANG=de_DE.iso8859-1
export LC_CTYPE=de_DE.iso8859-1
setpci -v -s 00:09.0 latency_timer=ff

modprobe -v dvb-ttpci
modprobe -v videodev
modprobe -v v4l1_compat
modprobe -v v4l2_common
modprobe -v saa7146
modprobe -v video_buf
modprobe -v saa7146_vv
modprobe -v dvb_core
modprobe -v ves1x93

nice -19 ./vdr -l3.7 --vfat --no-kbd -r /video/command.sh

noch ideen ?

SvenGWK · 30. Mai 2006

Hmm, ist nur so eine fixe Idee...
Wenn man AC3 abschaltet, wird es ja trotzdem mit aufgenommen.
Dazu noch der normale Ton und wenn man Pech hat wird noch eine fremdsprachige Tonspur mitgesendet.
Wenn ich jetzt z.b. mal den Eintrag von Arte in der channels.conf ansehe, finde ich:

arte;ARD:11837:hC34:S19.2E:27500:401:402=deu,403=fra:404:0:28109:1:1101:0

Wenn ich jetzt die PID 404 für den französische Ton entferne, kann er doch die französische Tonspur in diesem Fall auch nicht mehr aufzeichnen.
Das gleiche sollte doch eigentlich auch für den AC3 ton gelten,oder?
Man müsste dann nur nach editieren der Kanalliste das aktualisieren der PID´s abschalten, ansonsten steht der eintrag wahrscheinlich gleich weider drin.
Das AC3 an der Sache mitschuldig ist, bzw. sogar der Grund haben ja schon manche geschrieben.
Wenn das erhöhte Datenvolumen von AC3 bereits sowas auslösen kann, sollte ja bei mehrsprachigem Ton da noch ein wenig mehr an Daten anfallen.
Wenn man also auf AC3 verzichten kann, wäre das eventuell ein Ansatzpunkt...

Bei Pro7 also:

ProSieben;ProSiebenSat.1:12480:vC34:S19.2E:27500:255:256=deu;257=deu:32:0:898:133:33:0

Dort dürfte die PID 257 der 2.deutsche Ton sein, also der AC3.
Ich habe allerdings keine ahnung wozu der Rest dahinter gut ist.
Ein Eintrag von Kabel 1 der nur eine Tonspur sendet sieht so aus:

KABEL1;ProSiebenSat.1:12480:vC34:S19.2E:27500:511:512=deu:33:0:899:133:33:0
Schaut also so aus als wenn man einfach nur den entsprechenden Eintrag entfernen muss um nicht die anderen Spuren zu empfangen.
Dann eben unter den Einstellungen für die Aktualisierung umschalten so das die PID´s nicht mehr geändert werden können.

video stream broken - cAudioRepacker

Jetzt mitmachen!

Teilen