vorzugsweise wenn es auf der Festplatte eng wird
Damit hat es wohl doch nichts zu tun.
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
Um welche Hardware geht's denn dabei? SD-FF oder HD-FF? Verwendest Du (bei dem problematischen Sender) das 'böse' Plugin?
Gruss Steve135
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.
full-ts-mod
Danke, aber das kommt für mich nicht in Frage.
Laut Wiki geht es aber auch darum, einen Flaschenhals zu umgehen für den Fall, daß man zwei Programme vom selben Transponder gleichzeitig aufnimmt. Das ist bei mir nicht der Fall.
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?
02:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB card rev2.1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 19
Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: dvb
video2:~# femon -H -a 0
FE: ST STV0299 DVB-S (DVBS)
Problem retrieving frontend information: Function not implemented
status SCVYL | signal 67% | snr 71% | ber 16384 | unc -1216748743 | FE_HAS_LOCK
Problem retrieving frontend information: Function not implemented
status SCVYL | signal 68% | snr 71% | ber 0 | unc -1216748743 | FE_HAS_LOCK
video2:~# tail -f /var/log/syslog
May 30 21:22:13 video2 vdr: [4596] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 21:22:16 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:18 video2 vdr: [4596] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 21:22:19 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:21 video2 vdr: [4596] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 21:22:22 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:24 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:25 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:26 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:27 video2 vdr: [4596] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 21:22:27 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:28 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
May 30 21:22:30 video2 vdr: [4599] ERROR: driver buffer overflow on device 1
top - 21:21:49 up 1 day, 6:58, 1 user, load average: 0.05, 0.13, 0.07
Tasks: 62 total, 1 running, 61 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 1.3%sy, 0.7%ni, 97.0%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st
Mem: 3830792k total, 650368k used, 3180424k free, 328588k buffers
Swap: 2650684k total, 0k used, 2650684k free, 193100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4553 vdr 20 0 115m 27m 3764 S 2.7 0.7 10:19.25 vdr
4626 root 20 0 2332 1132 900 R 0.3 0.0 0:00.01 top
1 root 20 0 2032 700 608 S 0.0 0.0 0:01.71 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.04 ksoftirqd/0
After restart of VDR:
May 30 21:23:36 video2 vdr: [4736] buffer usage: 90% (tid=4728)
May 30 21:23:37 video2 vdr: [4736] buffer usage: 100% (tid=4728)
May 30 21:23:38 video2 vdr: [4736] ERROR: driver buffer overflow on device 1
May 30 21:23:40 video2 vdr: [4736] ERROR: driver buffer overflow on device 1
May 30 21:23:41 video2 vdr: [4736] ERROR: driver buffer overflow on device 1
May 30 21:23:41 video2 vdr: [4728] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 21:23:43 video2 vdr: [4736] ERROR: driver buffer overflow on device 1
May 30 21:23:45 video2 vdr: [4728] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 21:23:54 video2 vdr: [4736] ERROR: driver buffer overflow on device 1
May 30 21:23:56 video2 vdr: [4728] ERROR: skipped 11 bytes to sync on TS packet on device 1
video2:~# femon -H -a 0
FE: ST STV0299 DVB-S (DVBS)
Problem retrieving frontend information: Function not implemented
status SCVYL | signal 68% | snr 71% | ber 32000 | unc -1217440967 | FE_HAS_LOCK
Problem retrieving frontend information: Function not implemented
status SCVYL | signal 68% | snr 71% | ber 0 | unc -1217440967 | FE_HAS_LOCK
Problem retrieving frontend information: Function not implemented
status SCVYL | signal 68% | snr 71% | ber 0 | unc -1217440967 | FE_HAS_LOCK
video2:~# vdr -V
vdr (1.7.18/1.7.18) - The Video Disk Recorder
dvbsddevice (0.0.4) - SD Full Featured DVB device
femon (1.7.9) - DVB Signal Information Monitor (OSD)
video2:~#
video2:~# ctvdrsysinfo
CPU:
99.1% - User 0.7%us, - System 1.0%ni,
Memory:
3741.01 MB Ram - 635.633 MB Belegt
Swap:
2588.56 MB Swap - 0 MB Belegt
Disk Space:
/dev/sda1 : 2.5G von 3.8G frei
udev : 1.9G von 1.9G frei
tmpfs : 1.9G von 1.9G frei
/dev/sda6 : 381G von 453G frei
/dev/sdb9 : 200G von 238G frei
Tasks:
64 - Running 1 - Sleep 63 - Stopped 0
video2:~# ctvdrinfo
**************************************
* c't VDR Ãbersicht *
**************************************
VDR : 1.7.18-2~ctvdr1
Kernel: 2.6.32-5-486
ABI : vdr-abi-1.7.18-multipatch
Patches:
--------------------------------------
opt-20_liemikuutio
opt-21_internal-cam-devices
opt-22-x_edit_marks
opt-24_jumpplay
opt-27_ttxtsubs
opt-31-x_reelchannelscan
opt-37-x_menuorg
opt-38_disableDoubleEpgEntrys
opt-39_noepg
opt-41-x_timer-info
opt-42-x_MainMenuHooks
opt-43-x_recordshowfree
opt-44_rotor
opt-45_yaepg
opt-48-x_pin
opt-50_graphtft
opt-50_graphtft-liemikuutio
opt-51_cuttime
opt-52_hard_link_cutter
Plugins:
( N = Native Plugin )
( D = Debian Plugin )
( - = Deaktiviert )
--------------------------------------
D dvbsddevice
Package: vdr-plugin-dvbsddevice
Version: 1.7.18-2~ctvdr1
D femon
Package: vdr-plugin-femon
Version: 1.7.9-3
AddonÂPackages:
--------------------------------------
......................................edit:
Das Teil ist aumbedienbar:
May 30 22:04:57 video2 vdr: [1577] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 22:04:58 video2 vdr: [1586] ERROR: driver buffer overflow on device 1
May 30 22:04:59 video2 vdr: [1569] switching to channel 1
May 30 22:05:00 video2 vdr: [1577] ERROR: TS packet not accepted in Transfer Mode
May 30 22:05:00 video2 vdr: [1577] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 22:05:00 video2 vdr: [1586] buffer usage: 60% (tid=1577)
May 30 22:05:00 video2 vdr: [1569] ERROR (dvbsdffdevice.c,520): Connection timed out
May 30 22:05:00 video2 kernel: [ 2075.712013] __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
May 30 22:05:00 video2 kernel: [ 2075.712030] dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
May 30 22:05:00 video2 kernel: [ 2075.712041] dvb-ttpci: av7110_fw_cmd error -110
May 30 22:05:01 video2 vdr: [1569] ERROR (dvbsdffdevice.c,528): Connection timed out
May 30 22:05:01 video2 kernel: [ 2076.768011] __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
May 30 22:05:01 video2 kernel: [ 2076.768028] dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
May 30 22:05:01 video2 kernel: [ 2076.768038] dvb-ttpci: av7110_fw_cmd error -110
May 30 22:05:02 video2 vdr: [1569] ERROR (dvbsdffdevice.c,529): Connection timed out
May 30 22:05:02 video2 kernel: [ 2077.784011] __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
May 30 22:05:02 video2 kernel: [ 2077.784028] dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
May 30 22:05:02 video2 kernel: [ 2077.784039] dvb-ttpci: av7110_fw_cmd error -110
May 30 22:05:06 video2 vdr: [1586] buffer usage: 70% (tid=1577)
May 30 22:05:06 video2 vdr: [1586] buffer usage: 60% (tid=1577)
May 30 22:05:06 video2 vdr: [1586] buffer usage: 70% (tid=1577)
May 30 22:05:06 video2 vdr: [1586] buffer usage: 60% (tid=1577)
May 30 22:05:06 video2 vdr: [1586] buffer usage: 70% (tid=1577)
May 30 22:05:06 video2 vdr: [1586] buffer usage: 80% (tid=1577)
May 30 22:05:06 video2 vdr: [1586] buffer usage: 90% (tid=1577)
May 30 22:05:07 video2 vdr: [1586] buffer usage: 100% (tid=1577)
May 30 22:05:08 video2 vdr: [1586] ERROR: driver buffer overflow on device 1
May 30 22:05:10 video2 vdr: [1586] ERROR: driver buffer overflow on device 1
May 30 22:05:11 video2 vdr: [1577] ERROR: skipped 11 bytes to sync on TS packet on device 1
May 30 22:05:12 video2 vdr: [1569] connect from 127.0.0.1, port 54028 - accepted
May 30 22:05:12 video2 kernel: [ 2088.140011] dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1Bei mir kam der Ärger nach Umstieg auf Linux 3 und Wechsel von TT FF S2300 zu C2300 und das hat geholfen:
# 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:
# lspci -v |grep -A 1 Philips
00:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH Octal/Technotrend DVB-C for iTV
--
00:07.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01)
Subsystem: Creatix Polymedia GmbH Device 0005
--
00:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: KNC One Device 0021
00:0d.0 RAID bus controller: Promise Technology, Inc. PDC20579 SATAII 150 IDE Controller (rev 02)
Subsystem: Promise Technology, Inc. PDC20579 SATAII 150 IDE ControllerMit dieser PCI- Konfiguration (ohne gibts grüne Blitze im Bild):
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 saa7134Die 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
# grep device /var/log/syslog
...
Jul 28 23:27:34 tom1 vdr: [4704] loading plugin: /usr/lib/vdr/plugins/libvdr-dvbsddevice.so.1.7.28
Jul 28 23:27:34 tom1 vdr: [4704] ERROR: unknown config parameter: dvbsddevice.SDFF_TSOutput = 1
Jul 28 23:27:34 tom1 vdr: [4704] new device number 1
Jul 28 23:27:34 tom1 vdr: [4709] CI adapter on device 0 thread started (pid=4704, tid=4709)
Jul 28 23:27:34 tom1 vdr: [4704] new device number 2
Jul 28 23:27:34 tom1 vdr: [4713] CI adapter on device 1 thread started (pid=4704, tid=4713)
Jul 28 23:27:35 tom1 vdr: [4704] new device number 3
Jul 28 23:27:35 tom1 vdr: [4704] found 3 DVB devices
Jul 28 23:27:35 tom1 vdr: [4704] initializing plugin: dvbsddevice (0.0.6): SD Full Featured DVB device
Jul 28 23:27:35 tom1 vdr: [4704] setting primary device to 1
Jul 28 23:27:35 tom1 vdr: [4704] starting plugin: dvbsddevice
Jul 28 23:27:36 tom1 vdr: [4733] receiver on device 1 thread started (pid=4704, tid=4733)
Jul 28 23:27:36 tom1 vdr: [4734] TS buffer on device 1 thread started (pid=4704, tid=4734)
Jul 28 23:27:36 tom1 vdr: [4704] switching device 2 to channel 81
Jul 28 23:27:37 tom1 vdr: [4704] switching device 3 to channel 48
Jul 28 23:27:37 tom1 vdr: [4742] receiver on device 2 thread started (pid=4704, tid=4742)
Jul 28 23:27:37 tom1 vdr: [4743] TS buffer on device 2 thread started (pid=4704, tid=4743)
Jul 28 23:27:37 tom1 vdr: [4704] switching device 2 to channel 79
Jul 28 23:27:38 tom1 vdr: [4704] switching device 3 to channel 48
Jul 28 23:27:38 tom1 vdr: [4761] receiver on device 3 thread started (pid=4704, tid=4761)
Jul 28 23:27:38 tom1 vdr: [4763] TS buffer on device 3 thread started (pid=4704, tid=4763)
Jul 28 23:48:00 tom1 vdr: [4704] switching device 1 to channel 66
Jul 28 23:48:00 tom1 vdr: [4734] TS buffer on device 1 thread ended (pid=4704, tid=4734)
Jul 28 23:48:00 tom1 vdr: [4733] receiver on device 1 thread ended (pid=4704, tid=4733)
Jul 28 23:48:01 tom1 vdr: [4880] receiver on device 1 thread started (pid=4704, tid=4880)
Jul 28 23:48:01 tom1 vdr: [4881] TS buffer on device 1 thread started (pid=4704, tid=4881)
Jul 28 23:48:03 tom1 vdr: [4881] TS buffer on device 1 thread ended (pid=4704, tid=4881)
Jul 28 23:48:03 tom1 vdr: [4880] receiver on device 1 thread ended (pid=4704, tid=4880)
Jul 28 23:48:03 tom1 vdr: [4895] receiver on device 1 thread started (pid=4704, tid=4895)
Jul 28 23:48:03 tom1 vdr: [4896] TS buffer on device 1 thread started (pid=4704, tid=4896)
Jul 28 23:48:03 tom1 vdr: [4704] switching device 1 to channel 66
Jul 28 23:48:03 tom1 vdr: [4896] TS buffer on device 1 thread ended (pid=4704, tid=4896)
Jul 28 23:48:03 tom1 vdr: [4895] receiver on device 1 thread ended (pid=4704, tid=4895)
Jul 28 23:48:03 tom1 vdr: [4897] receiver on device 1 thread started (pid=4704, tid=4897)
Jul 28 23:48:03 tom1 vdr: [4899] TS buffer on device 1 thread started (pid=4704, tid=4899)Tja, wohl doch nicht, ARD/ZDF senden einfach mit zu hoher Videobitrate:
Aug 23 22:49:29 tom1 vdr: [4087] switching device 1 to channel 55
Aug 23 22:49:29 tom1 vdr: [4551] TS buffer on device 1 thread ended (pid=4087, tid=4551)
Aug 23 22:49:29 tom1 vdr: [4550] receiver on device 1 thread ended (pid=4087, tid=4550)
Aug 23 22:49:29 tom1 vdr: [4570] receiver on device 1 thread started (pid=4087, tid=4570)
Aug 23 22:49:29 tom1 vdr: [4571] TS buffer on device 1 thread started (pid=4087, tid=4571)
Aug 23 22:49:57 tom1 vdr: [4571] ERROR: driver buffer overflow on device 1
tom1:~# scan -c 2>&1 |grep -i erste
0x0000 0x6dca: pmt_pid 0x0064 ARD -- Das Erste (running)
Das Erste (0x6dca) 01: PCR == V V 0x0065 A 0x0066 (deu) 0x0067 (mis) TT 0x0068 AC3 0x006a SUB 0x0069
tom1:~# dvbsnoop -s bandwidth -buffersize 256 -n 100 0x0065 |grep '##'
## PID: 101 (0x0065) bad/total packets: 0/102 (= 0.0%) Avrg: 6973.091 kbit/s
tom1:~# scan -c 2>&1 |grep -i tele
0x0000 0x55f6: pmt_pid 0x02bd Frei deutsch -- TELE 5 (running)
TELE 5 (0x55f6) 01: PCR == V V 0x02be A 0x02bf (deu) TT 0x02c2
tom1:~# dvbsnoop -s bandwidth -buffersize 256 -n 10000 0x02be |grep '##'
## PID: 702 (0x02be) bad/total packets: 0/10000 (= 0.0%) Avrg: 1876.248 kbit/sUnd 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.
Die Standardgrösse der Puffer (modinfo 32MB/192KB) sind zu klein für mehrere saa7146- Karten
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:
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:
Nov 2 22:27:03 vdr1 vdr: [10328] switching device 3 to channel 54
Nov 2 22:28:00 vdr1 vdr: [10328] switching device 3 to channel 54
Nov 2 23:08:12 vdr1 vdr: [26151] TS buffer on device 3 thread ended (pid=10328, tid=26151)
Nov 2 23:08:12 vdr1 vdr: [26150] receiver on device 3 thread ended (pid=10328, tid=26150)
Nov 2 23:10:47 vdr1 vdr: [27985] receiver on device 3 thread started (pid=10328, tid=27985)
Nov 2 23:10:47 vdr1 vdr: [27987] TS buffer on device 3 thread started (pid=10328, tid=27987)
Nov 2 23:10:48 vdr1 vdr: [27987] TS buffer on device 3 thread ended (pid=10328, tid=27987)
Nov 2 23:10:48 vdr1 vdr: [27985] receiver on device 3 thread ended (pid=10328, tid=27985)
Nov 2 23:10:48 vdr1 vdr: [27988] receiver on device 3 thread started (pid=10328, tid=27988)
Nov 2 23:10:48 vdr1 vdr: [27990] TS buffer on device 3 thread started (pid=10328, tid=27990)
Nov 2 23:10:56 vdr1 vdr: [27990] TS buffer on device 3 thread ended (pid=10328, tid=27990)
Nov 2 23:10:56 vdr1 vdr: [27988] receiver on device 3 thread ended (pid=10328, tid=27988)
Nov 2 23:26:00 vdr1 vdr: [10328] switching device 3 to channel 21
Nov 2 23:27:00 vdr1 vdr: [10328] switching device 3 to channel 21
Nov 2 23:27:01 vdr1 vdr: [28693] receiver on device 3 thread started (pid=10328, tid=28693)
Nov 2 23:27:01 vdr1 vdr: [28694] TS buffer on device 3 thread started (pid=10328, tid=28694)
Nov 3 00:10:14 vdr1 vdr: [28694] TS buffer on device 3 thread ended (pid=10328, tid=28694)
Nov 3 00:10:15 vdr1 vdr: [28693] receiver on device 3 thread ended (pid=10328, tid=28693)
Nov 3 00:10:15 vdr1 vdr: [10328] switching device 3 to channel 21
Nov 3 00:10:15 vdr1 vdr: [30730] receiver on device 3 thread started (pid=10328, tid=30730)
Nov 3 00:10:15 vdr1 vdr: [30731] TS buffer on device 3 thread started (pid=10328, tid=30731)
Nov 3 00:25:05 vdr1 vdr: [30731] TS buffer on device 3 thread ended (pid=10328, tid=30731)
Nov 3 00:25:05 vdr1 vdr: [30730] receiver on device 3 thread ended (pid=10328, tid=30730)Leider doch wieder reproduzierbar, gerade auf die Sportschau mit Sofortaufnahme geschalten und:
Nov 3 18:04:34 vdr1 vdr: [6484] switching device 1 to channel 55
Nov 3 18:04:34 vdr1 vdr: [13444] TS buffer on device 1 thread ended (pid=6484, tid=13444)
Nov 3 18:04:34 vdr1 vdr: [13443] receiver on device 1 thread ended (pid=6484, tid=13443)
Nov 3 18:04:34 vdr1 vdr: [13453] receiver on device 1 thread started (pid=6484, tid=13453)
Nov 3 18:04:34 vdr1 vdr: [13455] TS buffer on device 1 thread started (pid=6484, tid=13455)
Nov 3 18:06:24 vdr1 vdr: [13455] ERROR: driver buffer overflow on device 1
Nov 3 18:06:27 vdr1 vdr: [13453] ERROR: skipped 11 bytes to sync on TS packet on device 1
Nov 3 18:07:11 vdr1 vdr: [13455] ERROR: driver buffer overflow on device 1
Nov 3 18:07:13 vdr1 vdr: [13453] ERROR: skipped 11 bytes to sync on TS packet on device 1
Latencytop:
Cause Maximum Percentage
Opening file 4438,0 msec 27,8 %
[dvb_usercopy] 4073,5 msec 39,3 %
[av7110_osd_cmd] 3770,5 msec 9,8 %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.
[...] Aber ich glaub wir haben kein Support für crystalhd im VDR? ....
Na und? - Da die crystalhd kein Deinterlacing kann, ist sie für einen VDR so oder so nicht geeignet.
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
Na und? - Da die crystalhd kein Deinterlacing kann, ist sie für einen VDR so oder so nicht geeignet.
Der neue Chipsatz xxx15 auch nicht? Ich hab den älteren nur mal zum "spielen" bestellt.
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.
[...] Der neue Chipsatz xxx15 auch nicht? ....
Keine Ahnung. - Aber wozu die Experimente? Besorge Dir für ~35€ eine vernünftige Grafikkarte (z.B. eine GT520) und gut is. 
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
