Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] possible workaround found for DVBs-1.3-signalless operation -> testers required



Hallo,

as mentioned before i did some tests with my vdr setup running a Siemens DVB-s 
Rev. 1.3 card (ves1893 frontend) with analogtv-feed.

I might have found a work-around to this problem:

After minutes or maximum some hours av7110_send_fw_cmd-errors appeared and 
later ARM-crashes ...

With the following to mini-diffs the behaviour improved a lot for me:

In DVB-driver (mine is dvb-kernel from cvs) change:

--- ves1x93.c.orig	2004-03-11 18:06:49.000000000 +0100
+++ ves1x93.c	2004-03-19 20:08:23.616250280 +0100
@@ -465,6 +463,7 @@
 
         case FE_READ_SIGNAL_STRENGTH:
 	{
+		ves1x93_init (i2c);
 		u8 signal = ~ves1x93_readreg (i2c, 0x0b);
 		*((u16*) arg) = (signal << 8) | signal;
 		break;

In vdr change:

--- dvbdevice.c.orig	2004-03-19 20:05:17.749506320 +0100
+++ dvbdevice.c	2004-03-19 19:10:17.000000000 +0100
@@ -284,7 +286,7 @@
          DisplaySignalInfo();
         }
         // in the beginning we loop more often to let the CAM connection 
start up fast
-        newSet.TimedWait(mutex, (ciHandler && (time(NULL) - startTime < 
20)) ? 100 : 1000);
+        newSet.TimedWait(mutex, (ciHandler && (time(NULL) - startTime < 
20)) ? 100 : 10000);
         }
   dsyslog("tuner thread ended on device %d (pid=%d)", cardIndex + 1, 
getpid());
 }

Then activate the option "Display signal infors: On Terminal" in setup->DVB.

(eventually you will have to change vdr/config.c to actually use the value 
from setup.conf instead of "0" for this parameter "HardwareSignalInfo" at 
line 602. is this vanilla-vdr or some patch i have applied?)

However - after this the ves1893-chip is intialised every 10 seconds (can 
maybe "on-demand" later).

The result of this manipulations are so far:
-IMHO less ARM-crashes and av7110_send_fw_cmd-errors
-vdr now survives if the ARM-resets: after firmware-reload playback simply 
resumes most of the time

I noticed however, that resetting the playmode is sometimes required, but i 
don't know were to put such code into vdr - any help and ideas appreciated.

As ARM-crashes also appear with setups including a sat-dish - maybe it's also 
a good thing to detect the firmware-reload in vdr, and reset the playmode 
(pmplay->pmfast->pmplay usually helps, experiments required) in such a case 
generally... again: i can't test this alone ;-)

I think the correct algorithm would involve the following:
-detect a firmware reload because of an ARM-crash, reset
-call ioclt(fronted,FE_INIT)
-reset any av7110-states from vdr to reflect current operation mode

The result would be, that the ARM-reset is technically reduced to a short 
drop-out (less than 1 second) only.

Guido


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



Home | Main Index | Thread Index