Not a DVB drivers or hardware issue.
Good old Kaffeine DVB app recordings are OK, no distorted stream.
VDR BUG!
y tom
On 06.11.24 04:57, schorpp wrote:
You're talking about "xineliboutput" and "libxine", as well as "saa7146", "mantis pci tuner cards" and "Broadcomm's crystalhd decoder". Did you change several of these at the same time? Can you start from a working system and change only one at a time, to find out which one causes the problem.
Can you send me a recording that shows the problem? You can use https://www.transfernow.net to do so.
Klaus
Am 07.11.24 um 21:36 schrieb Klaus Schmidinger:
? I didn't understand that fully.
Yes, the issue is reproducible with both tv card models and linux 3.12.40...6.x drivers.
No, the old crystalhd system is already deactivated and dissassembled for selling to eastern europe.
Yes, the testing platform is the new DFI x86 I7 System with plenty of ressources using xineliboutput ffmpeg AV software decoding.
Nov 7 18:13:21 vdr2 vdr: [25428] initializing plugin: xineliboutput (2.0.0-cvs): X11/xine-lib Ausgabe-Plugin
I could install e.g. softhddevice to crosscheck if still available in yavdr precision ppa but kaffeine recording works fine?
The issue occurs using production software vdr 2.0.6 AND
using recent VDR and drivers with minidvblinux.de 6.5 live system (xineliboutput).
Both SD (MTV,ARD,ZDF, DELUXE MUSIC) and HD Channels (ARD,ZDF) affected.
I've already increased the libxine buffer:
Nov 8 01:33:22 vdr2 vdr: [6124] [input_vdr] Using non-default "media.xvdr.num_buffers_hd:5000"
It looks like a problem with the high bandwidth ZDF/ARD channels, like we had with the old TT/Siemens full-featured mpeg2 decoder dvb cards but this should not occur with the advanced TDA10023 Tuner cards,
Recordings of the low bandwidth TELE5/DMF SD channels are always ok.
I've recorded TELE5 and DMF channels simultanously for 2h without any buffer overflow in logs.
Nov 8 03:31:31 vdr2 vdr: [9454] buffer usage: 80% (tid=9453) Nov 8 03:31:57 vdr2 vdr: [9454] buffer usage: 60% (tid=9453) Nov 8 03:31:57 vdr2 vdr: [9454] buffer usage: 70% (tid=9453) Nov 8 03:31:57 vdr2 vdr: [9454] buffer usage: 60% (tid=9453) Nov 8 03:36:44 vdr2 vdr: [6108] buffer stats: 0 (0%) used
Recording high bandwidth zdf neo HD simultanously with DMF SD reproduces the issue:
Nov 8 04:28:14 vdr2 vdr: [11341] buffer usage: 80% (tid=11378) Nov 8 04:28:29 vdr2 vdr: [11341] buffer usage: 90% (tid=11378) Nov 8 04:28:32 vdr2 vdr: [11341] buffer usage: 100% (tid=11378) Nov 8 04:28:32 vdr2 vdr: [11341] ERROR: 1 ring buffer overflow (1 bytes dropped) Nov 8 04:28:38 vdr2 vdr: [11341] ERROR: 15000 ring buffer overflows (2820000 bytes dropped) Nov 8 04:28:45 vdr2 vdr: [11341] ERROR: 5570 ring buffer overflows (1047160 bytes dropped) Nov 8 04:28:52 vdr2 vdr: [11341] ERROR: 4974 ring buffer overflows (935112 bytes dropped) Nov 8 04:28:58 vdr2 vdr: [11341] ERROR: 20223 ring buffer overflows (3801924 bytes dropped)
After some Minutes the buffers overflow and the record gets distorted.
Where's the (ring) buffer code in VDR sources, I try increasing?
Nov 7 05:00:59 vdr2 vdr: [2348] [input_vdr] vdr_plugin_write: buffer overflow ! (2068 bytes) Nov 7 05:01:20 vdr2 vdr: [2348] [input_vdr] vdr_plugin_write: buffer overflow ! (2068 bytes)
What is the correct driver module debug parameter to provide a useful debog log?
There're no buffer options in the mantis kernel driver.
https://www.transfernow.net/dl/20241108oxywvwO3/xMpWPpc5
ffmpeg analyze log attached here. -Attachment unix encoded TXT-
Klaus
y tom
Hello Klaus,
Am 08.11.24 um 04:35 schrieb schorpp:
I've FIXED it.
Nov 9 18:25:33 vdr2 vdr: [5318] buffer stats: 178600 (3%) used Nov 9 18:25:33 vdr2 vdr: [5337] TS buffer on device 1 thread started (pid=4621, tid=5337, prio=high) Nov 9 20:12:00 vdr2 vdr: [8367] TS buffer on device 2 thread started (pid=4621, tid=8367, prio=high) Nov 9 21:57:57 vdr2 vdr: [11332] TS buffer on device 3 thread started (pid=4621, tid=11332, prio=high) Nov 9 23:13:00 vdr2 vdr: [5337] TS buffer on device 1 thread ended (pid=4621, tid=5337) Nov 9 23:13:00 vdr2 vdr: [5335] buffer stats: 500268 (9%) used Nov 9 23:13:00 vdr2 vdr: [13456] TS buffer on device 1 thread started (pid=4621, tid=13456, prio=high) Nov 9 23:13:01 vdr2 vdr: [4621] buffer stats: 0 (0%) used Nov 9 23:30:00 vdr2 vdr: [4621] buffer stats: 222968 (1%) used Nov 9 23:37:52 vdr2 vdr: [4621] buffer stats: 474136 (2%) used Nov 9 23:37:52 vdr2 vdr: [11332] TS buffer on device 3 thread ended (pid=4621, tid=11332) Nov 9 23:37:52 vdr2 vdr: [11331] buffer stats: 233872 (11%) used Nov 9 23:37:53 vdr2 vdr: [14185] TS buffer on device 3 thread started (pid=4621, tid=14185, prio=high) Nov 10 00:37:14 vdr2 vdr: [4621] buffer stats: 0 (0%) used
Cause was HW unsupported pci hotplug damaged motherboard pci bridge and/or removed antenna signal amplififier.
Now, it's working with best quality on every channel and even faster switch times.
Thank You for VDR.
y tom
Not yet. It occurs again after some days system uptime.
No. dd write speed test showed a regression in the 3.12.40 AHCI SATA driver, HDD write performance dropped down from 60MB/s to 4MB/s on the which is too slow for HDTV or multiple recordings.
After reboot full speed is back. I've upgraded the kernel to the last longterm 4.19.324 stable version to check if this resolves the issue or it is a hardware issue of the
# lspci -vvv -s 00:1f.2 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0]) Subsystem: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] 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: 0 Interrupt: pin B routed to IRQ 32 Region 0: I/O ports at f0d0 [size=8] Region 1: I/O ports at f0c0 [size=4] Region 2: I/O ports at f0b0 [size=8] Region 3: I/O ports at f0a0 [size=4] Region 4: I/O ports at f060 [size=32] Region 5: Memory at f7e36000 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee08004 Data: 4022 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004 Capabilities: [b0] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: ahci
SATA HBA or WDC Drive Firmware.
y tom
It sounds like you've already ruled out hardware and driver issues, which is a solid start. If Kaffeine DVB recordings are fine but VDR is producing a distorted stream, it could be a VDR-specific bug. Have you checked for recent updates or patches? Sometimes, tweaking the buffer settings or testing a different VDR plugin can help.
For a reliable and high-performance network setup, consider <a href="https://theinsightsolutions.com/category/networking-devices/network-switches/?filter_brand=aruba">Buy Aruba Network Switches</a> to ensure smooth data flow in your environment!
-
Klaus Schmidinger -
Marvel Olivia -
schorpp