Modify

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#1970 closed patch (fixed)

dvbrecorder: limit number of open pid filters

Reported by: Janne <janne-mythtv@…> Owned by: janne
Priority: minor Milestone: 0.20
Component: dvb Version: head
Severity: medium Keywords:
Cc: Axel.Thimm@… Ticket locked: no

Description

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)

Attachments (6)

dvbrecorder_save_pidfilters.diff (829 bytes) - added by Janne <janne-mythtv@…> 11 years ago.
dvbrecorder_save_pidfilters.2.diff (3.9 KB) - added by Janne <janne-mythtv@…> 11 years ago.
first round-robin implementation, something like HasEITPIDChanges and PMT tracking in MPEGStremData would be a better approach
dvbrecorder_save_pidfilters.3.diff (7.6 KB) - added by Janne <janne-mythtv@…> 11 years ago.
final version
dvbrecorder_save_pidfilters.4.diff (8.0 KB) - added by Janne <janne-mythtv@…> 11 years ago.
1970-fix-pmt-change-bug.patch (3.4 KB) - added by danielk 11 years ago.
Potential fix
1970_silence_dvbrec_ff.diff (6.6 KB) - added by Janne <janne-mythtv@…> 11 years ago.

Download all attachments as: .zip

Change History (32)

Changed 11 years ago by Janne <janne-mythtv@…>

comment:1 Changed 11 years ago by anonymous

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Changed 11 years ago by Janne <janne-mythtv@…>

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

Changed 11 years ago by Janne <janne-mythtv@…>

final version

comment:2 Changed 11 years ago by Janne <janne-mythtv@…>

  • Component changed from mythtv to dvb
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version set to head

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.

comment:3 Changed 11 years ago by stuarta

  • Milestone set to 0.21
  • Owner changed from ijr to danielk
  • Status changed from reopened to new

comment:4 Changed 11 years ago by danielk

  • Milestone changed from 0.21 to 0.20

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

comment:5 Changed 11 years ago by 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.

Changed 11 years ago by Janne <janne-mythtv@…>

comment:6 Changed 11 years ago by Janne <janne-mythtv@…>

  • Type changed from defect to patch

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

comment:7 Changed 11 years ago by danielk

  • Resolution set to fixed
  • Status changed from new to closed

(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.

comment:8 Changed 11 years ago by danielk

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

comment:9 Changed 11 years ago by danielk

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

Changed 11 years ago by danielk

Potential fix

comment:10 Changed 11 years ago by danielk

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:11 Changed 11 years ago by Axel.Thimm@…

  • Cc Axel.Thimm@… added

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!

comment:12 Changed 11 years ago by anonymous

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

comment:13 Changed 11 years ago by 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.

comment:14 Changed 11 years ago by 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.

Changed 11 years ago by Janne <janne-mythtv@…>

comment:15 Changed 11 years ago by Janne <janne-mythtv@…>

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:16 Changed 11 years ago by danielk

  • Resolution set to fixed
  • Status changed from reopened to closed

(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.

comment:17 Changed 11 years ago by J.Pilk@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

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?).

comment:18 Changed 11 years ago by ijr

  • Resolution set to fixed
  • Status changed from reopened to closed

Don't confuse the fixes branch with trunk.

comment:19 Changed 11 years ago by 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.

comment:20 Changed 11 years ago by J.Pilk@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:21 Changed 11 years ago by danielk

  • Owner changed from danielk to janne
  • Status changed from reopened to new

comment:22 Changed 11 years ago by janne

  • Resolution set to fixed
  • Status changed from new to closed

(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

comment:23 Changed 11 years ago by J.Pilk@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

????

comment:24 Changed 11 years ago by janne

(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.

comment:25 Changed 11 years ago by janne

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:26 Changed 11 years ago by janne

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

Add Comment

Modify Ticket

Action
as closed The owner will remain janne.
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.