[GiGaBlue QUAD+ PLUS] AutoTimer Uniqueness

[birdman]

How on earth to deal with these stupid appended strings! Enough to make you sick!

Ah, the beauty of regular expressions...just add some more bits to it:

[mysys]: cat trimmer.py      
#!/usr/bin/python
#
import re

str = "A programme description [internal comment] with flags. (Ep1/7). [HD] [S] Followed by The News [AD,S] Then Reporting Scotland."

trimmer_re = re.compile('\[[^[]*?\](\s*| then[^][]*?| follow[^][]*?)$', flags=re.UNICODE|re.IGNORECASE)

sub_made = True
while sub_made:
        print "From:", str
        (str, sub_made) = re.subn(trimmer_re, '', str)
        print " to:", str

print str
[mysys]: 
[mysys]: ./trimmer.py 
From: A programme description [internal comment] with flags. (Ep1/7). [HD] [S] Followed by The News [AD,S] Then Reporting Scotland.
 to: A programme description [internal comment] with flags. (Ep1/7). [HD] [S] Followed by The News 
From: A programme description [internal comment] with flags. (Ep1/7). [HD] [S] Followed by The News 
 to: A programme description [internal comment] with flags. (Ep1/7). [HD] 
From: A programme description [internal comment] with flags. (Ep1/7). [HD] 
 to: A programme description [internal comment] with flags. (Ep1/7). 
From: A programme description [internal comment] with flags. (Ep1/7). 
 to: A programme description [internal comment] with flags. (Ep1/7). 
A programme description [internal comment] with flags. (Ep1/7). 
[mysys]:

 

[leshay]

Hi
Yes, I realize that it can of course be taken care of, but knowing what to deal with in an example case is one thing, it's the unexpected formats that are sure to crop up that will be the headache ones.

