30 replies to this topic

[kolomparrudi]

Hi,

 

I have an issue with autotimer:

 

When an already created timer start date changes autotimer will create a new event and leave the old timer active. This results 2 records from the same event. I can't find good option/workaround for this issue. I also found this bug when changing from/to daylight saving time.

 

Do you have any solution/workaround for it?

 

Thanks,

 

[WanWizard]

When that happens, is the old EPG entry still present as well?

 

In other words, is the problem that for both EPG entries a timer is created, or is the problem that Autotimer doesn't remove existing timers for which the EPG no longer exists?

[Pr2]

That's why there is an option to delete the EPG before importing it again in EPGimport plugin.

Edited by Pr2, 27 February 2018 - 09:01.

[WanWizard]

That won't delete already created timers either.

[kolomparrudi]

Hi,

 

 

That's why there is an option to delete the EPG before importing it again in EPGimport plugin.

 

The EPG came from DVB-c, so no EPGimport used.

 

When that happens, is the old EPG entry still present as well?

 

In other words, is the problem that for both EPG entries a timer is created, or is the problem that Autotimer doesn't remove existing timers for which the EPG no longer exists?

The EPG refreshes from DVB-c fine and autotimer creates new timer for the new start date and leave the old timer active, so I'll have 2 active timers. If there is only 5-10 minutes difference I'll have 2 separate record from the same content. 

It is annying to have useless recorded entries, uses disk space unnecessary and overload hdd when recording twice in the same time.

 

1 more issue with autotimer: when my STB is turned off with the remove (in standby) the autotimer plugin won't parse periodically (I set this in settings and set the interval for 60 minutes). I had to add a crontab to do it:

*/60 * * * * /usr/bin/wget -q -O/var/log/autotimer.xml http://user:pass@loc...autotimer/parse

 

Regards

kolomparrudi

Edited by kolomparrudi, 27 February 2018 - 17:02.

[Dimitrij]

AutoTimer Settings...

1)"Remove not existing events"

2)Not true

Enable log and see

[WanWizard]

That doesn't work either, as both the events are present.

 

To make it clear the provider first sends "start 18:00 - end 19:00", later sends "start 18:10 - ends 19:10". You'll end up with both events in the EPG, and two timers. Not sure if uniqueness detection takes timers not run yet into account, but that would probably leave the old timer in, and not create the new (and correct) timer.

 

Imho not very simple to solve...

[ccs]

2 timers get created in OpenViX (terrestrial eit tuners) if the time changes and is seen by an autotimer poll.

I've never noticed the 1st timer get deleted, but I guess it might do and I've never spotted it.

[ccs]

Oddly, it has happened just now, live football has pushed an (autotimer) programme back to tomorrow night.
The original timer is still there and autotimer has run a few times now.

[WanWizard]

And is today's programme still in the EPG?

 

If not, have you properly configured autotimer to remove timers not present in the EPG anymore

if so, have you configured that the timer should be unique in title and descriptions?

[kolomparrudi]

Hi,

 

1. Remove not existing events was set to yes, but I have never seen any events deleted.

2. Checked the autotimer debug logs, now it seems to run the auto parse during standby

 

About EPG: when the start date changes I see the new dates in EPG, but I don't know if it still remains in epg.dat or not.

 

Regards,

kolomparrudi

[WanWizard]

If the old one remains in the EPG too, you should be able to see it, for example in the channel single EPG.

[jeanclaude]

sometimes the old timer is deleted (= modified with new start & end times) and sometimes it is not. I suspect that the autotimer plugin doesn't see that both recordings are the same. I have already reported this in the past - it seems linked to the rule that the new timer must match the old timer for 80%. I suspect that this calculation does not take the pre + post times into account so it will compare the existing timer (pre + programme + post) to the new found hit (programme only), decides that it's less than 80% and so sets a new timer (with pre + programme + post).

[kolomparrudi]

