Klaus Schmidinger wrote:

Yes, this has been changed in version 1.3.27, and at least my tests indicated that it would work now.

I have the opposite (I think) problem: I have epg timeout set to 0 to disable epg scan, but while playing a recording the dish moved.

Bye

Luca Olivetti wrote:

Klaus Schmidinger wrote:

...

Yes, this has been changed in version 1.3.27, and at least my tests indicated that it would work now.

I have the opposite (I think) problem: I have epg timeout set to 0 to disable epg scan, but while playing a recording the dish moved.

That's odd. The check in question here is

if (Device != cDevice::ActualDevice() || (Device->ProvidesTransponderExclusively(Channel) && Setup.EPGScanTimeout && now - lastActivity > Setup.EPGScanTimeout * 3600)) {

which explicitly contains a check whether Setup.EPGScanTimeout is not 0.

Maybe something else has started moving your dish?

Klaus

Luca Olivetti wrote:

Klaus Schmidinger wrote:

...

Luca Olivetti wrote:

...

Klaus Schmidinger wrote:

...

Yes, this has been changed in version 1.3.27, and at least my tests indicated that it would work now.

I have the opposite (I think) problem: I have epg timeout set to 0 to disable epg scan, but while playing a recording the dish moved.

That's odd. The check in question here is

if (Device != cDevice::ActualDevice() ||

Isn't that always true when you're replaying through a dxr3 or xine output plugin?

...

 (Device->ProvidesTransponderExclusively(Channel) &&
  Setup.EPGScanTimeout && now - lastActivity > 

Setup.EPGScanTimeout * 3600)) {

which explicitly contains a check whether Setup.EPGScanTimeout is not 0.

if the above is true the the setting of EPGScanTimeout doesn't matter

I made it so that an EPG scan can always be done if there is a free DVB device. This means that if there is only a FF DVB card and a replay is going on, the receiver part of the DVB card actually can do an EPG scan.

Having Setup.EPGScanTimeout set to 0 should actually inhibit the entire EPG scan mechanism, because of

if (Setup.EPGScanTimeout && Channels.MaxNumber() > 1) {

at the beginning of cEITScanner::Process().

Klaus

e '0' means "no EPG scan at all". So maybe I should pull the check for Setup.EPGScanTimeout to the front of this condition.

Klaus

Klaus Schmidinger wrote:

Bernhard Stegmaier wrote:

...

I messed around the whole evening trying to get EPG scan to work on my vdr. I have a freshly installed vdr 1.3.27, single FF-card... no patches, just the plugins: femon, graphlcd, epgsearch

Triggering EPG scan with "svdrpsend.pl SCAN" seems fine (writes something like "EPG scan triggered"), but nothing happens. Triggering via the red button in the EPG menu does nothing either.

I have something in mind that I read that it didn't work on previous versions and that Klaus said, that he has changed (or will change) something to make it work again... has this been changed yet?

Yes, this has been changed in version 1.3.27, and at least my tests indicated that it would work now.

Could you try without the plugins? Apparently none of them is essential.

I have the same problem (nothing happens on scan command/button): vdr 1.3.27 without plugins dvb drivers from SuSE 9.3 kernel 2.6.11.4

Andreas

bernhard.stegmaier@in.tum.de(Bernhard Stegmaier) 22.06.05 21:25

Hi!

OK, the culprit was "TimeOut=0". If I set it to any other value everything is fine. Klaus, I think you should move the test for "TimeOut=0" somewhere else (as as sketched in the morning)... since it is somewhat confusing, that TimeOut=0 even prevents manually triggered EPG scans.

Some more thoughts on that issue... as far as I understand, the EPG-scan timeout only affects single-card systems, since otherwise EPG-Scan is done anyway, so:

Better use the term "restricted resources" because a multicard motor dish or LNBsharing system EPG-scan can't work sucessfully or will destroy recordings/livestream too!

(Currently in (my) LNBsharing EPG scan ends in an endless loop)

• It is useful if vdr is running 24/7, because you can set it to a

high value such that it does not disturb live-tv.

Some guys programms a dummy recording at 3:00 just to turn the VDR on to get the "fresh" EPG infos. Then a delay of 1minute would be ideal...

• In my case, vdr is only up when i watch live-tv, watch a recording,

or record something. If I set the timeout to a low value (1h) it is annoying during live-tv. On the other hand, it would enable EPG-scan while watching recordings. If I set it to a high value, it does not disturb live-tv, but most likely will never kick in, because I probably never watch such long recordings. In both cases, I don't find it very useful.

• What about a configuration option "EPG-Search only when viewing a

recording"? If it is disabled, everything is like it is now. If enabled, I might set the timeout to 1h, and EPG-scan only happens when I watch a recording and it does not disturb there...

Sound good. But EPG should save the channel when it started to restore it when the recording stops...

But EPG should take running recordings into count.

Another thing that might be useful: I'm currently setting up the wake-up such that vdr is powered on each night and an EPG-scan is triggered via SVDRP. It would be useful, if I could add a parameter "power off after scan"... of course that would be done anyway by means of the user idle setting, but why waiting 45 minutes (in my case) if a scan lasts, say, 10 minutes?

ACK.

Does anybody have/know patches in these two directions? If not, I possibly will try to find some spare time to do this myself...

PS: That's the 3rd attempt to post this reply... now using Linux as I did for the other posts. The other two attempts have been made using WindowsXP/Thunderbird... can anybody tell me why they are rejected?

Show the error message.