Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutoTimer Improvments from user prl001 #175

Open
jbleyel opened this issue May 29, 2017 · 2 comments
Open

AutoTimer Improvments from user prl001 #175

jbleyel opened this issue May 29, 2017 · 2 comments

Comments

@jbleyel
Copy link
Contributor

jbleyel commented May 29, 2017

I have a couple of improvements that I would like to suggest.

The first is that the margin before/after recording (padding time) is
saved in the RecordTimerEntry when an instance is created. This would
mean that whenever a timer's runtime needs to be compared to an EPG
entry or looked up in the EPG (e.g. in AutoTimer.timeSimilarityPercent()
or RecordTimer.RecordTimerEntry.getEventFromEPG()), the actual event
time is used rather than the padded time. The code that calls
AutoTimer.timeSimilarityPercent() adjusts for padding, but if the
AutoTimer doesn't specify ts own padding, it uses the current padding
values, not the values used to create the timer.

There are a couple of bugs in a plugin for an online EPG/recording
setting service used in the Beyonwiz version of enigma2 that can only be
fixed correctly if the correct padding values are known.

These bugs may be more of a problem in Australia than in Europe, because
some Australian broadcasters do not keep accurately to their published
schedule. The after-recording margin typically needs to be 25-30 minutes
in Australia. This is often longer than some programs (especially
children's programs), and it means that if an EPG lookup is done on
(timerStart+timerEnd)/2, the time looked up can be for the wrong program.

I know that this is a change that affects much more than just
AutoTimers. I suggest that it it were to be implemented,
RecordTimerEntry.begin and RecordTimerEntry.end should keep their
current meanings, and two additional attributes,
RecordTimerEntry.margin_before and RecordTimerEntry.margin_after should
be added.

The second suggestion is a more compact implementation for
AutoTimer.timeSimilarityPercent():

Instead of:

|def timeSimilarityPercent(rtimer, evtBegin, evtEnd, timer=None): ... if
(rtimerBegin <= evtBegin) and (evtEnd <= rtimerEnd): commonTime = evtEnd

  • evtBegin elif (evtBegin <= rtimerBegin) and (rtimerEnd <= evtEnd):
    commonTime = rtimerEnd - rtimerBegin elif evtBegin <= rtimerBegin <=
    evtEnd: commonTime = evtEnd - rtimerBegin elif rtimerBegin <= evtBegin
    <= rtimerEnd: commonTime = rtimerEnd - evtBegin else: commonTime = 0 |||

use:

|def timeSimilarityPercent(rtimer, evtBegin, evtEnd, timer=None): ...
commonTime = max(min(evtEnd, rtimerEnd) - max(evtBegin, rtimerBegin), 0)|

Possibly also allow for negative values for |timeSimilarityPercent()|
when there is no overlap by removing|max(..., 0)|. from the expression,, so:

|commonTime = min(evtEnd, rtimerEnd) - max(evtBegin, rtimerBegin)|

@AbuBaniaz
Copy link
Contributor

Will this resolve the instantaneous clashes?

To explain what I mean better....
(for sake of simplicity, usage is on a single tuner receiver , no overlaps in the timers)

Timer A = 19:00 to 19:30
Timer B = 19:30 to 20:00

The above will always result in a clash because one ends at 19:30 and the other also starts at 19:30

End 19:30:00.000 and start at 19:30:00.001 should work, but that is not currently possible.

@Dima73
Copy link
Contributor

Dima73 commented Jul 7, 2017

[autotimer] auto resolve conflict offset time begin/end (30 sec)
OpenPLi/enigma2-plugins@6798f07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants