View Full Version : [GiGaBlue QUAD+ PLUS] AutoTimer Uniqueness
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).
abu baniaz
18-11-15, 08:45
Found this for anyone interested
http://www.drm.org/wp-content/uploads/2012/10/XML-Specification-for-DAB-Electronic-Programme-Guide.pdf
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
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.
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("[S]", Nothing).Replace("[AD,S,SL]", Nothing).Replace("[S,SL]", Nothing)) = Trim(p.desc.Replace("[HD]", Nothing).Replace("[AD,S]", Nothing).Replace("[S]", 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) [S]
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) [S]
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 [S] 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 [S] 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("[S]", Nothing).Replace("[AD,S,SL]", Nothing).Replace("[S,SL]", Nothing)) = Trim(p.desc.Replace("[HD]", Nothing).Replace("[AD,S]", Nothing).Replace("[S]", 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...).
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] [S]"
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] [S] 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.
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]:
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.
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 frequentlySo 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).
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....
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)
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
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".
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.
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
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)
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.
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.
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!
I've never understood why epg episode crid data isn't available. It can't be too difficult to implement, surely?
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.
It'll becoming thru' along with all the other freeview eit data.
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.
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.:)
Hi
Yes, that is what I meant as well.
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.
How are you setting your auto timers? Changed any image defaults?
Never had this issue.The EPG description (sent by the broadcaster) is not a result of any autotimer setting by the user.
As has been noted before, some repeats of the same programme (re-broadcasts and/or different services) have different flags at the end, and sometimes different descriptions (e.g. SD == "Also in HD.", HD == "[HD]" at the end).
And different episodes of a programme may have the same (or very similar) description. e.g. successive episodes of "Football League Tonight" have a 99.5% similarity in their descriptions. So I won't get next-weeks timer set-up until this week's timer has been deleted, but for other programmes I have to keep the completed timer around for 7 days to stop it recording that programme a second time.
There are issues here, and several people are seeing them - the fact that you do not does not mean they they are not there.
There are issues here, and several people are seeing them - the fact that you do not does not mean they they are not there.
Agree, but still cant reproduce them.
Can you point to a show on a satellite that has these issues, in simple to follow instructions that has issues?
I must admit that I don't really totally understand the problem either.
For example, I have an autotimer set to record the evening edition of Look North for the weather forecast.
I get all 7 recordings every week, the weekday descriptions are all the same, the weekend ones vary a bit.
All 7 future timers are currently ready and waiting, and 3 completed timers are still showing.
Agree, but still cant reproduce them.
Can you point to a show on a satellite that has these issues, in simple to follow instructions that has issues?
Hi
In my case, I had autotimers set up for Daily Politics and Newsnight. Both had the odd missing recording. I eventually deleted these autotimers and started my own app to let me set timers. During development I found the issue surrounding same episode with different description and different episodes with identical descriptions.
If the VIX software is using only title and description to set timers for an autotimer, then it must be falling foul of this problem too, and may account for my original issues.
If the VIX software is using only title and description to set timers for an autotimer, then it must be falling foul of this problem too, and may account for my original issues.I'm working on that. In particular to discriminate by time period as well as description.
Can you point to a show on a satellite that has these issues, in simple to follow instructions that has issues?No.
We don't have a satellite - we have Freeview. So the EPG is sent by the broadcaster(s) and out of our control.
But if you look back though this thread you will find examples where multiple broadcasts of the same episode have slightly different descriptions and different episodes of a programme have (near) identical descriptions.
So if you leave completed timers around to avoid duplicate timers in one case, you prevent new recordings being added for the other.
Perhaps this has nothing to do with this issues.
A while back I by accident mixed 2 EPG providers. I am getting EPG from my cable provider and I also used Cross and Rytec to get the Rytec EPG.
I noticed that Program names sometimes where not the same, also on some channel the starting and ending time of the programs where different. I noticed the difference when my cable provider changed from EPG provider.
I can imagine that the autotimers have problems when you have 2 different program names in the EPG the same time.
There are several EPG providers for the same channels and the content can be different.
I must admit that I don't really totally understand the problem either.
For example, I have an autotimer set to record the evening edition of Look North for the weather forecast.The problem is to also not get them recorded when they are repeated. To do that you need to turn on uniqueness checking. And then you run into problems with getting only one recording (instead of one a day) as the uniqueness check will say that they are all the same.
The issue is all about being able to record one and only one copy of programmes which are repeated whilst ensuring that you do get one copy of each distinct episode.
PS: I now have code to make the uniqueness check percentage variable, allow you to strip flags (and any other user-configurable text) from the end of a description before doing the check, and also to define time periods such that if two programmes have the same description but fall into different time periods then they will be treated as different.
The latter two sets of fixes are interdependent, as the current code uses lists (numbered indices) for different filters rather than using dicts (named keys). It wouldn't be difficult (and would simplify all of the code) to switch to dicts (I think).
With all that in place I think i can discriminate most things...except it appears that descriptions are being truncated to 200 characters, so any episode numbers (say) mentioned beyond there have no effect...
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.