Does it solve the problem If I clear the EPG and start an epgrefresh? Will autotimer remove the not existing event?

[Dimitrij]

sometimes the old timer is deleted (= modified with new start & end times) and sometimes it is not. I suspect that the autotimer plugin doesn't see that both recordings are the same. I have already reported this in the past - it seems linked to the rule that the new timer must match the old timer for 80%. I suspect that this calculation does not take the pre + post times into account so it will compare the existing timer (pre + programme + post) to the new found hit (programme only), decides that it's less than 80% and so sets a new timer (with pre + programme + post).

I saw a small mistake.

Need test.

AutoTimer.py

			for rtimer in timerdict.get(serviceref, ()):
				if rtimer.eit == eit:
					oldExists = True
					doLog("[AutoTimer] We found a timer based on eit")
					newEntry = rtimer
					oldEntry = rtimer
					break
				elif config.plugins.autotimer.try_guessing.value:
-					if timer.hasOffset():
-						# Remove custom Offset
-						rbegin = rtimer.begin + timer.offset[0]
-						rend = rtimer.end - timer.offset[1]
-					else:
-						# Remove E2 Offset
-						rbegin = rtimer.begin + config.recording.margin_before.value * 60
-						rend = rtimer.end - config.recording.margin_after.value * 60
					# As alternative we could also do a epg lookup
					#revent = epgcache.lookupEventId(rtimer.service_ref.ref, rtimer.eit)
					#rbegin = revent.getBeginTime() or 0
					#rduration = revent.getDuration() or 0
					#rend = rbegin + rduration or 0
-					if getTimeDiff(rbegin, rend, evtBegin, evtEnd) > ((duration/10)*8) or timeSimilarityPercent(rtimer, evtBegin, evtEnd, timer) > 80:
+					if timeSimilarityPercent(rtimer, evtBegin, evtEnd, timer) > 80:
						oldExists = True
						doLog("[AutoTimer] We found a timer based on time guessing")
						newEntry = rtimer
						oldEntry = rtimer
						break

[jeanclaude]

Dimitrij,

if you send me the new autotimer.py then I'm willing to install it in my system & test for a few days to see if I'm getting less timer doubles .....

[Dimitrij]

Dimitrij,

if you send me the new autotimer.py then I'm willing to install it in my system & test for a few days to see if I'm getting less timer doubles .....

Send me yours AutoTimer.py and I will fix it.

[jeanclaude]

ok - no need - found the code & made the modifications. currently restarting enigma2 & I'll run the plugin afterwards.....

[jeanclaude]

OK - autotimer has run - checking the logfile - and I seem to be finding a lot of the following messages :

2018-02-28 10:16:07,448 - INFO - [AutoTimer] Serviceref 1:0:16:5282:C96:3:EB0000:0:0:0:

2018-02-28 10:16:07,467 - INFO - [AutoTimer] We found a timer based on eit

2018-02-28 10:16:07,470 - INFO - [AutoTimer] AutoTimer Top Gear modified this automatically generated timer.

2018-02-28 10:16:07,493 - INFO - [AutoTimer] conflict not found for modify timer Top Gear Special: James May's Cars of the People.

2018-02-28 10:16:07,496 - INFO - [AutoTimer] AutoTimer modified timer: Top Gear Special: James May's Cars of the People .

2018-02-28 10:16:07,547 - INFO - [AutoTimer] possible epgmatch Top Gear Special: James May's Cars of the People

2018-02-28 10:16:07,550 - INFO - [AutoTimer] Serviceref 1:0:19:5282:C96:3:EB0000:0:0:0:

 

so indeed this version seems to modify the existing timers better than to create new timers.

but it'll take a few days for the old timers to disappear and to verify if no more doubles are being created.

[jeanclaude]

and while we're at it - I think there may be another issue with autotimer. If you modify a timer which is deactivated, do you by any chance reactivate them ?

as from time to time it looks as if timers I've de-activated are coming back in the active timers list - which is not wanted of course ..........