VDSB Video Data Stream Broken

  Hi,

Udo Richter wrote:

>>I've again a problem with the mysterious Errormessage "ERROR: video data
>>stream broken".
>>
>>First of all I try to explain the setup of the friend of mine, who has
>>the Problem...
>>He has one PC with linvdr and VDR version 1.3.34 with 3 Cards: 2x FF
>>cards and 1x LBudget card
> 
> The typical base for the feared VDSB error...
> 
> The most common chain of trouble is this: VDR uses the budget card to do
> EPG scan as long as the second card is idle. Due to unknown reasons the
> frequent channel changes from one transponder to the next suddenly cause
> the budget card driver to hang, and no channel is tunable any more. This
> doesn't cause any error messages, because EPG scan is a low-priority
> task and mostly ignores errors. As soon as the next recording starts,
> this tuning trouble will become more critical, and VDR does an emergency
> exit to reload the DVB driver, that brings the card back to life (for
> most users at least).

To prove this, would you please try the attached patch (it's a 
simplified approach regarding my earlier posts). In DiSEqC setup's it 
repeats the DiSEqC message and retunes, if the tuner doesn't get a lock 
within 1000 ms or after loosing the lock for 1000 ms.

In my setup with just two budget cards and a channels.conf with some 
outdated entries, I get log messages regarding tuning when EPG scan 
comes across such channels.

> Some hints:
> - Upgrade or downgrade driver and/or firmware
> - IRQ's may be part of the problem, so try to give an own irq to the
> budget card
> - Disabling EPG scan helps
> 
> The reasons behind VDSB are very complex, and not all aspects are known.
> Some people suffer massively from it, others not at all, with identical
> setups. Solutions that work for one case may not work for other cases,
> thats making it difficult to fix it. Do some searching on the list and
> at vdrportal to get more info.

Bye.
  

Hi Reinhard,

Reinhard Nissl schrieb:
> To prove this, would you please try the attached patch (it's a 
> simplified approach regarding my earlier posts). In DiSEqC setup's it 
> repeats the DiSEqC message and retunes, if the tuner doesn't get a lock 
> within 1000 ms or after loosing the lock for 1000 ms.

I applied this patch on Dec. 30th. While I had UPT, VDSB and No-lock 
errors at least once a day before that, I had none after that.

It works. At least for me.

Martin
  

Martin Schoenbeck wrote:
> Hi Reinhard,
> 
> Reinhard Nissl schrieb:
> 
>> To prove this, would you please try the attached patch (it's a 
>> simplified approach regarding my earlier posts). In DiSEqC setup's it 
>> repeats the DiSEqC message and retunes, if the tuner doesn't get a 
>> lock within 1000 ms or after loosing the lock for 1000 ms.
> 
> 
> I applied this patch on Dec. 30th. While I had UPT, VDSB and No-lock 
> errors at least once a day before that, I had none after that.
> 
> It works. At least for me.
> 
> Martin

Can you please test with the modified patch I have posted
here today? That's the version that will go into VDR 1.3.38.

Klaus
  

Hi Klaus,

Klaus Schmidinger schrieb:

> Can you please test with the modified patch I have posted
> here today? That's the version that will go into VDR 1.3.38.

I saw it after posting about Reinhard's patch and activated it yesterday 
night. Since then I have a huge amount of
Jan  4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock
Jan  4 04:17:55 saturn vdr[8293]: frontend 1 regained lock

messages. About every 5 to 10 messages the same appears with frontend 2. 
  I had no restarts up to now, even after starting a recording, which 
would have induced a restart for sure before.

I must admit, that I installed Reinhard's patch together with 1.3.37, so 
  theoretically it's possible, that the restarts are cured by something 
else, changed in 1.3.37.

Martin
  

An addition:

Martin Schoenbeck schrieb:

> I saw it after posting about Reinhard's patch and activated it yesterday 
> night. Since then I have a huge amount of
> Jan  4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock
> Jan  4 04:17:55 saturn vdr[8293]: frontend 1 regained lock
> 
> messages. About every 5 to 10 messages the same appears with frontend 2. 
>  I had no restarts up to now, even after starting a recording, which 
> would have induced a restart for sure before.

