Comments (10)
rofafor
commented on June 11, 2024
Please, try to increase the buffer size (SATIP_BUFFER_SIZE in common.h). I've kept it as low as possible to save memory in RPI setups, but it might be a bit too low for high bandwidth channels (I've tested only 9Mbit/s channels). You should try first 2M and if that doesn't help, use 5M.
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
No success. It seems not a problem of the buffer size, but more that the consumer thread does not work properly. The vdr is blocked once the errors appear. Maybe if you could give me a hint where to search. Is all of the satip code running in the same thread?
from vdr-plugin-satip.
rofafor
commented on June 11, 2024
There's only on producer thread (poller.c) that's feeding all consumer threads (cTSBuffer in vdr/device.c). Now I've elevated the priority a bit in order to avoid any buffer underruns in consumers. Both producer and consumer threads are using VDR's I/O throttling mechanism, but producer thread is using 10ms timeouts instead of 100ms in consumer. So, make sure you're starting the VDR as root (to gain nice capatibilies) and the start fiddling with satip's ringbuffer timeouts (device.c:L33) and producer thread priority (poller.c:L78).
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
The priorities do not seem to be relevant. Remember that I can watch high data rate channels, record multiple channels, without problems. Then, one out of ten times, directly after a channel switch the errors apear and the VDR blocks. It seems that the thread who shall read from tsBufferM is blockes.
I replaced all debug16 in device.c with an if(ddd) info(). ddd is put to 1 by cSatipDevice::WriteData if len != lengthP, i.e. with the first call to tsBufferM->ReportOverflow. As you can see, only cSatipDevice::WriteData and cSatipDevice::HasLock is called after the error:
May 6 22:27:40 core vdr: [10026] switching to channel 8 (arte HD)
May 6 22:27:40 core vdr: [10026] [softhddev]SetPlayMode: 0
May 6 22:27:40 core vdr: [10026] [softhddev]SetVideoDisplayFormat: 1
May 6 22:27:40 core vdr: [10026] [softhddev]GetSpuDecoder:
May 6 22:27:40 core vdr: [15136] osdteletext-receiver thread ended (pid=10026, tid=15136)
May 6 22:27:40 core vdr: audio/alsa: using device 'default'
May 6 22:27:40 core vdr: video: slow down video, duping frame
May 6 22:27:40 core vdr: video: decoder buffer empty, duping frame (1286/84) 0 v-buf
May 6 22:27:40 core vdr: video: --:--:--.--- +0 0 0/\ms 0+0 v-buf
May 6 22:27:40 core vdr: audio/alsa: start delay 336ms
May 6 22:27:40 core vdr: [10032] ERROR: 1 ring buffer overflow (564 bytes dropped)
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10036] SATIP: virtual bool cSatipDevice::HasLock(int) const (0) [device 0]
May 6 22:27:40 core vdr: [10036] SATIP: virtual bool cSatipDevice::HasLock(int) const (0) [device 0]
May 6 22:27:40 core vdr: [10036] SATIP: virtual bool cSatipDevice::HasLock(int) const (0) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
May 6 22:27:40 core vdr: [10032] SATIP: virtual void cSatipDevice::WriteData(uchar*, int) [device 0]
If I understand it correctly, the data is pulled from tsBufferM in cSatipDevice::GetData, called by cSatipDevice::GetTSPacket, but they do not get called anymore...
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
OK, it seems to get blocked elswherre. I see GetTSPacket getting called and returning properly. But after the channel switch it is not called anymore. Can you please confirm that satip can be excluded in this case?
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: enter GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: enter GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: enter GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: enter GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: enter GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: enter GetTSPacket()
May 7 10:50:48 core vdr: [24646] SATIP: DDDDDD: return 2 GetTSPacket()
May 7 10:50:48 core vdr: [24647] osdteletext-receiver thread ended (pid=24078, tid=24647)
May 7 10:50:48 core vdr: video: slow down video, duping frame
May 7 10:50:48 core vdr: video: decoder buffer empty, duping frame (1176/139) 0 v-buf
May 7 10:50:48 core vdr: video: --:--:--.--- +0 0 0/\ms 0+0 v-buf
May 7 10:50:48 core vdr: audio/alsa: start delay 336ms
May 7 10:50:49 core vdr: [24084] ERROR: 1 ring buffer overflow (564 bytes dropped)
May 7 10:50:50 core vdr: [24084] SATIP: Detected 1 RTP packet errors [device 0]
May 7 10:50:55 core vdr: [24084] ERROR: 594 ring buffer overflows (781704 bytes dropped)
May 7 10:51:01 core vdr: [24084] ERROR: 594 ring buffer overflows (781704 bytes dropped)
May 7 10:51:07 core vdr: [24084] ERROR: 595 ring buffer overflows (783020 bytes dropped)
from vdr-plugin-satip.
rofafor
commented on June 11, 2024
Please, get rid of all non-essential plugins and leave only satip and softhddevice there. You'll have at least osdteletext using a receiver and maybe some others too: too many moving parts make it hard to pinpoint the root cause for a malfunction.
The VDR exits the device thread if the GetTSPacket returns false. Satip always returns true, even if there's no data available, so in that sense it isn't the one to blame here. Now, the VDR is passing the got TS packet to all registered receivers, so if one of the Receive methods is blocking the whole device thread is frozen.
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
Yes, this was the first I did ;-). But even then, I managed to trigger the error. But you are right, it is easier with less plugins. I will now add further debug code in vdr's cDevice::Action() to detect where it starts to block.
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
In fact it seems to be related to the osdteletext plugin leading to some mutex deadlock in Detach()... Therefore we can close here (see http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/128920-ring-buffer-overflows-cdevice-detach-blockiert/).
Thanks for your help.
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
Grrr... osdteletext is not the real reason. Even without it the deadlock kicks in, although much less often. Locking at the backtrace of the locked thread it is indeed related to the cCaPidReceiver:
#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007f5c05017b05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x1171f70) at ../nptl/pthread_mutex_lock.c:81
#2 0x000000000050ad09 in cMutex::Lock (this=0x1171f70) at thread.c:193
#3 0x000000000050b2af in cMutexLock::Lock (this=0x7f5b537fdbd0, Mutex=<optimized out>) at thread.c:373
#4 0x00000000004845b8 in cDevice::Detach (this=this@entry=0x116f690, Receiver=Receiver@entry=0x125c400) at device.c:1690
#5 0x0000000000474411 in cCaPidReceiver::Receive (this=0x125c400, Data=<optimized out>, Length=<optimized out>) at ci.c:213
#6 0x000000000048648b in cDevice::Action (this=0x116f690) at device.c:1614
#7 0x000000000050b119 in cThread::StartThread (Thread=0x116f690) at thread.c:262
#8 0x00007f5c05015454 in start_thread (arg=0x7f5b537fe700) at pthread_create.c:334
#9 0x00007f5c039c4eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Any ideas?
from vdr-plugin-satip.
REELcoder
commented on June 11, 2024
from vdr-plugin-satip.
Related Issues (20)
- ERROR: SATIP poller thread HOT 5
- channel retune issue HOT 20
- missing quirk for Inverto IDL-400s HOT 4
- Reoccuring RTP errors with Octopus NET S2 V1.1.5/1.1.6 HOT 43
- Plugin uses all available tuners of AVM Fritz! box when using wirbelscan
- vdr-2.5.1 crash HOT 1
- New release? HOT 4
- question about your website HOT 1
- Glitches when switching channels HOT 6
- create satip.h HOT 4
- README/log improvements: list names of supported devices ("description"), quirks, ... HOT 2
- Plugin does not start fresh connection after Curl timeout HOT 2
- PIDs are added and removed again within milliseconds HOT 9
- Returncode 404 from minisatip is not handled HOT 6
- Session times out on EXIP418 when timeout is equal to eMinKeepAliveIntervalMs HOT 9
- 250ms delay between commands is missing sometimes HOT 1
- plugin reports signal strength in dBm wrong to vdr, if server reports zero signal strength HOT 8
- octopus: "RTSP/1.0 455 Method Not Valid in This State" followed by vdr crash
- Problem with StreamID 0 HOT 2
- Maintenance state of your plugins? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vdr-plugin-satip.