Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[GiGaBlue QUAD+ PLUS] AutoTimer Uniqueness

leshay

New member
Joined
Sep 6, 2014
Messages
289
Reaction score
0
Points
0
Location
Livingston, Scotland
Hi

How does the system cope with an AutoTimer set for a daily (mostly) programme when the title and description may sometimes be identical? Are there other factors used by the system to differentiate one from the other, or, as I think is happening, the newer (but identical title and description) programme is being ignored as far as the AutoTimer is concerned.

One example of this is the 'Daily Politics' on BBC, where they quite often just have generic basic descriptions, and of course, the title is always the same.

I had stopped using AutoTimers for this (and a couple of others) due to missing some, and just used manually set Timers. I retried using AutoTimers recently and had the same occasional missed programmes.

Isn't it a pity that the EPG doesn't use/have a unique programme ID system (such as the UK CRID system).
 
Hi

How does the system cope with an AutoTimer set for a daily (mostly) programme when the title and description may sometimes be identical?
It copes fine.
One of the options when setting an auto-timer is whether to check for unique descriptions. By default it is off, so it would record all instances. if you switch it on then it would only set up one recording (which may not be the first one - there coudl be clashes for that).
For instance, I record The Football League on Channel 5 on Saturday evening. I have that auto-timer set to record on Ch5, Ch5+1 and Ch5+24. So I have set that the description must be unique (so ony 1 will ever be set at a time). This usually clashes with other recordings at the time. So if the Ch5 one is set and I have clashes, I disable that and re-run the search. It will then set the Ch5+1 one. If there is still a clash then I'll disable the Ch5+1 one and re-run. At that point it will (probably) pick up the Ch5 re-broadcast at 9am the following morning.
Once it's no longer got clashes I can delete the disabled timers.

I also have my config set to add a disabled timer on clashes, and disabled timers to show at the end of the timer list. So I can always see if I have clashes, what they are and do something to resolve them.

Are there other factors used by the system to differentiate one from the other, or, as I think is happening, the newer (but identical title and description) programme is being ignored as far as the AutoTimer is concerned.
It can be, but by default all of them should be recorded. if you want one-per-day of something with multiple broadcasts a day then you can probably add a time filer.
Isn't it a pity that the EPG doesn't use/have a unique programme ID system (such as the UK CRID system).
Agreed, but it doesn't. And if it did you can guarantee that the satellite ones would be different to the terrestrial ones and likewise the cable ones, and so it wouldn't be of any use to people with mixed tuners.
 
Does anyone know if crossepg is still being developed? if so is there a way to request new features? - i can only see an archived google code site