Primary device is 1, there are three devices.

And I just found a restart on yesterday evening, after posting, that 
there were none and before installing your patch:

Jan  3 20:10:02 saturn vdr[4496]: ERROR: frontend 1 timed out while 
tuning - re-tuning
Jan  3 20:10:05 saturn last message repeated 3 times
Jan  3 20:10:06 saturn vdr[4403]: ERROR: device 2 has no lock, can't 
attach receiver!
Jan  3 20:10:06 saturn vdr[4403]: initiating emergency exit

Martin
  

And a second addition:

Martin Schoenbeck schrieb:
> Jan  3 20:10:02 saturn vdr[4496]: ERROR: frontend 1 timed out while 
> tuning - re-tuning
> Jan  3 20:10:05 saturn last message repeated 3 times
> Jan  3 20:10:06 saturn vdr[4403]: ERROR: device 2 has no lock, can't 
> attach receiver!
> Jan  3 20:10:06 saturn vdr[4403]: initiating emergency exit

I activated the 'WAIT_FOR_TUNER_LOCK' and also inserted an immediate 
emergency restart, as soon as there was no lock, because in former 
versions, this never was cured without driver reload. I now removed the 
emergency restart, to see, whether it is perhaps cured by the patch.

Martin
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Can you please test with the modified patch I have posted
>> here today? That's the version that will go into VDR 1.3.38.
> 
> 
> I saw it after posting about Reinhard's patch and activated it yesterday 
> night. Since then I have a huge amount of
> Jan  4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock
> Jan  4 04:17:55 saturn vdr[8293]: frontend 1 regained lock
> 
> messages. About every 5 to 10 messages the same appears with frontend 2. 
>  I had no restarts up to now, even after starting a recording, which 
> would have induced a restart for sure before.
> 
> I must admit, that I installed Reinhard's patch together with 1.3.37, so 
>  theoretically it's possible, that the restarts are cured by something 
> else, changed in 1.3.37.
> 
> Martin

Please test the new patch I've posted under
"VDR-1.3.37: retuning -- possibly a fix for VDSB".

Klaus
  

Martin Schoenbeck <ms.usenet.nospam@schoenbeck.de> wrote:
> Jan  4 04:17:55 saturn vdr[8293]: ERROR: frontend 1 lost lock
> Jan  4 04:17:55 saturn vdr[8293]: frontend 1 regained lock

I had similar problems until I re-made my cables (loose F plugs) and
reattached them to the receiver cards.
  

Hi Klaus,

Klaus Schmidinger schrieb:
> Please test the new patch I've posted under
> "VDR-1.3.37: retuning -- possibly a fix for VDSB".

Now it only shows up numerous

Jan  4 22:27:25 saturn vdr[10765]: ERROR: frontend 2 timed out while tuning

with all three frontends. But no restarts.

Yes, I used the vdr.1.3.37-tunertimeout4.diff

Martin
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Please test the new patch I've posted under
>> "VDR-1.3.37: retuning -- possibly a fix for VDSB".
> 
> 
> Now it only shows up numerous
> 
> Jan  4 22:27:25 saturn vdr[10765]: ERROR: frontend 2 timed out while tuning
> 
> with all three frontends. But no restarts.

Strange - I haven't had a single error message since today afternoon
with the latest version of the patch. And I did some heavy channel hopping
with transfer modes, recordings and replaying.

> Yes, I used the vdr.1.3.37-tunertimeout4.diff

What kind of devices do you have (DVB-S, -C or -T)?

Klaus
  

Hi Klaus,

Klaus Schmidinger schrieb:

> Strange - I haven't had a single error message since today afternoon
> with the latest version of the patch. And I did some heavy channel hopping
> with transfer modes, recordings and replaying.

It may be interesting, that any time only two frontends are reported. 
Normally frontend 1 and 2, also 1 and 2 if recording. As soon as a 
replay is started, it moves over to 0 and 2. If two recordings are 
running, the messages stop.

Primary DVB is 1.

