[mythtv-users] EIT vs XMLTV - Formula 1 and adhoc rescheduling

belcampo belcampo at zonnet.nl
Thu Jun 16 08:44:16 UTC 2011

On 06/16/11 09:51, blind_Pete wrote:
> On Thu, 16 Jun 2011, Nick Rout wrote:
>> On Wed, Jun 15, 2011 at 9:06 PM, John Veness
>> <John.Veness.mythtv at pelago.org.uk>  wrote:
>>> On 14/06/2011 23:45, Richard Morton wrote:
>>>> I have been using EIT since starting with Myth a few years ago now
>>>> (thanks - and congratulations - for putting up with me for so long).
>>>> I have been toying with using xmltv for the superior data that is
>>>> supplied by xmltv radio times feed in the UK, this weekend changed that.
>>>> Because the Canadian Grand Prix went on for hours longer than expected
>>>> during the transmission they rescheduled, first extending the broadcast,
>>>> then moving it from BBC1 to BBC2. MythTV worked flawlessly picking up
>>>> the extensions and then newly scheduled programme on BBC2.
>>>> XMLTV just couldnt do that with its current implementation in MythTV.
>>> As a XMLTV Radio Times user, I agree that it is not great for
>>> last-minute changes like the above. I was watching my recording of F1
>>> just a few minutes behind live, so I could keep up to date with the
>>> channel changes, but that was just luck. The BBC in the past have even
>>> changed some sporting things, such as Wimbledon matches featuring UK
>>> players, from BBC2 to BBC1, just when they start getting exciting, in
>>> order to gain a bigger audience!
>>>> It seems to be that simple matching of xmltv id and programme based on
>>>> start/end date and time using the xmltv guide to update the other
>>>> attributes such as title, subtitle, description and whether it is a
>>>> repeat or other pertinent details. I just looked at the radiotimes feed
>>>> and was surprised to see that the url is xmltv.radiotimes.co.uk..... but
>>>> the file is actually csv format. Maybe I am looking at the wrong file?
>>> You're looking at the correct file. My understanding is that the files
>>> from xmltv.radiotimes.co.uk aren't actually directly in XML format, but
>>> they have been put there for the benefit of the XMLTV project (and XMLTV
>>> end-users), hence the URL. They need post-processing by the
>>> tv_grab_uk_rt program before becoming XML.
>>>> I remember seeing mike mention there are challeneges with merging the
>>>> data but I am happy to work through the logic required if there is
>>>> appetite from the developers or other contributors as coding it to a
>>>> reasonable standard would be a serious challenge!
>>> I would be very happy if MythTV could use both XMLTV (for its better
>>> long-term data and better descriptions) and EIT (for last-minute
>>> changes). In fact, a few years ago I'm sure it did do that reasonably
>>> successfully, but maybe that was just a fluke.
>> Conflict handling will always be an issue. what if mythfilldatabase
>> does a run right in the middle of F1 and undoes the EIT stuff?
>> Confusion abounds.
> That is an interesting problem.
> I'm twisted, I like interesting problems.
> First up; TV stations will always do something interesting.  The best that you can hope for is robust sensible heuristics.  TV executives just might consider that shooting the president of the US is more important than /Dr who/.  There is a legend about the very first episode and JFK.
> For some channels, or some countries, the EIT data is just not to be trusted.  There is a channel by channel configuration option to ignore it now.  You don't have to subscribe to a paid TV guide if you don't want to.  So far so good.  The EIT data seems to be reasonably accurate and good for about eight days here.
> Next problem, even if you only have *one* data source, how do you handle updates?  Accept them?  Ignore them?  Do the best you can, and request human confirmation?  That is the "easy" problem.
> Multiple sources are more interesting.  You could rank them, "only use source C if nothing else is available".  Perhaps, source A can override source B, but not the other way around.  Perhaps, newest data overrides older data - this one appeals to me.  Could the strategy be configurable?
> When a sporting event has been moved (past tense) from one channel to another when mythfilldatabase is run mid show the *best* result would be to record the second half from the new channel.
> If the unexpected happens, an Englishman does well at Wimbledon, and the broadcast is moved from BBC2 to BBC1 then most English would probably want MythTV to record BBC1 instead of BBC2.  New strategy; try to record both, inform the user that something strange is happening, and generate an automatic rude email to send to the BBC.  ;-)
I'm using a brute force solution to this. Record all relevant muxes, 
just a matter of disks and dvb-cards, always have everything, 
bullet-proof solution.

More information about the mythtv-users mailing list