142 replies to this topic

[jeanclaude]

new conflict today - currently running timers :

 conflict1.jpg   81.2KB   3 downloads

 

when checking the 4th timer (sleepy hollow) the following timer conflict screen appears :

 conflict2.jpg   82.33KB   2 downloads

 

here are the files you requested for :

 autotimer.xml   36.59KB   3 downloads

 

aha - can't upload autotimer.log because it's too big (46 MB) - I have compressed it in a zip file :

 autotimer.zip   2.59MB   2 downloads

 

hope you find this useful.......

Edited by jeanclaude, 29 March 2016 - 21:49.

[Dimitrij]

EPGImport plugin.

Use option "Run AutoTimer after import"?

[jeanclaude]

yes ........ seems logical

[Dimitrij]

yes ........ seems logical

Please disable it for testing.

[jeanclaude]

okay, we'll do (tonight). I'll let it run for a few days (autotimer will lauch every 18 hours) and I'll see how it goes.I'll be back

[Dimitrij]

conflict2.jpg first conflict  timer not AT.

When you added it(The story of...), AT timers(see conflict2.jpg) already existed?

[Dimitrij]

This  AT ( see conflict2.jpg) in not autotimer.xml and not autotimer.log.

How can this be?
Where did they come from?

[jeanclaude]

timers are being set in 3 ways :

- twice a week I scan the epg for anything that seems interesting and I set a manual timer. If a timer conflict pops up, I de-activate other timers (mostly set by AT) until the new timer is accepted

- AT runs after every EPG import (will deactivate tonight) and every 18 hours after reboot. This will create activated & de-activated timers

- I have found out that when a timer conflict exists, then AT will only create de-activated timers. Upon resolving the conflict, I check all de-activated timers and try to re-activate them using the yellow "ON" button. This will work for most deactivated timers, pressing the yellow button makes them disappear from the list of deactivated timers (which is at the bottom of the timerlist). For some the timer conflict screen will pop up and I then decide either to keep the timer deactivated, or I start deactivating other timers until that timer is activated.

 

the 2 files I attached were retrieved just after I made the 2 screenshots (OR I made a big mistake and I was connected to my 'other' dreambox when fetching those files, in which case they will indeed not correspond with the screenshots). I'll make sure I'm connected to the correct dreambox next time, and I'll resend the files.

[jeanclaude]

come to think of it, I also check the timers regularry in the web-interface (because here you can also see the programme description).

timers that I don't need are de-activated here in the webinterface.

I can't prove it but I have the strong impression that some of these deactivated timers are re-activated again by AT, perhaps when there is a small shift in the start and/or ending timers ?

I often find myself deactivating timers I thought I had already deactivated before.

[Dimitrij]

timers that I don't need are de-activated here in the webinterface.

This OpenWebif?

Only deactivate timers or activate too in OpenWebif?

Edited by Dimitrij, 30 March 2016 - 12:23.

[jeanclaude]

standard Open PLI webinterface.

and I only deactivate timers in webinterface, I never set a timer using the webinterface.

[Dimitrij]

jeanclaude

new wersion AT

[jeanclaude]

new script copied, dreambox rebooted, no more AT run requested after EPG download.

I've also deleted the current AT logfile to make sure that we start with a clean situation.

we'll see tomorrow evening how this goes ............... 

[anudanan]

I´ve had an interessing timer conflict bug since last weekend, I think after switching the local time to daylight saving time an sunday morning 2pm

 

We was on vacation  until last tuesday and on wednesday my wife can´t set some new timer on our et8000. She got an conflict message but there was no conflict with the 3 tuners. Yesterday she had the some problem on our 2  et9000 with 2 tuners. The timer conflict message came up but there was no conflict for 2 timers.

 

To solve the problem I´ve restarted enigma on all et8000/et9000 boxes. Now it works well. In the past I never have had this problem, I don´t user autotimer, only manually timersettings.

 

It is possible that after automatic switching to the daylight saving time the existting timerlist must have a conversion from the new daylight saving time to an internal system time to work successfully during the next  timerconflict detection? 

Edited by anudanan, 1 April 2016 - 08:42.

[jeanclaude]

today's observations :

when activating the dreambox, I got the following message

 conflict1.jpg   125.77KB   1 downloads

 

doesn't look good to start with. let's have a look at running timers :

 conflict2.jpg   74.31KB   1 downloads

 

2 things strike me as odd :

- the top 2 timers are actually the same recording, apparently boyh set by autotimer

- why are 2 timers in "activating" state (orange) when their activation is more than 1 minute in the future ? the 2nd timer won't even start in more than an hour.

I check the first timer in the list, and sure enough the timer conflict screen pops up :

 conflict3.jpg   88.35KB   2 downloads

 

now at this time the timer sanity check goes haywire : I have to deactivate EVERY timer in the list before the timer conflict screen disappears. I end up with the following "conflicting" timers :

 conflict4.jpg   90.5KB   2 downloads

 

as you can see all but one is already de-activated, with the "conflict not resolved" popup appearing every time the yellow "OFF" key is used. After de-activating the last timer in the screen, the timer conflict screen disappears and I'm back in the timer list :

 conflict5.jpg   74.54KB   3 downloads

 

the top 2 timers are now recording, the other one is still "in preparation" - strange.

I check the current timer again, and sure enough another timer conflict screen is displayed. This time the conflict can be resolved by deactivating a single timer in the list. I suppose this 2nd conflict is the reason why I could only resolvethe 1st conflict by deactivating all timers : it seems the timer sanity check also returned the 2nd timer conflict status when checking the 1st timer conflict. As rhe timer sanity check continued to get a "not resolved" response, it did not exit the 1st timer conflict screen until all timers were deactivated.

 

here is my autotimer.xml :  autotimer.xml   46.14KB   1 downloads

and the autotimer.log file (in zip format) :   autotimer.zip   167.78KB   2 downloads

 

this time I made sure I was connected to the correct receiver. hope this helps you solve this problem.

 

[Dimitrij]

Nothing comes out.
I can not cope with this large log.
Too many AT timers.
And satellite 28.2e I can not test personally.

[Dimitrij]

ок.

new version AT

[jeanclaude]

yeah, well, I'm not gonna reduce the number of autotimers just because you can't cope with such a large log.

talking of this logfile, I was a bit surprised to see that every matching event on all channels seems to be processed and then rejected because it's not in the channel selection list.

isn't it easier (and quicker) just to scan the epg of the requested channels for any autotimer event ? This would also significantly reduce the logfile size.

 

but you'll have to agree that there are problems with the timer sanity logic, my examples I send yesterday evening clearly show this.

[jeanclaude]

ok, we'll install it and see how this works out. I'll be in touch with the results 

[Dimitrij]

'Timer sanity logic' in Pli not problem.

Argument --> restart enigma2 and auto disable all conflict timers  of timer list.

Where did they come from, is the question.