[vdr] Re: Possible fix for EPG scan ("video data stream broken")

[a.share@t-online.de (Andreas Share)]

> Hi,
>
> while debugging I noticed that when starting a recording while EPG
> scan is active the following piece of code in method
> cDvbDevice::SetChannelDevice prevents starting transfer mode (at
> least on a single card system):
>
>    if (EITScanner.Active()) {
>       StartTransferMode = false;
>       TurnOnLivePIDs = false;
>       }
>

No, this only prevents livepids & transfermode during epgscan. So vdr does
not use pes-pids during scanning, only section filter will be opend.

If you start a record, (EITScanner.Active()) == false.


> I think this causes the recording thread not receiving data for some
> time (20sec ScanTimeout for EITScanner + some time for several
> Channel switches incl. displaying "Channel not available"). This
> amount of time can quite reach the timeout of 30sec in the recording
> thread.

Yes, there is no more data, so vdr stop the recording with the well known
message. And, this is not a vdr only problem (but maybe vdr trigger some
thing). You could easiely check your card if you get an VDSB error....there
are no more interrupts handled, so there is no more data transfered from the
card to userspace. I have had confirmed this is also valid for ff cards!
Before any other error occurs (fw_command errors, arm crashes) the card stop
delivering data!

> As workaround I inserted a call of EITScanner.Activity()  in
> cRecordControls::Start in before SwitchChannel is called.
>
> In method  cEITScanner::Activity I rearranged the assignments for
> currentChannel and lastActivity. So EITScanner::Active immediatly
> returns false.
>
> Furthermore I made a small optimization at the beginning
> cEITScanner::Process for single card setups. This prevents building
> and deleting the scanlist every 20 secs when EPGScanTimeout is not
> reached.
>
> I will have to test this patch over night but up to then comments a
> welcome. This patch contains also the cDvbTuner patch (timeout now
> 300ms) and some debugging messages.
>
> Stefan
>
>
>
>