>> Yes, I used the vdr.1.3.37-tunertimeout4.diff
> 
> 
> What kind of devices do you have (DVB-S, -C or -T)?

Three dvb-s card, one of them a budget card (IIRC).

Dec 20 11:05:36 saturn kernel: DVB: registering new adapter 
(Siemens/Technotrend/Hauppauge PCI rev1.3).
Dec 20 11:05:36 saturn kernel: DVB: registering frontend 0:0 (Grundig 
29504-491, (TDA8083 based))...

Dec 20 11:05:38 saturn kernel: DVB: registering new adapter 
(Technotrend/Hauppauge PCI rev2.1).
Dec 20 11:05:38 saturn kernel: probe_tuner: try to attach to 
Technotrend/Hauppauge PCI rev2.1
Dec 20 11:05:39 saturn kernel: 
/usr/local/src/linuxtv-dvb-1.1.1/build-2.6/stv0299.c: setup for tuner 
BSRU6, TDQB-S00x
Dec 20 11:05:39 saturn kernel: DVB: registering frontend 1:0 
(STV0299/TSA5059/SL1935 based)...

Dec 20 11:05:41 saturn kernel: DVB: registering new adapter 
(TT-Budget/WinTV-NOVA-CI PCI).
Dec 20 11:05:41 saturn kernel: probe_tuner: try to attach to 
TT-Budget/WinTV-NOVA-CI PCI
Dec 20 11:05:41 saturn kernel: 
/usr/local/src/linuxtv-dvb-1.1.1/build-2.6/stv0299.c: setup for tuner 
SU1278 (TSA5059 synth) on TechnoTrend hardware
Dec 20 11:05:41 saturn kernel: DVB: registering frontend 2:0 
(STV0299/TSA5059/SL1935 based)...

Martin
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Strange - I haven't had a single error message since today afternoon
>> with the latest version of the patch. And I did some heavy channel 
>> hopping
>> with transfer modes, recordings and replaying.
> 
> 
> It may be interesting, that any time only two frontends are reported. 
> Normally frontend 1 and 2, also 1 and 2 if recording. As soon as a 
> replay is started, it moves over to 0 and 2. If two recordings are 
> running, the messages stop.
> 
> Primary DVB is 1.
> 
>>> Yes, I used the vdr.1.3.37-tunertimeout4.diff

Are you absolutely, postitively, sure about that?

I'm just asking because I can't see where this problem
might come from...

Is there a particular sequence of actions necessary to
reproduce this?

Klaus
  

Hi Klaus,

Klaus Schmidinger schrieb:
> Martin Schoenbeck wrote:

>>>> Yes, I used the vdr.1.3.37-tunertimeout4.diff
> 
> 
> Are you absolutely, postitively, sure about that?

Absolutely. Positively. I doublechecked, that I really used that patch, 
before sending my last posting and now also checked, that it made it 
into dvbdevice.c and that dvbdevice.o and vdr were made after that. ;-)

> I'm just asking because I can't see where this problem
> might come from...
> 
> Is there a particular sequence of actions necessary to
> reproduce this?

May it possibly connected with my earlier mentioned activating of 
WAIT_FOR_TUNER_LOCK? Do I have to remove it now?

Martin
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Martin Schoenbeck wrote:
> 
> 
>>>>> Yes, I used the vdr.1.3.37-tunertimeout4.diff
>>
>>
>>
>> Are you absolutely, postitively, sure about that?
> 
> 
> Absolutely. Positively. I doublechecked, that I really used that patch, 
> before sending my last posting and now also checked, that it made it 
> into dvbdevice.c and that dvbdevice.o and vdr were made after that. ;-)
> 
>> I'm just asking because I can't see where this problem
>> might come from...
>>
>> Is there a particular sequence of actions necessary to
>> reproduce this?
> 
> 
> May it possibly connected with my earlier mentioned activating of 
> WAIT_FOR_TUNER_LOCK? Do I have to remove it now?
> 
> Martin

