Klaus Schmidinger Klaus.Schmidinger@cadsoft.de writes:
What we would need to know first is which of VDR's threads actually consumes all this CPU time.
Now it seems this thread has got out of control: --- pahartik 28311 91.9 9.5 108560 13636 pts/1 R+ 20:17 168:41 ./vdr --config=sarabi-config --video=/dvb/video --plugin=streamdev-server --plugin=subtitles ---
Then look into the log file and find out which VDR thread corresponds to the pid that consumes the most CPU time.
--- Dec 5 20:17:49 sarabi vdr[28310]: streamdev-writer thread started (pid=28310, tid=-1) Dec 5 20:17:49 sarabi vdr[28312]: receiver on device 1 thread started (pid=28312, tid=-1) Dec 5 20:17:49 sarabi vdr[28311]: streamdev-livestreaming thread started (pid=28311, tid=-1) Dec 5 20:17:49 sarabi vdr[28313]: TS buffer on device 1 thread started (pid=28313, tid=-1) Dec 5 20:27:21 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:27:24 sarabi vdr[28312]: buffer usage: 60% (tid=1376265) Dec 5 20:27:34 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:27:39 sarabi vdr[28312]: buffer usage: 60% (tid=1376265) Dec 5 20:27:47 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:27:59 sarabi vdr[28312]: buffer usage: 60% (tid=1376265) Dec 5 20:27:59 sarabi vdr[28312]: buffer usage: 70% (tid=1376265) Dec 5 20:28:46 sarabi vdr[28312]: buffer usage: 80% (tid=1376265) Dec 5 20:29:59 sarabi vdr[28312]: buffer usage: 90% (tid=1376265) ---
Several hours later... Looks like streamdev-server does not always know when to stop. It is not sending packets anymore, according to ethernet switch and iftop output. That buffer usage growing towards 100% probably is result of network being slow between client and server, it does not happen when streaming to client on LAN. Stream in question is 160 kilobits per second MPEG-2 audio layer 2 ES stream to HTTP client. Buffer reaching 100% usage does not always cause this problem of thread going wild, thread may still exit normally when other end quits.