En/na Malcolm Caldwell ha escrit:

Hello,

I get the feeling that 1.4 might be getting close - so I though I should speak up now.

I have a request: find a way to fix transfer mode while using a motorised dish.

I have a dxr3 based system and a motorized dish. The problem is vdr only waits a few seconds (TUNER_LOCK_TIMEOUT set in device.c) before it reports "ERROR: device %d has no lock" and gives up.

This makes it fairly painful. I have to change channel, wait for the dish to move and then go "menu->channels->OK" to re-tune the current channel.

My "Fix" is not to return false after the timeout. This causes vdr to

My fix is not to wait at all :-) (unfortunately this breaks the ttxsubs plugin for recordings)

try to set up the filters anyway, and things work fine. When the dish moves the channels just starts to work fine. (If I am not wrong, vdr used to have no timeout here but some cards did not like you to set filters when there was no lock... ?) Setting the timeout to a large value is not an option as vdr is unresponsive during this period, making channel surfing 'stick' at various places where channels are un-available. I cannot think of a fix that preserves the "don't set filters without a lock" behaviour without using another thread.

The other problem with vdr and motorised dishes is due to the timeout for recordings. If vdr receives no data for MAXBROKENTIMEOUT defined in recording.c it does an emergency restart. Now on the plus side, by the time vdr restarts my dish has (so far) always moved to the correct position! However, I must say it is hard to explain to my wife why the recording we just happened to be watching at the time stopped midway through...

Here my fix is to wait ten time the MAXBROKENTIMEOUT but only for the first packet.

Maybe some of this could be fixed by to rotor plugin, however the rotor plugin should not be needed in this setup (I just define things in diseqc.conf).

There are other problems, like the channel autoupdate picking data from the wrong satellite. I don't think you can solve that without a plugin. In fact Klaus promised to check the plugins in the tuning thread to see if a channel can be actually tuned to and it is ready to be tuned. If he manages do to it and at the same time doesn't block vdr responsiveness to the remote I think it would be the best solution. However, Klaus kindly reminded us that his day has only 24 hours (bad, bad Klaus ;-), so you'll just have to be patient.

Bye

Hi,

Malcolm Caldwell wrote:

I have a dxr3 based system and a motorized dish. The problem is vdr only waits a few seconds (TUNER_LOCK_TIMEOUT set in device.c) before it reports "ERROR: device %d has no lock" and gives up.

I get the same error with both softdevice and dxr3. The default 5s TUNER_LOCK_TIMEOUT is also unfortunately sometimes too short for a terrestial tuner (Hauppauge Nova-T) lock. There could be something in 2.6.x DVB as well which has increased lock time from 2.4.x. I have increased the timeout in vdr to 8s which seems to fix it.

Maybe some of this could be fixed by to rotor plugin, however the rotor plugin should not be needed in this setup (I just define things in diseqc.conf). The better fix IMHO would be in vdr itself. I think a parameter that says "maximum timeout when changing source" might help the recording problem. Not so sure for the transfer mode problem.

I agree. For diseqc motors it could be based on motor speed. Correct lock cannot be done before a turn degree dependent minimum time. It could happen that e.g. when moving from 13.0E to 28.2E vdr could temporarily lock to 19.2E and receive whatever channel updates and EPG data.

There is one more thing which could be fixed for motorized dishes. The EIT scan moves the dish all the time wildly. Some motors are too noisy (like mine) and may wear mechanically for this. I have added this ugly hack to eitscan.c to limit scanning to afternoon/evening hours.

...