I know the descriptions need to be different for comparisons, but that example was just to show an anomaly. It is impossible to make an autotimer for some of the programmes based only on title and description where they are identical - typically daily shows. Knowing they are daily shows is one thing, but where you have them on multiple channels (+1's for example) really does throw a curve. I have found that one of the programmes I repeatedly get an autotimer failure on (Daily Politics) very often has the same tile/description on successive days and the second one will undoubtedly fail.I get the same effect on Newsnight fairly frequently.

I gave up using autotimers on those due to the failures. Now, using manual timers, if I have a failure, it's down to me alone.

 

[birdman]

It is impossible to make an autotimer for some of the programmes based only on title and description where they are identical - typically daily shows. Knowing they are daily shows is one thing, but where you have them on multiple channels (+1's for example) really does throw a curve. I have found that one of the programmes I repeatedly get an autotimer failure on (Daily Politics) very often has the same tile/description on successive days and the second one will undoubtedly fail.I get the same effect on Newsnight fairly frequently

So you would want "only one timer in a 24-hour period starting from hh:mm" with a given Title (i.e. ignore the Descriptions, as they aren't discriminative).

 

[birdman]

So you would want "only one timer in a 24-hour period starting from hh:mm" with a given Title (i.e. ignore the Descriptions, as they aren't discriminative).

Or, if the 24 hours were configurable too up to, say, 200 hours (1+ week) then it could also be used for my 7 Football League programmes in 36 hours.
It doesn't sound too problematic to code it....

 

[leshay]

Hi
Yes, using tour suggested method would work well for those items. The issue then becomes one of having 2 or more 'types' of autotimer, as only the human element can decide whether a particular programme is one of a general series, or one of the type you mention. Perhaps an AutoTimer (General) and an AutoTimer (Time Based)

 

[birdman]

Perhaps an AutoTimer (General) and an AutoTimer (Time Based)

No.Just like "Title + description(s?)" it would be "Title + timespan", so part of the same menu option. Just an additional option to the "Check for uniqueness in" option.

And the ? follows the s above, as "Title and Short description" and "Title and all descriptions" do the same thing. There is some code for testing long descriptions in AutoTimer.py, but that only runs:

if timer.searchForDuplicateDescription == 3:

which seems unlikely to ever be the case, given that AutoTimerEditor.py only has menu options to set it to 0, 1 or 2 and AutoTimerConfiguration.py has:

                if searchForDuplicateDescription < 0 or searchForDuplicateDescription > 2:
                        searchForDuplicateDescription = 2

 

[birdman]

No.Just like "Title + description(s?)" it would be "Title + timespan", so part of the same menu option. Just an additional option to the "Check for uniqueness in" option.

Actually it's more flexible (and slightly neater to code the menu display) to just add a timespan option for all Uniqueness selections and treat a zero one as "don't test".

 

[birdman]

It seems to be working....

Testing it on "Football League Tonight" (2 showings on each of C5, C5+1 and C5+24 - I haven't include the one on Spike).
The descriptions for the 6 broadcasts differ slightly (some have [S}, some do not) the descriptions week-on-week only differ by the episode number. So I can't discriminate by that.

Setting up a "timegroup" of 48-hours from 17:00 (which means, given any two start time, so back to the nearest 17:00 in the past, and consider 48 hours forward from there) I can discriminate. With the last two showing (22:00 Sunday and ~09:00 Monday) it will consider 17:00 Sunday to 17:00 Tuesday, so next Saturday's 21:00 is in a different group.

This is the log reports:

root@mbtwin:/media/usb/logs# fgrep -C2 'GML: [A'  Enigma2-12-12-2015_17-29-37.log
< 13055.232711> [eEPGCache] lookup events with 'FA Cup' in title (ignore case)
< 13055.821511> [eEPGCache] lookup events with 'Football League Tonight' in title (case sensitive)
GML: [Autotimer] Football League Tonight timegroup matches for (1449953820L, 1449957420)
[AutoTimer] We found a timer (any service) with same description, skipping event
[AutoTimer] Skipping timer because it has not changed.
GML: [Autotimer] Football League Tonight timegroup matches for (1450002720L, 1449957420)
[AutoTimer] We found a timer (any service) with same description, skipping event
[AutoTimer] We found a timer with similar description, skipping event
GML: [Autotimer] Football League Tonight timegroup matches for (1450040220L, 1449957420)
[AutoTimer] We found a timer (any service) with same description, skipping event
GML: [Autotimer] Football League Tonight timegroup differs for (1450558620L, 1449957420)
[TIMER] [AutoTimer] Try to add new timer based on AutoTimer Football League Tonight.
getResolvedKey config.usage.remote_fallback failed !! (Typo??)
--
< 13168.559172> [eEPGCache] lookup events with 'FA Cup' in title (ignore case)
< 13169.144306> [eEPGCache] lookup events with 'Football League Tonight' in title (case sensitive)
GML: [Autotimer] Football League Tonight timegroup matches for (1449953820L, 1449957420)
[AutoTimer] We found a timer (any service) with same description, skipping event
[AutoTimer] Skipping timer because it has not changed.
GML: [Autotimer] Football League Tonight timegroup matches for (1450002720L, 1449957420)
[AutoTimer] We found a timer (any service) with same description, skipping event
[AutoTimer] We found a timer with similar description, skipping event
GML: [Autotimer] Football League Tonight timegroup matches for (1450040220L, 1449957420)
[AutoTimer] We found a timer (any service) with same description, skipping event
[AutoTimer] Skipping timer because it has not changed.

where it added the timer for next Saturday (which the "normal" autotimer, using descriptions, can't do).

It's run twice (not sure why) and on the second pass it skipped the newly added one.
And that newly added one was correctly added as disabled, as it clashes with other recording next Saturday (but I can fix that manually).

So, all looking good. Just need to review the code and remove the unneeded print statements I have for debugging.

 

[birdman]

Just need to review the code and remove the unneeded print statements I have for debugging.

Which revealed a few oddities. (such as in one place commenting out my edited line, rather than the original, which produced odd warnings...).

The base time for timegroups has also changed - it now goes back to the preceding hh:mm on a day that a recording is allowed (which makes more sense, and is far more useful).

The trimFlags option is still there - as just removing trailing
[*] items. Also handling "then ..." and "Followed by" in the code was going to be English-specific, which wasn't on. However, it should be possible to also have a user-configurable list of word that could start such items, which would avoid that issue. I only thought of that a few minutes go, so it's not in the current code.

Speaking of which, the current code is at:

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

under Experimental/variableUniueness

 

[leshay]

Hi
After a few test runs, I believe that the VIX software is completely unaware of any 'seconds' added/removed from Timer start/end times. It would appear to round down to nearest minute. So, if I want to adjust my Timers enough to avoid simultaneous start/end times being treated as conflicts, then I would need to deal only with 1 minute add/subtract to adjust those timer conflicts.
(copied over from wrong thread)

 

[birdman]

Hi
After a few test runs, I believe that the VIX software is completely unaware of any 'seconds' added/removed from Timer start/end times.

Which sort-of makes sense, as no broadcaster uses them.

So, if I want to adjust my Timers enough to avoid simultaneous start/end times being treated as conflicts, then I would need to deal only with 1 minute add/subtract to adjust those timer conflicts.
(copied over from wrong thread)

Actually seeing what happens if end == next begin were not treated as an overlap might be an option too, but since one timer has to shut-down and release the tuner before then next one can successfully start up and claim the tuner there could be a timing issue there resulting in it working sometimes and not others.

 

[leshay]

Which sort-of makes sense, as no broadcaster uses them.

Yes, I fully agree, but without knowing what the PVR software can/does handle, I gave it a try out.

Actually seeing what happens if end == next begin were not treated as an overlap might be an option too, but since one timer has to shut-down and release the tuner before then next one can successfully start up and claim the tuner there could be a timing issue there resulting in it working sometimes and not others.

Well, I'm sure that if end == next begin, then presumably, the same tuner can be made continuous with only the redirection of the stream to a new file? Maybe, maybe not, but it would seem logical.

 

[leshay]

Hi
Well, yet another stupid EPG craziness. Tonights (Thurs) EPG has Newsnight with differing descriptions - same 'episode' - one has 'Followed by weather' the other has 'Followed by national weather'. It is indeed no wonder that the VIX software can't cope with similar/dissimilar episodes etc.

Is there anywhere on the PVR that the EPG is held in decompressed/readable format at all? Does the 'over-air' EPG carry anything at all relevant to series linking? Where does the 'over-air' EPG come from? Where does the PVR EPG programme ID come from - is it just an auto-incremented number added to the data or is it incoming from the 'over-air' EPG. In any case, the ID number seems to be irrelevant (except possibly as an event ID)?

I now have both a PVR EPG based application and an Atlas based application (that provides everything needed), but there are so many differences from the PVR supplied EPG data that I can not link one to the other. It is so frustrating to be so close yet so far!

 

[ccs]

I've never understood why epg episode crid data isn't available. It can't be too difficult to implement, surely?

 

[leshay]

Hi
I suspect that CRID data isn't supported (is it in the EPG data at all?) is that the VIX software is built for an international user base rather than a UK base.

 

[ccs]

It'll becoming thru' along with all the other freeview eit data.

 

[leshay]

Hi

Unless someone with better knowledge than me drops bye to confirm that, then I will reserve judgement. I would also have thought that the CRID data is present but unused.

 

[ccs]

Hi

Unless someone with better knowledge than me drops bye to confirm that, then I will reserve judgement. I would also have thought that the CRID data is present but unused.

You've lost me a bit there.

Series Link is broadcast on freeview and freesat (and sky as far as I'm aware.)

I've been using it successfully for 7 or 8 years on other PVR's, the crid data is coming down my aerial and VIX chooses to ignore it.

 

[leshay]

Hi
Yes, that is what I meant as well.

 

[judge]

Hi
Well, yet another stupid EPG craziness. Tonights (Thurs) EPG has Newsnight with differing descriptions - same 'episode' - one has 'Followed by weather' the other has 'Followed by national weather'. It is indeed no wonder that the VIX software can't cope with similar/dissimilar episodes etc.

How are you setting your auto timers? Changed any image defaults?
Never had this issue.