Insufficient hardware PID filters on tuner

[Richard F <lists@xxxxxxxxxxxxxxxxxxxxx>]

Hi list,

Having another go at a long-standing problem on Freecom USB tuners - a bit more testing:
Using VDR 1.6.0.2, and the problem seems to be that the tuners run out of hardware PID's.
The problem can be reliably repeated tuning to BBC1 & BBC2 on freeview, when 1 channel is already recording on that multiplex
What's appears unusual about these channels is that they need 4 PID's like so:

May 10 17:36:54 ha-server vdr: [7018] changing pids of channel 1 from 600+600:601=eng,602=eng:0:0 to 600+600:601=eng,602=eng:605=eng:0

And tuning to another channel on that TS that uses 3 PID's (e.g BBC news) works OK:

May 10 17:36:53 ha-server vdr: [7018] changing pids of channel 5 from 640+640:641=eng:0:0 to 640+640:641=eng:643=eng:0

The tuners report a capacity of 15 PID's from dmesg so:

[   42.437874] DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom))
[   42.449952] DVB: registering frontend 0 (WideView USB DVB-T)...
[   42.464022] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1d.7/usb4/4-3/input/input4
[   42.475543] dvb-usb: schedule remote query interval to 300 msecs.
[   42.486250] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected.
[   42.755308] usb 4-5: new high speed USB device using ehci_hcd and address 5
[   42.895930] usb 4-5: new device found, idVendor=14aa, idProduct=0221
[   42.907350] usb 4-5: new device strings: Mfr=1, Product=2, SerialNumber=0
[   42.918743] usb 4-5: Product: Digital TV Receiver
[   42.930060] usb 4-5: Manufacturer: Digital TV Receiver
[   42.941813] usb 4-5: configuration #1 chosen from 1 choice
[   42.953252] dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state.
[   42.967224] dvb-usb: will use the device's hardware PID filter (table count: 15).

Some basic investigation...
Looking at the PID's being used during recording of a single channel, using lsof -n | grep adapter1.demux0 I see :

vdr        7008        vdr    7u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   15u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   21u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   22u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   24u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   26u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   27u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   34u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   35u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   36u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   37u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   39u      CHR     212,68                  6038 /dev/dvb/adapter1/demux0

So 12  filters in use, which is several more than needed by the channel being recorded (I assume these are other channels being monitored for epg etc, or is this other stuff in the TS being filtered...?).  When nothing is being recorded the following is typically output:

vdr        7008        vdr    7u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   15u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   21u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   22u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   24u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   26u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   27u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   28u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   39u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0

Sometimes this count is lower (e.g. 8, in which case 2 channels can be recorded).
When it fails, VDR still tries to allocate the PID's for the channel that requires 4:

May 16 19:47:51 ha-server vdr: [7022] ERROR: /dev/dvb/adapter1/demux0: Too many open files
May 16 19:47:51 ha-server vdr: [7022] ERROR (dvbdevice.c,658): Too many open files

Sometimes, after multiple retries, the 2 channels fit the total of 15 (presumably some other PID's discarded) and it records 2 channels OK.
Then after stopping 2 simultaneous recordings (BBC1 + BBC2), and the residual PID count is now just 5.

vdr        7008        vdr    7u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   15u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   21u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   22u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0
vdr        7008        vdr   26u      CHR     212,68                 6038 /dev/dvb/adapter1/demux0

The question is can the total PID count be reduced when VDR is idle, or is there an assumption that a channel uses fewer than 4 PID's in calculating how many to leave spare for recordings (if that's how it works)? 
Or is it that these USB sticks are just old now, and I need one that has more hardware filters - if so does anyone have recommendations?

Thanks!

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr