dvbrecorder: limit number of open pid filters

[Janne <janne-mythtv@…>]

dvbrecorder listens currently on each pmt pid in the pat. On some multipplexes this is to much for my Fujitsu-Siemens Full-featured DVB-C card. It can't open more than 27 filters. Unfortunately it fails hard and needs a driver reload to recover if you try to open more.

So this is mainly a driver issue but it's stupid to listen to all PMTs. Attached is probably incorrect since _pat is NULL when AdjustFilters? is first called. Nevertheless it works since _input_pmt is already correct (probably cached from the signalmonitor).

An error report on the linuxtv mailinglist resulted only in a change in the dvbscan utility (​http://www.linuxtv.org/pipermail/linux-dvb/2005-October/005577.html)

[anonymous]

We listen to these pids so that channel changing within a multiplex is quicker. I would accept a patch which optionally did a round-robin pid filter change to get these PMTs, but now something which disables the feature altogether just to support some broken DVB hardware.

[Janne <janne-mythtv@…>]

first round-robin implementation, something like HasEITPIDChanges and PMT tracking in MPEGStremData would be a better approach

[Janne <janne-mythtv@…>]

final version

[Janne <janne-mythtv@…>]

Almost final version of the round robin PMT listening patch.

Opens filter for PMT monitoring until a demux filter can't be opened, i.e we will use all available hardware filter. If we need to open another filter the PMT PID filter with the lowest pid will get closed and pushed back to the queue.

Two small issues remain: We should maybe change the "Failed to set demux filter" VERBOSE level from important to record. I'm not sure if the counter based timer in the read loop is ok. I didn't want to use a real timer with a stop time of 0.2 seconds. 250 runs of the loop take on my computer approximately 0.2 seconds.

[danielk]

I would like to fix this before 0.20, it's a regression for these "full-featured" cards since 0.19.

[danielk]

Janne, the PMT of the program we are recording should not be considered "low priority", only the auxiliary PMTs we use for quick channel changing. We want to respond quickly when the PMT for the current recording changes, say to add subtitles or an extra audio stream, or add video if the channel was previously "off-air" but was transmitting interactive tv info.

Otherwise this looks ok.

[Janne <janne-mythtv@…>]

Right. I haven't thought of that. Updated patch attached.

[danielk]

(In [10860]) Fixes #1970. Adds pid listening priorities. This allows recording to work for cards with very limited pid filtering capabilities.

Tuning to a new channel on the same transport may take a little longer if you use one of these cards, but it should still be faster than tuning in 0.19. Most of the time, tuning should be just as fast since we still monitor other "low priority" pids, we just visit them in a round-robin fashion so the tables are not updated as quickly.

[danielk]

(In [10944]) Refs #1970. Fix debugging output line in DVBRecorder::AdjustMonitoringPMTPIDs().

[danielk]

Reopened, it looks like this accidentally stops listening to all the low priority pids on PMT changes. See message from Otto Kolsi.

[danielk]

Potential fix

[danielk]

(In [10946]) Fixes #1970. Applies patch for dealing with PAT/PMT changes correctly with new pid filter limiting code.

[Axel.Thimm@…]

I received a report form a user who would like to see this fix in 0.20-fixes, so ATrpms could pick it up (or he would rather simply see this fix in ATrpms, but the canonical way is through the fixes branches :)

Is there any chance to backport this to the fixes branch?

Thanks!

[anonymous]

Axel, this was committed back in [10860] and [10946]. 0.20 is [11132]

[Axel.Thimm@…]

Oops, sorry I didn't check the dates. I relied on the user's report that this is still happening with the current 0.20 fixes rpms. So either the reporter messed up his installation, or something else is happening.

[J.Pilk@…]

syslog: dvb-usb: will use the device's hardware PID filter (table count: 15)

Error messages every two seconds during recording: DVBRec(0) Error: Could not open demux device.

eno: Too many open files (24)

The recordings produced are excellent, as is the EIT program guide.

Explanation received from danielk: many thanks.

I believe this is normal with your device. MythTV doesn't know ahead of time that your card can't filter the number of streams needed, so it opens as many as possible until it gets that error. What happens then is that every couple seconds it closes a pid that it wants to listen to and opens another it wants to listen to, it does this in a round-robin fashion so that it has a relatively up to date view of the metadata in the stream. The fix referred to in the [10946] changeset makes sure that it gives the current audio and video streams priority over other streams, and attempts to always record them.

The error message you are seeing should be suppressed, but doesn't indicate any real error in the recording. The worst that will happen with 24 streams is that channel changing will be a little slow and potentially you won't be able to record MHEG or other interactive television programs. Regular TV and DVB Radio should work fine.

[Janne <janne-mythtv@…>]

1970_silence_dvbrec_ff.diff suppresses the warnings by setting the maximum number of concurrent open pid filters on the first error. It counts the open filters separately since for late packets a PIDInfo is added without a open filter.

Fixes also the round-robin of the low priority (pmt) pids. In the current implemantation only the lower pmt pids are shuffled around since a QMap is iterated in order of its keys.

[danielk]

(In [11719]) Fixes #1970. Silences complaints about PID filtering on hardware with limited pid filtering abilities and shuffles around all the low priority pids when there is limited PID filtering with patch from Janne.

[J.Pilk@…]

Daniel, Janne: Many thanks for your work on this. I now have Axel's build of yesterday (0.20-147), which is updated to 11812, and unfortunately the error messages every two seconds are still there.

Syslog and error messages are still as I reported above. The kernel recognises the device as as dvb-usb: WideView? WT-220U PenType? Receiver (Typhoon/Freecom?).

[Isaac Richards]

Don't confuse the fixes branch with trunk.

[J.Pilk@…]

OK, it seems I was confused. Can I repeat the request that Axel made above on my behalf for consideration of a backport to the fixes branch? Thanks to all concerned.

[J.Pilk@…]

Maybe I'm the only person in the universe using the hardware listed above? I'm still getting the error messages every two seconds on eg UKHistory, although not always on other channels. I'm now running Axel's build 0.21-150_trunk_r12545.fc5.at.i386. The recordings are probably as good as I can expect given that I'm in a fringe reception area, but the constant flow of error messages might obscure others that I would like to know about.

[Janne Grunau]

(In [12572]) merged r11719 to 0.20 fixes

silence warnings about failing PID filters after the maximun number of open filters is reached for hardware pid filtering cards

Closes #1970

[J.Pilk@…]

Now running 0.21-153_trunk_r12782.fc.at.i386 under kernel 2.6.19-1.2299.fc5@i686

2007-02-15 10:59:07.043 DVBRec(0) Error: Could not open demux device.

eno: Too many open files (24)

2007-02-15 10:59:08.735 DVBRec(0) Error: Could not open demux device.

eno: Too many open files (24)

2007-02-15 10:59:10.403 DVBRec(0) Error: Could not open demux device.

eno: Too many open files (24)

2007-02-15 10:59:12.115 DVBRec(0) Error: Could not open demux device.

eno: Too many open files (24)

etc

????

[Janne Grunau]

(In [12800]) Refs #1970. Fix pid filter usage for dvb_usb devices.

Opening the demux device on DVB USB device fails if no further hardware PID filters are availbale. Update the maximal number of pid filters also in this case.

[Janne Grunau]

(In [12801]) Closes #1970. Backports [12800] to 0.20-fixes.

[Janne Grunau]

(In [12803]) Refs #1970. commit the one line change I intended to commit in [12800]