TimerSanityCheck can report a failure when it should be OK

[birdman]

I'm having problems with getting a recording to be enabled.

There are two existing timers:

20:57 to 22:45
20:57 to 22:05

The one I'm trying to add is for:

22:27 to 23:20

i.e. after the latter of those first two timers has finished I should have a free tuner for that next recording to run; but TimerSanityCheck reports otherwise.

I've added some debug statements to TimerSanityCheck.py to see what is going on. All I can see is that
the fakeRecService.start(True) produces an abnormal result (True not False?), so then

if not fakeRecResult: # tune okay

fails. The code then goes on to add an item of "DVB-T" to tunerType. This still leaves it as a failure, though.
I haven't (yet?) been able to find what handles that fakeRecService.start(True) call. (EDIT: eDVBServiceRecord::start() in lib/service/servicedvbrecord.cpp?)

The odd thing is that if I edit the start time of one of those timers to be 20:55 then the sanity check passes OK (so is it cause by having timers starting up at the same time?). However, since these are set by autotimers, when that runs again it resets the start times and then on the following autotimer scan it throws up the clash again.

[ccs]

However, since these are set by autotimers, when that runs again it resets the start times and then on the following autotimer scan it throws up the clash again.

I know it's only a workaround, but you could always change the "custom offset" for one of the autotimers, or even disable it after editing one of the timers.

I've always wondered what the green tick next to an autotimer meant - it shows that it is "enabled".
It's a pity it doesn't indicate if any timers have been set as well.

Hope you can find a proper solution.

[birdman]

I know it's only a workaround, but you could always change the "custom offset" for one of the autotimers, or even disable it after editing one of the timers.

That was going to be step 2.
Step 1 was to edit the timers.xml file to swap the two timers around that start at the same time (so the one which finished first is first in the file).
And that works!!!
It might be a simpler "solution", as that file is written out in python (so I can sort it there) whereas the TimerSanityCheck issue is somewhere unknown in C++ code.

I've always wondered what the green tick next to an autotimer meant - it shows that it is "enabled".
It's a pity it doesn't indicate if any timers have been set as well.

I don't think anything actually knows which timers have been set by which autotimers (read on....)

Hope you can find a proper solution.

Well, I'll sort equal-string timers on finish times shortly....

Now, about timers and autotimers. I've been working on the AutoTimer code to make the similarity level (for titles and descriptions) be configurable, add the ability to remove [*] flags (and any other text you want) from the end before checking for similarity, and also configuring timegroups (time spans) such that any programmes that fall into different ones will be considered as different even if their description are the same (== "sufficiently similar).
Once I'd added the timegroups I was wondering whether the other two bits would be useful, as the timegroups seemed to discriminate everything for me.
But, in a timely reminder that it helps to have as many options as possible, this coming weekend Channel 5 decided to split the Football League Tonight into two programmes, running consecutively. The programmes are all repeated (and also on Ch5+1, Ch5+24 and Spike). Given that I usually (but not always) have clashes with the first broadcasts I have to set it up so that it will find any of them. The first broadcasts all have "New:" at the start, but the repeats do not.
Now, "New: The Championship: Football..." and "The Championship: Football..." are 0.920634920635 similar, but "New: Goal Rush: Football League..." and "Goal Rush: Football League Tonight" are only 0.764705882353 similar, which is below the 0.8 test for titles. So I'd get two recordings of the Goal Rush done each time (one with New:, one without). However, I can now configure that level, so I lowered it to 0.6 (this was before I did a test of the similarity levels), and at that point I got none, as there is actually a 0.617647058824 similarity between the different programmes, and since there is no indication of which autotimer set which timer, you can get a match between programmes that would be set by different autotimers.
Anyway, I've managed to set a level that works.

[birdman]

I've figured out where to make the changes so that all new timers (anything added to the timer_list) get added sorted by a primary key of the start time and a secondary one of the end time.
It replaces insort() calls with an append and keyed sort (of the start and stop times).

Patches are available under the Timers-EndSort at:

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

[birdman]

The odd thing is that if I edit the start time of one of those timers to be 20:55 then the sanity check passes OK.

Not actually what is happening.
I've gone back to the original code and done some testing. The issue happens when the the longer timer comes first, even if the start times are different (presumably when I changed one yesterday I altered things such that the order changed).

So:

20:57 to 22:45 (New: The Young Montalbano, BBC Four)
20:57 to 22:05 (New: The Championship: Football..., Channel 5)

results in a clash for:

22:27 to 23:20 (QI XL, BBC TWO HD)

