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.