Re: [vdr] Suggestion (patch) for sections.c
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.0 +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(1);
+}
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@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Suggestion (patch) for sections.c
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.schmidin...@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.0 +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(1);
+}
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@linuxtv.org
http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdrhttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Suggestion (patch) for sections.c
On 09.02.2013 12:03, Teemu Suikki wrote:
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.
It would also have an effect on the EPG displayed when the channel display is
shown. If the new channel hasn't been tuned to in a while it might display
totally wrong events for as long as 10 seconds. And a recording might also use
wrong EPG data in such cases.
Klaus
But yes, I agree the patch could be cleaner somehow.
9.2.2013 12.50 Klaus Schmidinger klaus.schmidin...@tvdr.de
mailto:klaus.schmidin...@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.0 +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(1);
+}
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
[vdr] Suggestion (patch) for sections.c
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.0 +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(1);
+}
if (!DeviceHasLock)
cCondWait::SleepMs(100);
for (int i = 0; i NumFilters; i++) {
--
Teemu Suikki
http://www.z-power.fi/
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
