[vdr] Re: V1.1.19: Problem with second DVB-S card ?

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Wiljo Heinen wrote:
> 
> Hi !
> 
> Sorry for the following stupid Q (or statement of observation). I've been
> lurking here the past weeks - but now I'll have to ask this.
> 
> Setup is with two DVB-S. One is Rev. 1.3, the other 2.1. The "primary" is
> the rev. 1.3 card.
> 
> I decided to give it a try and installed vdr 1.1.19 yesterday. But I do have
> a problem with vdr accessing the second card. To me it looks like it has
> something to do with "retuning" a channel.
> 
> With 1.0.4 the behaviour was:
> 
> -------- log with vdr 1.0.4: ---------------
> Dec 10 21:23:58 quark vdr[1065]: timer 65 start
> Dec 10 21:23:58 quark vdr[1065]: switching to channel 4
> Dec 10 21:23:58 quark vdr[1065]: ERROR: channel 4 not sync'ed on DVB card 2!
> Dec 10 21:23:58 quark vdr[1065]: retrying
> Dec 10 21:23:58 quark vdr[1065]: Title: 'Quarks & Co' Subtitle: 'Wunderdroge
> Tee
> '
> Dec 10 21:23:58 quark vdr[1065]: record
> /video0/Quarks_&_Co/2002-12-10.20:56.99.
> 99.rec
> -------------------------------------------
> ... and from here everything goes fine.
> 
> Which implies to me that vdr first "had its problems" with the channel on
> the second card. "Retried" (retuned ???) and then everything (including the
> recording ....) went fine.
> 
> Unfortunately (for me....) the behaviour of 1.1.19 is different:
> 
> ---------- log from vdr 1.1.19 ---------------
> Dec 10 21:15:43 quark vdr[2580]: recording thread started (pid=2580)
> Dec 10 21:15:43 quark vdr[2581]: receiver thread started on device 2
> (pid=2581)
> Dec 10 21:15:44 quark vdr[2571]: max. latency time 1 seconds
> Dec 10 21:16:14 quark vdr[2581]: ERROR: video data stream broken on device 2
> Dec 10 21:16:14 quark vdr[2581]: initiating emergency exit
> Dec 10 21:16:14 quark vdr[2571]: emergency exit requested - shutting down
> ---------------------------------------------
> 
> Again - there are these problems with the second card. But this time vdr
> does not "retry" anything (at least it does not tell me) but instead
> initiates an "emergency exit". Which is too bad for the recording, as vdr
> will exhibit the same behaviour on every subsequent start (from runvdr).
> 
> NOW: Of course, reading the list, the usual recommendations such as "swap
> the cards" etc. could be applied. And it may be the IRQ or whatever... BUT:
> to me it looks as if the behaviour of 1.0.4 vs. 1.1.19 is significantly
> different, to warrant a look into the sources ?
> 
> Unless - of course - I am overlooking something here, which might very well
> be the case...

Looks like your second card always need to be tuned _twice_. Version 1.0.4
did this, but version 1.1.19 only tunes _once_ and assumes that this is
sufficient (which actually it should be).

Please try the following change to dvbdevice.c, cDvbTuner::Action():

--- dvbdevice.c 2002/12/07 14:50:46     1.38
+++ dvbdevice.c 2002/12/10 22:13:24
@@ -235,8 +235,10 @@
   active = true;
   while (active) {
         cMutexLock MutexLock(&mutex);
-        if (tunerStatus == tsSet)
+        if (tunerStatus == tsSet) {
+           SetFrontend();
            tunerStatus = SetFrontend() ? tsTuned : tsIdle;
+           }
         if (tunerStatus == tsTuned) {
            fe_status_t status = fe_status_t(0);
            CHECK(ioctl(fd_frontend, FE_READ_STATUS, &status));

This will simply always call SetFrontend() twice. Let's see if this helps.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.