Since this is not set by default (and so I don't have it set here)
this might be worth testing.

Klaus
  

Hi Klaus,

Klaus Schmidinger schrieb:
> Since this is not set by default (and so I don't have it set here)
> this might be worth testing.

Ok, I did it. But _you_ speak to my wife, if a recording of zero length 
files is created again. ;-)

Martin
  

me again,

Martin Schoenbeck schrieb:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Since this is not set by default (and so I don't have it set here)
>> this might be worth testing.
> 
> 
> Ok, I did it. But _you_ speak to my wife, if a recording of zero length 
> files is created again. ;-)

It didn't change anything. At least the timeout reports remain.

Martin
  

Martin Schoenbeck wrote:
> me again,
> 
> Martin Schoenbeck schrieb:
> 
>> Hi Klaus,
>>
>> Klaus Schmidinger schrieb:
>>
>>> Since this is not set by default (and so I don't have it set here)
>>> this might be worth testing.
>>
>>
>>
>> Ok, I did it. But _you_ speak to my wife, if a recording of zero 
>> length files is created again. ;-)
> 
> 
> It didn't change anything. At least the timeout reports remain.
> 
> Martin

Please replace the cDvbTuner::Action() function with the following
version (add the lines marked with XXX), run VDR, and when it logs
timeouts please send me the log excerpt.

Klaus


void cDvbTuner::Action(void)
{
   cTimeMs Timer;
   bool LostLock = false;
   fe_status_t Status = (fe_status_t)0;
   while (Running()) {
         fe_status_t NewStatus;
         if (GetFrontendStatus(NewStatus, 10))
            Status = NewStatus;
         cMutexLock MutexLock(&mutex);
         switch (tunerStatus) {
           case tsIdle:
                break;
           case tsSet:
                dsyslog("TUNER %d: tsSet", cardIndex);//XXX
                tunerStatus = SetFrontend() ? tsTuned : tsIdle;
                Timer.Set(tuneTimeout);
                continue;
           case tsTuned:
                dsyslog("TUNER %d: tsTuned", cardIndex);//XXX
                if (Timer.TimedOut()) {
                   dsyslog("TUNER %d: tsTuned - timeout", cardIndex);//XXX
                   tunerStatus = tsSet;
                   diseqcCommands = NULL;
                   if (time(NULL) - lastTimeoutReport > 60) { // let's not get too many of these
                      esyslog("ERROR: frontend %d timed out while tuning", cardIndex);
                      lastTimeoutReport = time(NULL);
                      }
                   continue;
                   }
           case tsLocked:
                if (Status & FE_REINIT) {
                   tunerStatus = tsSet;
                   diseqcCommands = NULL;
                   esyslog("ERROR: frontend %d was reinitialized", cardIndex);
                   lastTimeoutReport = 0;
                   continue;
                   }
                else if (Status & FE_HAS_LOCK) {
                   if (tunerStatus != tsLocked) dsyslog("TUNER %d: tsLocked", cardIndex);//XXX
                   if (LostLock) {
                      esyslog("frontend %d regained lock", cardIndex);
                      LostLock = false;
                      }
                   tunerStatus = tsLocked;
                   locked.Broadcast();
                   lastTimeoutReport = 0;
                   }
                else if (tunerStatus == tsLocked) {
                   LostLock = true;
                   esyslog("ERROR: frontend %d lost lock", cardIndex);
                   tunerStatus = tsTuned;
                   Timer.Set(lockTimeout);
                   lastTimeoutReport = 0;
                   continue;
                   }
           }

         if (ciHandler)
            ciHandler->Process();
         if (tunerStatus != tsTuned)
            newSet.TimedWait(mutex, 1000);
         }
}
  

Hi Klaus,

Klaus Schmidinger schrieb:
> Please replace the cDvbTuner::Action() function with the following
> version (add the lines marked with XXX), run VDR, and when it logs
> timeouts please send me the log excerpt.

Jan  5 23:09:28 saturn vdr[14257]: TUNER 1: tsSet
Jan  5 23:09:28 saturn vdr[14260]: TUNER 2: tsSet
Jan  5 23:09:28 saturn vdr[14257]: TUNER 1: tsTuned
Jan  5 23:09:29 saturn last message repeated 15 times
Jan  5 23:09:29 saturn vdr[14257]: TUNER 1: tsLocked
Jan  5 23:09:29 saturn vdr[14260]: TUNER 2: tsTuned
Jan  5 23:09:31 saturn last message repeated 180 times
Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned - timeout
Jan  5 23:09:31 saturn vdr[14260]: ERROR: frontend 2 timed out while tuning
Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsSet
Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned
Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsLocked
Jan  5 23:09:49 saturn vdr[14257]: TUNER 1: tsSet
Jan  5 23:09:49 saturn vdr[14260]: TUNER 2: tsSet
Jan  5 23:09:49 saturn vdr[14260]: TUNER 2: tsTuned
Jan  5 23:09:49 saturn vdr[14260]: TUNER 2: tsLocked
Jan  5 23:09:49 saturn vdr[14257]: TUNER 1: tsTuned
Jan  5 23:09:50 saturn last message repeated 16 times
Jan  5 23:09:50 saturn vdr[14257]: TUNER 1: tsLocked
Jan  5 23:10:10 saturn vdr[14257]: TUNER 1: tsSet
Jan  5 23:10:10 saturn vdr[14260]: TUNER 2: tsSet
Jan  5 23:10:10 saturn vdr[14260]: TUNER 2: tsTuned
Jan  5 23:10:10 saturn vdr[14260]: TUNER 2: tsLocked
Jan  5 23:10:10 saturn vdr[14257]: TUNER 1: tsTuned
Jan  5 23:10:10 saturn last message repeated 15 times
Jan  5 23:10:10 saturn vdr[14257]: TUNER 1: tsLocked

is that enough, or do you want more logging?

Martin
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Please replace the cDvbTuner::Action() function with the following
>> version (add the lines marked with XXX), run VDR, and when it logs
>> timeouts please send me the log excerpt.
> 
> 
> Jan  5 23:09:28 saturn vdr[14257]: TUNER 1: tsSet
> Jan  5 23:09:28 saturn vdr[14260]: TUNER 2: tsSet
> Jan  5 23:09:28 saturn vdr[14257]: TUNER 1: tsTuned
> Jan  5 23:09:29 saturn last message repeated 15 times
> Jan  5 23:09:29 saturn vdr[14257]: TUNER 1: tsLocked
> Jan  5 23:09:29 saturn vdr[14260]: TUNER 2: tsTuned
> Jan  5 23:09:31 saturn last message repeated 180 times
> Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned - timeout
> Jan  5 23:09:31 saturn vdr[14260]: ERROR: frontend 2 timed out while tuning
> Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsSet
> Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsTuned
> Jan  5 23:09:31 saturn vdr[14260]: TUNER 2: tsLocked
> Jan  5 23:09:49 saturn vdr[14257]: TUNER 1: tsSet
> Jan  5 23:09:49 saturn vdr[14260]: TUNER 2: tsSet
> Jan  5 23:09:49 saturn vdr[14260]: TUNER 2: tsTuned
> Jan  5 23:09:49 saturn vdr[14260]: TUNER 2: tsLocked
> Jan  5 23:09:49 saturn vdr[14257]: TUNER 1: tsTuned
> Jan  5 23:09:50 saturn last message repeated 16 times
> Jan  5 23:09:50 saturn vdr[14257]: TUNER 1: tsLocked
> Jan  5 23:10:10 saturn vdr[14257]: TUNER 1: tsSet
> Jan  5 23:10:10 saturn vdr[14260]: TUNER 2: tsSet
> Jan  5 23:10:10 saturn vdr[14260]: TUNER 2: tsTuned
> Jan  5 23:10:10 saturn vdr[14260]: TUNER 2: tsLocked
> Jan  5 23:10:10 saturn vdr[14257]: TUNER 1: tsTuned
> Jan  5 23:10:10 saturn last message repeated 15 times
> Jan  5 23:10:10 saturn vdr[14257]: TUNER 1: tsLocked
> 
> is that enough, or do you want more logging?
> 
> Martin

Have you edited this log?
I'm missing the "switching to channel ..." messages.
How do you actually set both devices at the same time?

Anyway, apparently there just is no lock within the two seconds
tuning timeout. Please try setting DVBS_TUNE_TIMEOUT to a higher value.
Let me know what's the smallest value that just doesn't give
you the timeout messages any more.

Klaus
  

Hi Klaus,

Klaus Schmidinger schrieb:

> Have you edited this log?
> I'm missing the "switching to channel ..." messages.
> How do you actually set both devices at the same time?

Nobody is switching channels then. Perhaps the EPG-Scan is running, but 
AFAIK not on two cards. We see and hear under certain conditions (I 
assume, it happens, when then retuning is on the primary device) sort of 
glitches any several seconds. But these glitches are some milliseconds, 
not two seconds.

It seems to be retuning just for fun. ;-)

