Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: Vox and EPG: A summary to the situation



_cooper_ wrote:
> 
> Hello,
> 
> it took longer than I expected, but here the latest details to what is going
> on with my efforts to get a clean EPG on Vox.
> 
> Vox and the whole RTL group will change the data link to SES from beginning
> 2003, instead of using a TV archive there will be a direct line from Colonge
> to Luxembourg. Because of this, Mr. Indek (my contact to Vox) cannot do
> great efforts to reach changes in the EPG that will last for 2 or 3 month.
> 
> There will be a round table in November 2002 with all the responsible people
> from the RTL group, I hope to get an invitation so I can present the view of
> the customers/viewers. Perhaps I can help that all stations will have a
> useable EPG in the future, but I fear I have to read a lot more of EPG and the
> technical backgrounds... do you have any suggestion for a good document?
> 
> Since next year we will have to work with the EPG of Vox as it currently is.

I believe (well, _hope_) you meant to write "Until next year..." - right?

> Klaus: Perhaps you could add the EPG parsing as you suggested some weeks ago?

Here's what I've implemented in VDR 1.1.10. It would appear to work rather nicely.
This is an addition you should be able to easily insert in the 1.0.4 code of
VDR/eit.c as well. Note that I've also modified the bugfix stats count, but that
doesn't change the effect.

@@ -485,6 +485,32 @@
   // EPG data. Let's fix their bugs as good as we can:
   if (pTitle) {
 
+     // VOX puts too much information into the Subtitle and leaves the Extended
+     // Description empty:
+     //
+     // Title
+     // (NAT, Year Min')[ ["Subtitle". ]Extended Description]
+     //
+     if (pSubtitle && !pExtendedDescription) {
+        if (*pSubtitle == '(') {
+           char *e = strchr(pSubtitle + 1, ')');
+           if (e) {
+              if (*(e + 1)) {
+                 if (*++e == ' ')
+                    if (*(e + 1) == '"')
+                       e++;
+                 }
+              else
+                 e = NULL;
+              char *s = e ? strdup(e) : NULL;
+              free(pSubtitle);
+              pSubtitle = s;
+              EpgBugFixStat(0, GetServiceID());
+              // now the fixes #1 and #2 below will handle the rest
+              }
+           }
+        }
+


> There are two basic formats, one "correct" and one "simplified". It's
> currently not fully clear how there can be correct EPG entries at all, because
> SES claims not to be able to generate such entries ;-)
> 
> The "simple" entries allways will have this format, which will (says Indek)
> not change till the big change next year:

And once they change it, will it become *better*??

I really wonder what's so hard about doing this in a way that is really *useful*.
The user, IMHO, wants the title in the <title> field, the episode name (or whatever
short description is available) in the <subtitle> field (which, I believe, is not
well named, since it has nothing to do with "subtitles"), and whatever additional
information is available in the <extended description> field.

> In the title field:
>   <title>
> In the subtitle field:
>   (<country>, <year> <length>') Von <name>, <name>, ..., <name>. Mit <name>,
>   <name>, ..., <name>. "<subtitle/series title>". <description>

This is about as bad as it can be done - mixing several kinds of information
in one field. This field should *ONLY* contain the episode name (or equivalent
information).

>...
> I think it's not too difficult to do with this format for some month, perhaps
> we get a better EPG then. I'll stay in contact with Vox and keep you up to
> date from time to time.

Thanks for your efforts - it's good that at last somebody has made contact with
people who actually can _do_ something about this.

As far as I understand it, the EIT nomenclature speaks of four text fields that
are of interest here:

- ShortName
- ShortText
- ExtendedName
- ExtendedText

Apparently ShortName is where all stations agree that the title of a broadcast
shal go, and that works ok.

ShortText is where the episode name of a series should go (without any quotation marks
or preceeding it with the title), or where a very brief characterization of this
broadcast should be placed. VDR will use ShortName and ShortText to form the
recordings name, so that the user will be able to have a directory containing
the correctly titled episodes of a series. Of course this can only work if
the episode name is placed as expected.

ExtendedName can be used for any kind of additional information, like a summary
of what this broadcast is about, who stars in it, the director's name and stuff
like that.

ExtendedText is apparently never used - or at least it was never used up to
201-09-22 (see the comment in eit.c marked with that date). I don't know if
it has been used in the meantime.

So, when you get the chance to talk to somebody in charge of EPG data, please
make them understand that we need the title and episode name clearly separated
(from each other and from other data) in order to nicely set up the recording
directories - and also to present a useful channel display (What's on now/next).
The user needs to know which episode of a series is running next - not a lengthy
list of names, the date when the movie was made, and whatever other stuff they
list _before_ finally getting to the episode name, which by then may even not
be displayed any more because there's no more space.

ShortText and ShortName should also be considered *single line* entities, and
they shouldn't exceed 40-50 characters. The Extended* fields can contain more
text, but they shouldn't make any asumptions about the with of the display (*NO*
newline characters!).

For more about what's wrong with the EPG data on the several channels please take
a look at VDR/eit.c, function cEventInfo::FixEpgBugs().

Well, these are just a few thoughts. Maybe they can help making the EPG a useful
thing ;-)

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index