Hi,
Jeremy Hall wrote:
> My apologies if I seem a bit dense here, but there have been a few threads
> either on vdr or linux-dvb that have my attention--yet I am having a
> little difficulty putting it all together.
>
> There is a thread about fixing for 8vsb tuning that has a patch which sets
> some #defines for (I think) how long you think it will take to tune a
> channel on your system, but I'm not sure I understand what it's trying to
> resolve.
A VDSB can happen when VDR tunes a device to take a recording. If such a
device uses full DiSEqC (see diseqc.conf), it may happen that sending
this message just once won't have an influence the multiswitch in case
this message get's lost or distorted.
That's why my patch repeats the DiSEqC message every 1000 ms until the
reception of a stable signal. Unfortunately, it seems that resending the
DiSEqC message requires to restart tuning, too which can have
influence for example on steerable dishes.
> my situation:
>
> I have a rotor connected to a diseqc switch connected to a skystar budget
> that uses stv0299 as its frontend, but overrides voltage and possibly
> other routines with flexcop_set_* (like flexcop_set_voltage) etc
>
> When I'm trying to align the dish, what is the best recommended way to
> proceed? I remember reading some thread about new tuning modes getting
> checked into the linuxtv-dvb dvb-kernel CVS (now probably v4l-kernel) but
> it's quite hard to align a dish now.
>
> What are the requirements for setting voltage, tone, and other fe events
> from plugins? Older vdr versions seemed to authorize plugins to do this,
> but now newer ones seem to want the sets to occur from within the vdr
> loop, so you have to modify the vdr core code to allow a plugin to trigger
> events from within the main loop (is this thread-safe)
>
> So can somebody take a moment please and describe what happens to vdr in
> the tuning thread? What states can it be in and what is it trying to do? I
> know some on this list would suggest I read through the source, which I am
> capable of doing, but I'm asking somebody who is fluent in this to just
> take about five minutes to write up a pseudocode explanation just to make
> sure we're all on the same page. I think if we had a brief description in
> one message describing bullet points for what everybody's trying to solve
> efficiency would improve.
Vanilla VDR behaves like that:
START
|
v
+---> tsLocked tsIdle <--------+
| | \ | |
| | \ | |
| v v v |
| FE_REINIT cDvbTuner::Set() |
| | / |
| | / |
| v v |
| +-> tsSet |
| | | |
| | v |
| | cDvbTuner::SetFrontend() -+
| | |
| | v
| | tsTuned
| | |
| | v
| +-----+-- event.status & FE_REINIT
| |
| v
+-------+-- event.status & FE_HAS_LOCK
Explanation:
- cDvbTuner::Set() initiates a tuning operation.
- cDvbTuner::SetFrontend() sends the DiSEqC message and asks the device
to tune.
- device events ask for retuning (FE_REINIT) respectively indicated
successful tuning (FE_HAS_LOCK).
> NOTE: it takes about 25 seconds to zoom across the sky, so whatever code
> gets written should understand that.
Hhm, that's why I asked for a report. What happens in your setup with my
patch applied?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
