[vdr] Suggestion (patch) for sections.c

Teemu Suikki tsuikki at zuik.org
Sat Feb 9 12:03:45 CET 2013


Klaus,

This has no effect on channel switching time. Channel switch is instant.
Patch only delays the scanning of pids, epg data, new transponders etc.

Of course if the pids have changed since the last time this channel was
tuned, it will use the old values for the first 10 seconds.. but I don't
think this happens very often.

But yes, I agree the patch could be cleaner somehow.
 9.2.2013 12.50 "Klaus Schmidinger" <Klaus.Schmidinger at tvdr.de> kirjoitti:

> On 08.02.2013 14:52, Teemu Suikki wrote:
>
>> Hi!
>>
>> As I mentioned in my previous email, I'm using diseqc.conf to drive my
>> motorized dish.
>>
>> I noticed that sometimes VDR generates false channe updates, when the
>> dish is moving. The problem is, channel switches immediately, but it takes
>> seconds for the dish to move. Often there is several seconds time when VDR
>> thinks it's already on the new channel, but old satellite is still tuned.
>>
>> I googled and I noticed something about this in actuator plugin README:
>>
>> "vdr assumes that, as soon as a channel has been switched to, the new
>> source (satellite) is valid, even if the dish is moving, so the autoupdate
>> function will assign new/updated channels to the wrong satellite. The
>> plugin's workaround is to disable autoupdate while the dish is moving and
>> restore the
>> previous setting only when it has reached the target satellite. It's
>> possible that the plugin will fail to restore the value of this setting. If
>> you see that channels aren't updating anymore check this setting (main
>> menu->configuration->dbv->**update channels, note that while the dish is
>> moving this
>> setting is always "no", so check and modify it only when the actuator is
>> idle). "
>>
>> RotorNG does not have such hack, so it still suffers from this problem.
>> Also as I said, I use VDR "as is" without rotor-ng, and have this problem.
>>
>> I made the following patch to sections.c, this is for vdr 1.7.27 but I
>> guess it's similar in newer VDRs as well..
>>
>> If source has been changed, it forces a 10 second delay. This means that
>> epg data and channel updates are disabled during that time, but it
>> shouldn't matter.
>>
>> 10 seconds might not be quite enough to get to the new position with a
>> slow motor, but it is enough to make the frontend loose lock on the
>> previous satellite..
>>
>> Here's also example from syslog:
>>
>> Feb  8 15:17:23 yavdr vdr: [16352] switching to channel 990
>> Feb  8 15:17:23 yavdr vdr: [16420] New source 0x5300ff7e, 10sec wait
>> forced in section loop
>> Feb  8 15:17:29 yavdr vdr: [16419] frontend 1/0 lost lock on channel 990,
>> tp 112322
>> Feb  8 15:17:30 yavdr vdr: [16419] frontend 1/0 regained lock on channel
>> 990, tp 112322
>>
>> Here you can see how it takes full 6 seconds before frontend reports lost
>> lock, after channel switch.. Channel is really switched at 15:17:30 when it
>> regains lock. If any section data would be received between 15:17:23 -
>> 15:17:29, it would be registered on the wrong satellite.
>>
>> ------------------------------
>> The patch:
>>
>> *** vdr-alt/sections.c  2007-10-14 15:52:07.000000000 +0300
>> --- vdr/sections.c      2013-02-08 14:50:30.524186976 +0200
>> ***************
>> *** 164,169 ****
>> --- 164,171 ----
>>
>>    void cSectionHandler::Action(void)
>>    {
>> +   int PrevSource=shp->channel.**Source();
>> +
>>      SetPriority(19);
>>      while (Running()) {
>>
>> ***************
>> *** 183,188 ****
>> --- 185,196 ----
>>
>>            if (poll(pfd, NumFilters, 1000) > 0) {
>>               bool DeviceHasLock = device->HasLock();
>> +            if (PrevSource!=shp->channel.**Source()) {
>> +                 PrevSource=shp->channel.**Source();
>> +                 DeviceHasLock = false;
>> +                 dsyslog("New source 0x%x, 10sec wait forced in section
>> loop\n",PrevSource);
>> +                 cCondWait::SleepMs(10000);
>> +            }
>>               if (!DeviceHasLock)
>>                  cCondWait::SleepMs(100);
>>               for (int i = 0; i < NumFilters; i++) {
>>
>
> While this may be a viable solution for your particular problem, I don't
> think
> putting a general 10s wait in there would be such a good idea. This would
> be totally
> annoying for users who receive multiple sat positions via a multiswitch,
> where switching
> between sources is very fast.
>
> I'm wondering whether there is any information in the SI data as to which
> source
> (i.e. satellite) this data is broadcast on. I guess that should help a
> great deal in actually
> solving this problem.
>
> Klaus
>
> ______________________________**_________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdr<http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20130209/34bc998f/attachment.html>


More information about the vdr mailing list