> Anyway, apparently there just is no lock within the two seconds
> tuning timeout. Please try setting DVBS_TUNE_TIMEOUT to a higher value.
> Let me know what's the smallest value that just doesn't give
> you the timeout messages any more.

I took 4 seconds and will report.

Martin
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Have you edited this log?
>> I'm missing the "switching to channel ..." messages.
>> How do you actually set both devices at the same time?
> 
> 
> Nobody is switching channels then. Perhaps the EPG-Scan is running, but 

Of course, that's what it is - I should have seen that by the
20 seconds interval.

> AFAIK not on two cards. We see and hear under certain conditions (I 
> assume, it happens, when then retuning is on the primary device) sort of 
> glitches any several seconds. But these glitches are some milliseconds, 
> not two seconds.

Is that a new effect, caused by the tuner timeout patch?
If so, was it also there with Reinhard's original patch?

> It seems to be retuning just for fun. ;-)
> 
>> Anyway, apparently there just is no lock within the two seconds
>> tuning timeout. Please try setting DVBS_TUNE_TIMEOUT to a higher value.
>> Let me know what's the smallest value that just doesn't give
>> you the timeout messages any more.
> 
> 
> I took 4 seconds and will report.

Ok.

Klaus
  

Martin Schoenbeck wrote:
> Hi Klaus,
> 
> Klaus Schmidinger schrieb:
> 
>> Have you edited this log?
>> I'm missing the "switching to channel ..." messages.
>> How do you actually set both devices at the same time?
> 
> 
> Nobody is switching channels then. Perhaps the EPG-Scan is running, but 