but if the order of the first two recordings changes (either by modifying start times by a minute, or sorting timers such that equal starters are sorted by end times) the the clash doesn't happen and the third timer adds OK.

This happens whether creating a new timer or trying to enable a disabled one (which is much quicker to do when testing...)

[judge]

Not actually what is happening.

Thanks for finally explaining the issue in simple steps.

20:57 to 22:45 (New: The Young Montalbano, BBC Four)
20:57 to 22:05 (New: The Championship: Football..., Channel 5)
results in a clash for:
22:27 to 23:20 (QI XL, BBC TWO HD)

Set the same 3 recordings & issue is obvious.
Issue should be moved out of [MB Premium Twin HD] as it happens on all ViX images.

[abu baniaz]

Issue should be moved out of [MB Premium Twin HD] as it happens on all ViX images.

Done. Changed to "Vix Misc"

[birdman]

It's just occurred to me that since this can occur with timers starting at different times (see #5), it should be able to happen at any time. So I'm surprised I haven't seen it before...but when I have multiple concurrent timers they tend to be on BBC1/BBC2/ITV/Ch4 HD, which are all on the same FreeviewHD mux, so no conflicts - this set seems to be abnormal for me.

I've set the conditions up again and added code to see what fakeRecService.start(True) is actually returning.

The answer is -6.

I've had a look at the code in eDVBServiceRecord::start() and can't see anything that would do that (only -1, -2, -3 and -4 are defined in the enums). Hmmmm......

[ccs]

......deleted

[birdman]

It's just occurred to me that since this can occur with timers starting at different times (see #5), it should be able to happen at any time.

I've just set:

13:00 -> 18:00 BBC2 Snooker
14:00 -> 15:00 ITV Judge Rinder

then tried to add:

16:06 -> 16:40 ITV3 Man About the House

and the latter reports a clash with the Snooker. So this seems to be a general problem when you have a long running recording with multiple shorted ones overlapping.
Looks like I may have to compile debug versions of enigma2 itself....

but when I have multiple concurrent timers they tend to be on BBC1/BBC2/ITV/Ch4 HD, which are all on the same FreeviewHD mux, so no conflicts - this set seems to be abnormal for me.

At 21:00 on Sunday I have all 4 of those channels recording. I can also add a fifth on a separate mux OK.
The failing example above is three different muxes.

So, my "sort on end times as well" is only a workaround for the case I had.

[birdman]

Looks like I may have to compile debug versions of enigma2 itself....

I've made the first step along that path - I've just produced a (working) build of enigma2 (or rather, all of Openvix), so should now be able to add debug statements in the C++ code to help figure out what is going on.

Various mutterings along the way, as some people think you can put bash extensions into /bin/sh scripts (which doesn't work on a Debian/Ubuntu-based system). Also, the minidlna SourceForge CVS server was broken, so I looked for another source, found one (looks like the development site has moved off SourceForge?), but then had to work out what to do to the *.bb build configuration file to get it to download and use a *.tar.gz file instead of a CVS repository.

Along the way I was hit by two bugs in the text editor I've used for the last >20 years. It never did much bother with buffer size checking. So, one more fix, and one more larger buffer size (with a test in at least one place). At least some debugging got done today.


ccs has pointed out that there is a similar issue reported on the OpenPLi forum:

http://forums.openpli.org/topic/39306-problem-with-timer-sanity-check/?view=findpost&p=511785

[birdman]

I've made the first step along that path - I've just produced a (working) build of enigma2 (or rather, all of Openvix), so should now be able to add debug statements in the C++ code to help figure out what is going on.

Hmm....well, so I though, but....

If I edit either of the two copies of servicedvbrecord.cpp (well, 3 - but 2 are hard-linked) and run a rebuild then the enigma2 executable doesn't get rebuilt. How do I make that happen?

[birdman]

I've set the conditions up again and added code to see what fakeRecService.start(True) is actually returning.

The answer is -6.

I've had a look at the code in eDVBServiceRecord::start() and can't see anything that would do that (only -1, -2, -3 and -4 are defined in the enums). Hmmmm......

Something else is getting -6 as an error too:

http://www.world-of-satellite.com/sh...l=1#post388337

[birdman]

Set the same 3 recordings & issue is obvious.

By "obvious" do you mean you know what the cause of the problem is?

[judge]

By "obvious" do you mean you know what the cause of the problem is?

Nope, just that obvious = easier to reproduce it, so hopefully easier to find a solution.
Obvious bugs get fixed faster, so better to make them as obvious & easy to reproduce as possible.