[ViX_Misc] TimerSanityCheck can report a failure when it should be OK

[birdman]

FIXED!!!! (I believe...).

Just need to do some more testing - and at the moment I've have imminent recordings.

Just as well I did, as I'd put in two parts to fix it. Part1 didn't work, so I added part2, which did. So I was just going to remove part1, but a test showed that although that did allow my test recordings to be added without clashes, it was clear from the log that it was "working but still wrong" (the destructor was still called late, but not so late that the clash was reported).
So, both parts are needed.

After several days of adding lots of debug statements to the C++ code (and having to turn on RTTI [or rather, turn -fno_rtti off], so that I could print debug info for just the 3 types of ePtr I needed, not all 114 of them) I was able to set up just 3 timers in one order which worked, and one order which didn't. Looking at the debug output it seemed that there was a destructor call missing as the code went back into TimerSanityCheck.py. So I finally had a look at that and, indeed, there are 3 variables that hang on to references as timers are added. The result of this was that if the timer that is ending is the same one as was last started up, its FrontEnd (tuner) doesn't get released when it should, and hence continues to be "busy".

Setting the three variables to None at the end of the start-up tests clears this problem. Interestingly the end timer code already had such a var = None setting.

So I've managed to learn a lot more about C++ templates, and about Python's (lack of) variable scoping.

The patch is at

http://birdman.dynalias.org/OpenVix/

under SanityCheck. It also includes the test for completed timers, so that the Done timers passed in at boot time aren't check (there is no way they can clash) - and also mentions a possible way to speed up the check in general, but I haven't coded that yet.

 

[ccs]

Quite a few changes to TimerSanityCheck.py coming up on OpenPLi...

https://github.com/OpenPLi/enigma2/commit/0557b78ca2cc2fd29994d363a092b5ee29bc8b58

 

[birdman]

Quite a few changes to TimerSanityCheck.py coming up on OpenPLi...

https://github.com/OpenPLi/enigma2/commit/0557b78ca2cc2fd29994d363a092b5ee29bc8b58

Interesting.
A lot of it seems to be related to the timer type changing, but it also includes this:

 +              if fakeRecResult == -6 and len(NavigationInstance.instance.getRecordings(True)) < 2: 
 +                  print "[TimerSanityCheck] less than two timers in the simulated recording list - timer conflict is not plausible - ignored!" 
 +                  fakeRecResult = 0

which is a hard-code workaround (==kludge) for what I have just fixed.
Looks like I need to post to the relevant OpenPli thread as well....

 

[birdman]

The patch is at

http://birdman.dynalias.org/OpenVix/

under SanityCheck.

Well, it is now. I'd left the debugging patch in place (although TimerSanityCheck.py itself was "correct").

 

[Huevos]

Thanks Birdman. Changes so far are here:
https://github.com/OpenViX/enigma2/commit/55aacdf7c5ebdaa5204e90137870657b62d109ea

 

[birdman]

Thanks Birdman. Changes so far are here:
https://github.com/OpenViX/enigma2/commit/55aacdf7c5ebdaa5204e90137870657b62d109ea

That highllights something...

An extraneous ";" has crept in (to my code...now removed) on this line:

208: +             					feinfo = None[COLOR=#ff0000];[/COLOR]

Just habit.
It doesn't seem to affect python, but it might be best to remove it.

 

[Huevos]

What language do you normally work in?

 

[birdman]

What language do you normally work in?

Most of my scripting would have been in Perl.

 

[Huevos]

Hi Birdman, can you look at the latest commit to this file on OpenPLi. Also to do with "done" timers.

 

[birdman]

I can't see anything to do with done timers on the History page of changes for the master branch.

https://github.com/OpenPLi/enigma2/commits/master/lib/python/Components/TimerSanityCheck.py

 

[ccs]

Some activity also on the OpenPLi/Dutch forum.

 

[birdman]

Some activity also on the OpenPLi/Dutch forum.

Dutch?
I know there's been activity on the Deutsch one, since I was doing (a lot of) the posting.

 

[ccs]

Dutch?
I know there's been activity on the Deutsch one, since I was doing (a lot of) the posting.

Yes, the Dutch forum, fortunately most of the relevant thread is in English.

http://forums.openpli.org/topic/40505-timer-uitgeschakeld/

 

[birdman]

Yes, the Dutch forum, fortunately most of the relevant thread is in English.

http://forums.openpli.org/topic/40505-timer-uitgeschakeld/

Thanks. I've added a note to that pointing to the explanation I put on the German thread.
Everything else seems to be about wishing to turn the conflict checking off when you can see it's wrong, rather than actually fixing the problem.

 

[twol]

Its always easier to take the easy option especially if the "problem" then seems to "disappear" ... But I always thought the Openpli crowd thought themselves above doing things like that

 

[birdman]

Its always easier to take the easy option especially if the "problem" then seems to "disappear" ... But I always thought the Openpli crowd thought themselves above doing things like that

It was those suffering/reporting the clashes who wanted to be able to turn it off (as far as I could tell).

 

[Huevos]

Birdman, here is the commit,
https://github.com/OpenPLi/enigma2/commit/6e41e91cc6a5b5b0170581b7913ba7767eabca90

Here is the discussion,
http://forums.openpli.org/topic/39299-timer-conflicts/page-4#entry529571

The reason for turning off sanity check is so remote (uncheckable) tuners can be used for recordings. For anyone who wants reliable recordings this is obviously madness.

 

[twol]

Thanks Huevos, I must admit I have been looking at the fallbacktuner & timer conflicts thread ..... From my Wetek experiences running as a client to one of my ET8500,s there are many situations where the streaming from the remote has been broken up ... It is just difficult (for me at least) to get any debug info as to why it happens between the 2 boxes (I am also aware of issues between other non like receivers eg VU/xtrend)
Are you aware of any flags you can set to force more debug msgs? ... Purely on the streaming side.

 

[Huevos]

Not sure. I use my boxes as satellite receivers, and only ever stream occasionally. Never had any problems over wired LAN.

 

[birdman]

BThe reason for turning off sanity check is so remote (uncheckable) tuners can be used for recordings. For anyone who wants reliable recordings this is obviously madness.

I wondered what the '%3a//' check was for. Not having a second box I've never used them (and can't see why you wouldn't do the recording on the other box directly - but no doubt someone does).

Given that I was going to write code to greatly reduce the amount of conflict checking that needs to be done (most of the current checks are unnecessary) I can filter out remote ones as well, since I assume that they are "hope and pray" attempts. I have the pseudo-code written (somewhere...).