(i don't have the skills to make changes myself)

Even if the constraint was that you could only use it per tuner (i.e. sat, cable or terrestrial) it would be very helpful.
 
It copes fine.
One of the options when setting an auto-timer is whether to check for unique descriptions. By default it is off, so it would record all instances. if you switch it on then it would only set up one recording (which may not be the first one - there could be clashes for that).

Hi
Yes, I am aware of the unique descriptions etc and already had that set up for the example I mentioned (Daily Politics), restricting to one channel and no other timers in same period.

Another thing I forgot to mention in OP. On one or two of those occasions where I noticed a Timer for the programme hadn't been set, I tried all sorts of things to make the AutoTimer 'find' the 'episode' - even as far as deleting the AutoTimer and recreating it afresh (on the same 'episode' that wasn't found - and the new Auto\Timer still wouldn't find it. (again, there were no clashes to account for this)

Talking about the Options for Uniqueness. If a programme has the exact same title and description, then those settings would be redundant in of themselves - there has to be something else used to add uniqueness (bearing in mind, the 'Daily Politics' time slot does vary quite a bit at times.)
 
Found this for anyone interested
Code:
http://www.drm.org/wp-content/uploads/2012/10/XML-Specification-for-DAB-Electronic-Programme-Guide.pdf


Hi

Thanks for that. A long dry read, but brief scan through entire document seems to provide the information to support the 'uniqueness' case. CRID information seems to be very well supported in the specifications and should provide well segregated Timers.

I am not very well versed in XML, just delving into it in small doses from time to time. That document is extensive and I would imagine I would struggle to follow everything.

Does the EPG that the Enigma 2 based receivers use follow the outlined specification in that document? If so, then from my brief reading, there should be no problem in the Enigma 2 boxes finding the 'uniqueness' from the "id" and "CRID" EPG data transmitted.

Of course, the data transmitted is only as good as the data supplied from the various providers. As was the case with my old receiver which did use the CRID data extensively and was frequently upset by the provider not maintaining the CRID data thoroughly (or at all in some cases).
 
CRID information seems to be very well supported in the specifications and should provide well segregated Timers.
"should" being the operative word. In practice broadcasters don't always get it right. And once you are on to multiple repeats then all bets are off.
 
"should" being the operative word. In practice broadcasters don't always get it right. And once you are on to multiple repeats then all bets are off.

Hi
I agree and already stated the broadcasters/providers in some cases are/were sadly lacking in the maintenance of the CRID data. However, most of the EPG data and CRID data was well maintained and did provide very good accuracy and tracking of repeats right through a series, and I didn't get same channel or cross channel repeats being recorded. A few of the channels were slow to add the necessary data to the EPG though and in those cases, the box dealt reasonably intelligently with them.
 
Hi

Further to the issue of uniqueness - I have been experimenting with the various data supplied via the webIF API, and have a question that some learned soul may answer for me.

I had thought, from previous posts in this thread that the ID was in some way connected to the way that the VIX software sorted out the linking of programmes for such things as Autotimers etc.

However, I have found that the eventID's as found from the webIF API can not be used for such things as these ID's are used multiple times for non-related programmes (attached example of one or two - there are very many of the same)

So, this means there is nothing that can be used externally to differentiate between linking (say) a group of programmes in a series other that comparing titles and descriptions. A pity, as using just those criteria means that a series would be practically impossible to sort out as the descriptions of the same episodes do vary quite often.

Anyway, I don't know if the webIF can be coaxed to supply some other means of identifying such uniqueness or not, but this post is a request for something like that please.
 

Attachments

So, this means there is nothing that can be used externally to differentiate between linking (say) a group of programmes in a series other that comparing titles and descriptions. A pity, as using just those criteria means that a series would be practically impossible to sort out as the descriptions of the same episodes do vary quite often.
Really? I see the same descriptions for the same episode at differing times.
I actually have a reverse problem in that the uniqueness isn't actually uniqueness but non-similarity, and successive episodes of one series I record are unique, but quite similar. So the next episode won't show up as a timer until I delete the previous week's timer (which I can't do until all of its repeats have been broadcast). So I'm thinking of looking into making the similarity rating (71%) be configurable per auto-timer.

Anyway, I don't know if the webIF can be coaxed to supply some other means of identifying such uniqueness or not, but this post is a request for something like that please.
It's not specific to WebIF - it is just a front-end to the standard Enigma2 timer setting.
 
Really? I see the same descriptions for the same episode at differing times.
I actually have a reverse problem in that the uniqueness isn't actually uniqueness but non-similarity, and successive episodes of one series I record are unique, but quite similar. So the next episode won't show up as a timer until I delete the previous week's timer (which I can't do until all of its repeats have been broadcast). So I'm thinking of looking into making the similarity rating (71%) be configurable per auto-timer.

It's not specific to WebIF - it is just a front-end to the standard Enigma2 timer setting.

After some testing, I see that the descriptions will quite often carry the '[HD]' text, so the same repeated episode on SD channel differs from the one on a HD channel. At least, in the testing I have done today - I feel sure I have seen other differences too where an episode carries the episode number in the description but not in a repeat description.
 
After some testing, I see that the descriptions will quite often carry the '[HD]' text, so the same repeated episode on SD channel differs from the one on a HD channel.
But since the required similarity is only 71% then I wouldn't expect "Also in HD" vs "[HD]" to stop the check working (although I've never set up a timer for both an HD and an SD channel).
 
Hi
If I want to find any other programmes matching one I have set a Timer for (I mark same episodes as already on a Timer), or, I want to find non-same episodes, at the moment, I am having to use (as an example), :