I just realized that I had turned off the EPG scan here for
some tests and hadn't turned it on again.

I have now turned it on and get the timeouts, too, once
the EPG scan kicks in.

Maybe these are transponders that (currently) don't broadcast.
I'll check this tomorrow.

Klaus
  

Klaus Schmidinger wrote:
>> Nobody is switching channels then. Perhaps the EPG-Scan is running, but 
> 
> Of course, that's what it is - I should have seen that by the
> 20 seconds interval.

I've also tested the patch, and I'm getting lost/regained lock and timed
out errors roughly every half hour for about 1min, unless a recording
blocks the second device. Has been that way since Reinhard's first
patch, however my second card has a known issue with low-band transponders.

Cheers,

Udo
  

Hi Klaus,

Klaus Schmidinger schrieb:

> Of course, that's what it is - I should have seen that by the
> 20 seconds interval.

Ok, so the timeouts are OK, right?

>> AFAIK not on two cards. We see and hear under certain conditions (I 
>> assume, it happens, when then retuning is on the primary device) sort 
>> of glitches any several seconds. But these glitches are some 
>> milliseconds, not two seconds.
> 
> Is that a new effect, caused by the tuner timeout patch?
> If so, was it also there with Reinhard's original patch?

I didn't notice it with Reinhard's patch, but I'm not sure about that. I 
noticed a short distortion this morning at a time, where tuner 1 and 
tuner 2 announced timeouts, but AFAIK the primaryDVB 1 uses tuner 0, 
isn't it? And there were no entries at all with tuner 0 until we started 
a recording.

>> I took 4 seconds and will report.

> Ok.

The timeouts didn't go, but I assume, that's normal, given the EPG scan 
scanning. Is the EPG scan running around the clock, if there is a free 
device other than the primary device?

Martin