Yes, I too don't see how it can be harmful. In case you want to
collect statistics, I did it with this patch (for a single device):
http://pastebin.com/6NAVNMda
Best,
Sergey Chernyavskiy.
2016-03-20 16:07 GMT+03:00 Klaus Schmidinger :
> On 18.03.2016 22:14, glenvt18 wrote:
>>
>> UPDATE.
>>
>> H
On 18.03.2016 22:14, glenvt18 wrote:
UPDATE.
Here are 60 Mbit/s (entire transponder) test results:
http://pastebin.com/nHDN8nsW
- the same behaviour as for 30- Mbit/s, no huge chunks on the second
read. Threshold value of 7 was chosen for demonstration only. It's
just a bit smaller than th
UPDATE.
Here are 60 Mbit/s (entire transponder) test results:
http://pastebin.com/nHDN8nsW
- the same behaviour as for 30- Mbit/s, no huge chunks on the second
read. Threshold value of 7 was chosen for demonstration only. It's
just a bit smaller than the mean which is about 75000. Notice tha
Hi Klaus,
I've tested your patch on x86_64 and ARM (I picked the weakest HW I
have). I've gathered some statistics:
http://pastebin.com/kXEP9Bp7
Notes.
A "good" tuner there means the one that returns bigger chunks on
average and generally consumes less CPU cycles with a vanilla (not
patched) VDR
On 10.03.2016 02:54, glenvt18 wrote:
Hi folks,
I've found that with some DVB tuner drivers poll() returns when there
are only small (1-3) number of TS packets available to read(). This
results in high CPU usage of the TS buffer thread which is busy
reading small chunks of data in cTSBuffer::Acti