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?

http://www.vdr-portal.de/board/thread.php?postid=639048 The actual patch is at http://tafe.unkelhaeusser.de/vdr/dvbdevice.c.patch

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

artur