If Trim(i.desc.Replace("[HD]", Nothing).Replace("[AD,S]", Nothing).Replace("", Nothing).Replace("[AD,S,SL]", Nothing).Replace("[S,SL]", Nothing)) = Trim(p.desc.Replace("[HD]", Nothing).Replace("[AD,S]", Nothing).Replace("", Nothing).Replace("[AD,S,SL]", Nothing).Replace("[S,SL]", Nothing)) Then

where i and p represent and EPG items with (among others), the .desc property.

Rather unwieldy at the moment, but at least working, with the restraints that I only have the .title and .desc fields to try and differentiate episodes.
 
I actually have a reverse problem in that the uniqueness isn't actually uniqueness but non-similarity, and successive episodes of one series I record are unique, but quite similar. So the next episode won't show up as a timer until I delete the previous week's timer (which I can't do until all of its repeats have been broadcast). So I'm thinking of looking into making the similarity rating (71%) be configurable per auto-timer.
And I've just discovered that it is not only waiting and completed timers which are checked, but also existing recordings.
So I was in the position of having missed a recording of a new episode as I hadn't actually watched last weeks (I had deleted the completed timer for it), and the descriptions were similar but different - but not sufficiently different.

So coding for a variable similarity score per- autotimer starts now....
 
And I've just discovered that it is not only waiting and completed timers which are checked, but also existing recordings.
And now further discovered that checking the recordings in configurable.
So coding for a variable similarity score per- autotimer starts now....
Basically done. Just needs tidying up (possibly - at least removing the trace and debug statements) and checking.

As an example of what I have to be able to differentiate, this is the description of successive (so different) weekend descriptions of the Football League show:
  • Kelly Cates and George Riley present highlights of today's action from the SkyBet Championship, League 1 and League 2, with special guests on hand to give their reaction. (S1 Ep 18)
    [*]Kelly Cates and George Riley present highlights of today's action from the SkyBet Championship, League 1 and League 2, with special guests on hand to give their reaction. (S1 Ep 19)

They are 99.46% similar - but crucially different. Repeat showings of the same instance all have the same description (there are 6 showings - wait, there are 7! It's on Spike too!)
 
Arrgggghhh!!!!
Having activated it I now see that some of the showing have the at the end and some do not.
More thinking needed....(perhaps strip trailing [] flags before testing...)
 
Arrgggghhh!!!!
Having activated it I now see that some of the showing have the at the end and some do not.
More thinking needed....(perhaps strip trailing [] flags before testing...)


Hi
Yes, I already found that issue and posted above about using:

If Trim(i.desc.Replace("[HD]", Nothing).Replace("[AD,S]", Nothing).Replace("", Nothing).Replace("[AD,S,SL]", Nothing).Replace("[S,SL]", Nothing)) = Trim(p.desc.Replace("[HD]", Nothing).Replace("[AD,S]", Nothing).Replace("", Nothing).Replace("[AD,S,SL]", Nothing).Replace("[S,SL]", Nothing)) Then

in testing to deal with it.
 
I'm using a regular expression recursively to remove all
[*] sections from the end of a string....with usage optional by autotimer. Nearly there (I hope...).

Code:
        import re
        trimmer_re = re.compile('\[[^[]*?\]\s*$', flags=re.UNICODE)
        def flag_trim(text):
                sub_made = True
                while sub_made:
                        (text, sub_made) = re.subn(stripper_re, '', text)
                return text
 
Hi

How on earth to deal with these stupid appended strings! Enough to make you sick! All well and good if there is a '[]' block to index to, but what if not and they tag on some stupid ending!

The One Show start = #12/8/2015 7:00:00 PM#
desc = "If it's got Britain talking then it will get talked about on The One Show. Presented by Matt Baker and Alex Jones. [HD] "

The One Showstart = #12/9/2015 7:00:00 PM#
desc = "If it's got Britain talking then it will get talked about on The One Show. Presented by Matt Baker and Alex Jones. [HD] Then Reporting Scotland."
 
Ah. But those are different programmes, so it doesn't matter as you need the descriptions to be different!

Anyway - my code is up, running and has been left in place. It no longer produces exceptions.
Now I need to see if it will sort out my recording issues, which should happen on Friday and Saturday. Past ones have had to be dealt with by deleting finished timers and viewed recordings, so I can't do a "real" test yet.
 

OpenViX Feeds Status

Back
Top