Richard F wrote:
> Teemu,
> I had a similar problem with budget Freecom / WT-220U USB stick tuners.
> I usually had to swap multiplex/transponder to get them to re-tune reliably.
> I observed that if they lost tuning, vdr made them re-try (which I saw in the 
> log)
> but eventually would bomb out if it couldn't tune, which is maybe what you're 
> seeing?
> Originally I logged it as a DVB driver bug, but the maintainer said it was an 
> application bug.
> I found the following, which requires you to patch/rebuild vdr from source.
> Basically it just adds a small delay to the tuning process, and it works 100% 
> for me.
> I had to do this on 1.4.7 and carried it over in 1.6.0 also - so no, vanilla 
> 1.6 won't help you.
> It would be good if something equivalent was in vanilla VDR but I suppose it 
> slows 
> some systems by a fraction of a second when tuning.  
> Perhaps a  "budget card" option?
> The actual patch is at

If the .1s delay helps it's probably some kind of race, and if restarting
the app (ie close/open/tune sequence) does not make the device work it is
clearly a driver bug. Adding random delays to apps in order to work around
driver bugs is not the right solution.

Fixing the driver would be, but if that's not an option, you could add the
.1s delay to the open-demux path of the driver; that way only users of that
driver would suffer until it's fixed properly.

If the driver does recover after some time, you could do something like this
instead of the above patch:

 int cDvbDevice::OpenFilter(u_short Pid, u_char Tid, u_char Mask)
   const char *FileName = *cDvbName(DEV_DVB_DEMUX, CardIndex());
   int f = open(FileName, O_RDWR | O_NONBLOCK);
+  if (f==-1) {
+     usleep(100000);
+     f = open(FileName, O_RDWR | O_NONBLOCK);
+  }
   if (f >= 0) {
      dmx_sct_filter_params sctFilterParams;

to limit the cost of the delays somewhat, but it won't work if the first
open call messes up the driver...


vdr mailing list

Reply via email to