Debugging AutoTimer conflicts

[Photovoltaic]

I'm after some help to resolve a problem I'm having with Autotimers.

I schedule most stuff these days via the Open Webif browser interface. I've been using AutoTimers without problems for weeks, but now I'm starting to get clashes that shouldn't be there.

The Open Webif interface for this will return, after I hit the button to parse the AutoTimers, a result like; Found a total of 32 matching Events. 0 Timer were added and 0 modified, 17 conflicts encountered, 0 similars added.

The problem I'm having is working out what is actually clashing; I don't think there should be any clashes.
On the TV itself, periodically a message pops up saying what it was unable to add due to clashes (huge long list) but this never stays around long enough to be useful.

Is there any way to get further information on exactly what it thinks the clashes are, either via TV Interface, Web Interface or CLI ?



- ah wait, I see something, I looked in /etc/enigma2/autotimers.xml - and it's full of things that should have been removed. Why would this file and the Webif not match?

[birdman]

The problem I'm having is working out what is actually clashing; I don't think there should be any clashes.There is a fix for a bug in the TimerSanityCheck.py code, but it didn't maker 037.


On the TV itself, periodically a message pops up saying what it was unable to add due to clashes (huge long list) but this never stays around long enough to be useful.That will be when the background AutoTimer code runs.
The bug (see above) means you can add a timer, but the conflict is only reported afterwards, and erroneously. At this point you will get the conflict report when adding any timer - so the conflict might be unrelated to what is being added.



Is there any way to get further information on exactly what it thinks the clashes are, either via TV Interface, Web Interface or CLI ?You can force the AutoTimer to run by going into the list and Save'ing it. But it will only show what you are already seeing.

- ah wait, I see something, I looked in /etc/enigma2/autotimers.xml - and it's full of things that should have been removed. Why would this file and the Webif not match?From what I can tell, if you add/remove timers via Webif the xml file doesn't get updated until enigma2 is stopped(restarted) and looking at the on-screen menu of AutoTimers doesn't show what Webif does.
No idea why...

[Photovoltaic]

From what I can tell, if you add/remove timers via Webif the xml file doesn't get updated until enigma2 is stopped(restarted) and looking at the on-screen menu of AutoTimers doesn't show what Webif does.
No idea why...

yeah, that's really confusing. I actually found that Autotimers interface on TV was same as webif interface, but totally different from autotimers.xml file.

Some more stuff I found since the last post;


1. There was way more info in autotimers.xml that webif showed
2. After editing autotimers.xml manually to remove shows I no longer wanted recording, on the next open of autotimers page in webif, it was slightly more in-sync
3. It seems to specifically not be adding anything after Feb 28th. Whether this is coincidence or not I don't know, but could it be confused by Leap Year? Seems unlikely.

[Photovoltaic]

After a bit of a clear up I managed to get it to start adding some new timers, but it's still reporting conflicts where there aren't any visible to me.

I'm utterly confused by this. It's just not behaving logically.

[birdman]

After a bit of a clear up I managed to get it to start adding some new timers, but it's still reporting conflicts where there aren't any visible to me.

I'm utterly confused by this. It's just not behaving logically.You could try downloading the TimerSanityCheck.py file from:
http://birdman.dynalias.org/OpenVix/patches/SanityCheck/popping it in place, restarting enigma2 and seeing whether it fixes your problem.

[birdman]

yeah, that's really confusing. I actually found that Autotimers interface on TV was same as webif interface, but totally different from autotimers.xml file.I find that if I enable/disable an AT in WebIF that the changed state isn't reflected in on-screen displays.




There was way more info in autotimers.xml that webif showed

Things like "Avoid Duplicate Descriptions". Fine-tuning has to be done via the TV.

[Photovoltaic]

I added the replacement .py file and rebooted (which has compiled it, I see) and it's changed the behaviour but I'm not certain it's "Fixed"

Running "parse" on OpenWebIF view of AutoTimers now shows 0 conflicts but 0 matches - there should be over 20 matches? I'll keep an eye on that...

The TV Interface looks as expected, and the conflict message is no longer periodically popping up, but instead this;

47021

[Photovoltaic]

Hmm, that message has gone now. Doesn't seem to be coming back.

Now that I can see it's adding things again, I'm beginning to suspect that all of the "Conflicts" that I was getting previously, unexpectedly, were actually cases where it was a repeat airing of something that had already aired, so was getting blocked by the "Require Description to be Unique: Yes" flag. Is that plausible? If so, why would such a case be marked as a Conflict, and why would a different TimerSanityCheck.py change this behaviour?

[birdman]

... so was getting blocked by the "Require Description to be Unique: Yes" flag. Is that plausible? If so, why would such a case be marked as a Conflict, and why would a different TimerSanityCheck.py change this behaviour?It wouldn't be marked as a conflict (the instance would just be skipped in the AutoTimer code). The TimerSanityCheck.py would never be called for that case.