bug with setting DeCsaTsBuffSize=2048?

[warpme]

Hi, I think there is bug in code related to allocation of DeCsaTsBuffSize. Looking on /sc/PLUGINS/src/device.c:

tsBuffer=new cDeCsaTSBuffer(fd_dvr,MEGABYTE(ScSetup.DeCsaTsBuffSize),CardIndex()+1,decsa,ScActive());

there is macro 'MEGABYTE'. ./sc/include/ffdecsawrapper/tools.h:#define MEGABYTE(n) ((n) * 1024 * 1024)

So setting DeCsaTsBuffSize=2048 means allocating it with 2GB not 2MB...or I do miss something?

[bas-t]

I've been wondering myself about this. Checking cat /proc/meminfo does not support your conclusion. Nevertheless, it is quite obvious that there is a bug involved. ATM setting tsbuffersize to 2048 solves my tuning problems. As a temp workaround. I'm short on time right now, so I invite you to do a thorough job on this and send me a pull request

[warpme]

May You give some details on tuning problems?. I have 4 DVB-S2 tuners and stable operation. Measure for this can be avg. rate of failed rec. is 1 per 500-1000 recordings (and MythTV logs aren't telling me root cause is within softcam). Also recording concurrency is OK as doing tests for 16 concurrently starting recordings hasn't single failed rec. in series of 50 tests. I do those tests with unicable - so shared SCR bus is additional complication factor here. I think first thing You can consider is to apply https://code.mythtv.org/trac/ticket/10997 as currently MythTV can send undesired Discq commands which can impact tuner demodulator lock and this can impact ongoing recordings/LiveTV. Every Disecq cmds. is interpreted by softcam as separated tuning. So unneeded Disecq are very costly for softcam and have critical impact on MythTV multirec stability.

[warpme]

Ah - I forgot to mention. If we don't see huge mem allocation in /proc/meminfo then this means given system setup (CPU/storage speed, system load, etc) isn't requiring to allocate much of available to allocate buffer space. This is good sign. Also mem allocation by cDeCsaTSBuffer is on-demand - so even if we will declare 1TB and code operation timings will require to buffer 1M - 1M will be allocated. Only thing which You need to change in code is return to Mbyte unit during setting size + help screens. IIRC in my case increasing buffer above 4M hasn't any impact on speed or stability.

[bas-t]

No Diseqc here, I've got 8 dvb-c tuners in my backend.

[warpme]

Hi, I'm afraid there is missing KEY change. Line 948 in https://github.com/bas-t/ffdecsawrapper/blob/stable/sc/PLUGINS/src/sc.c still has "DeCsaTsBuffSize=2048;" which means by default we are allocating 2GB for DeCSA buffer. Also I think line 439 in configure should be also addressed... Generally - I don't understand why You are touching DeCsaBuffer when this functionality is already there: changeset: 561:6f9890bae547 branch: trunk user: leslie date: Sat Jul 23 17:00:07 2011 +0200 summary: added option to set TS buffer size

[bas-t]

Leslie never made that functional. I added a config option to do just that. However, until the bug in mythtv that causes my tuning problems with LiveTV is solved, I'll leave things as they are now. It should not hurt anybody, since "mem allocation by cDeCsaTSBuffer is on-demand". But if you don't like it, you can just use the config option --tsbuffer=4, and you'll be back into the previous state.