On 05/16/10 23:19, Richard F wrote: > 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)? VDR doesn't do any calculations regarding the number of PID filters. It just assumes that there will be enough of them ;-) You might want to try VDR 1.7.14, which saves a few PID filters. Here's what you could try in VDR 1.6.0-2: - in eit.c exchange the code after the line "// --- cEitFilter -----------" with that from VDR 1.7.14. You may need to leave out the "disable until" part. That saves two PID filters. - disable setting the system time from the transponder (saves another filter in eit.c) Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