void cEITScanner::Process(void) { struct tm now_tm; int enablescan;

if ((Setup.EPGScanTimeout || !lastActivity) && Channels.MaxNumber() > 1) { // !lastActivity means a scan was forced time_t now = time(NULL); now_tm = *localtime( &now ); if ((now_tm.tm_hour >= 21) || (now_tm.tm_hour <= 14)) enablescan = 0; else enablescan = 1;

if ( (now - lastScan > ScanTimeout) && (now - lastActivity > ActivityTimeout) && (enablescan > 0) ) {

...

A decent solution for limiting optionally EIT scan should be DVB adapter specific and the time for allowing scan should be configurable from vdr setup.

BR, Seppo

On Tue, 2005-08-09 at 15:00 +0930, Malcolm Caldwell wrote:

On Mon, 2005-08-08 at 10:56 +0200, Luca Olivetti wrote:

...

En/na Malcolm Caldwell ha escrit:

...

Hello,

I get the feeling that 1.4 might be getting close - so I though I should speak up now.

I have a request: find a way to fix transfer mode while using a motorised dish.

I have a dxr3 based system and a motorized dish. The problem is vdr only waits a few seconds (TUNER_LOCK_TIMEOUT set in device.c) before it reports "ERROR: device %d has no lock" and gives up.

This makes it fairly painful. I have to change channel, wait for the dish to move and then go "menu->channels->OK" to re-tune the current channel.

My "Fix" is not to return false after the timeout. This causes vdr to

My fix is not to wait at all :-)

I tried that as well but I think this caused problems with my Terrestrial card.

...

(unfortunately this breaks the ttxsubs plugin for recordings)

...

try to set up the filters anyway, and things work fine. When the dish moves the channels just starts to work fine. (If I am not wrong, vdr used to have no timeout here but some cards did not like you to set filters when there was no lock... ?) Setting the timeout to a large value is not an option as vdr is unresponsive during this period, making channel surfing 'stick' at various places where channels are un-available. I cannot think of a fix that preserves the "don't set filters without a lock" behaviour without using another thread.

The other problem with vdr and motorised dishes is due to the timeout for recordings. If vdr receives no data for MAXBROKENTIMEOUT defined in recording.c it does an emergency restart. Now on the plus side, by the time vdr restarts my dish has (so far) always moved to the correct position! However, I must say it is hard to explain to my wife why the recording we just happened to be watching at the time stopped midway through...

Here my fix is to wait ten time the MAXBROKENTIMEOUT but only for the first packet.

OK, this may be a good compromise.

...

...

Maybe some of this could be fixed by to rotor plugin, however the rotor plugin should not be needed in this setup (I just define things in diseqc.conf).

There are other problems, like the channel autoupdate picking data from the wrong satellite. I don't think you can solve that without a plugin. In fact Klaus promised to check the plugins in the tuning thread to see if a channel can be actually tuned to and it is ready to be tuned. If he manages do to it and at the same time doesn't block vdr responsiveness to the remote I think it would be the best solution.

I am not sure that I completely understand this paragraph.

IMHO a plugin should not be needed, just some way to make sure that 'transient' data does not get added. Maybe a minimum time between channel change and autoupdate? Again this could be configurable for changing source.

Changing source from C to T to S should not matter, but when changing from SXXX to SYYY it does.

...

However, Klaus kindly reminded us that his day has only 24 hours (bad, bad Klaus ;-), so you'll just have to be patient.

Bye

Klaus: do you have any thoughts on this subject. IMHO current vdr is broken for movable dishes.

(While it may work a bit for live tv on a ff card, recordings require a restart to work and transfer mode does not work either).

Klaus Schmidinger wrote:

...

Klaus: do you have any thoughts on this subject. IMHO current vdr is broken for movable dishes.

(While it may work a bit for live tv on a ff card, recordings require a restart to work and transfer mode does not work either).

Sorry, at this time I don't have any thoughts on this, except for increasing the lock timeout.

Not good since it makes vdr unresponsive (in my case the dish can take 2..3 minutes to go from one extreme to the other).

What about my suggestion?

1) modify cDvbDevice::HasLock to check that the dish is positioned (by querying plugins) 2) remove the wait for HasLock in cDevice::AttachReceiver 3) remove also Receiver->Activate(true) there. In its place mark that this receiver hasn't been activated 4) modify cDevice::Action to wait for HasLock() before the main loop 5) call receiver[i]->Activate(true) in cDevice::Action just befor calling Receive, but only for receivers that haven't been activated yet

I've played with it a bit and it seems to work, however I don't have a ff card. Instead of 1) I checked the dish status directly in 4) (and actually it should check *only* for the dish position and not for a lock, so the recorder thread can notice if there is no data). The "problem" is that all plugins should make sure to detach receivers immediatile during a channel switch, otherwise cDevice::Action wouldn't restart (and that's necessary to check for dish position), and make sure to use Activate(true) to start their own thread (e.g.the ttxtsubtitles plugin doesn't do either). I don't know if all cReceivers used inside of vdr hold to these rules though. Another thing to modify is the section handling (it should check too that the dish is positioned before starting).

Bye

Seppo Ingalsuo wrote:

I guess Luca's suggestion is even better than the existing patch (though

but I'm not too knowledgeable about vdr internals so I'm not sure it will work in every case

dish position querying from a plugin doesn't work for me).

If you don't want a full-fledged plugin like rotor, you or someone else could write a very simple plugin that just keeps track of the supposed position of the dish (i.e. at each channel switch update the target based on the source and every X ms increment or decrement the position until it reaches target, add some additional wait for safety).

Bye