[mythtv] [PATCH] More improvments to guide fixup

[Torbjörn Jansson]

mythtv-dev-bounces at mythtv.org <> scribbled on Saturday, February 19,
2005 1:12 PM: 
> Torbjörn Jansson skrev:
>> * Adds new members in class Event so fixup functions can insert
>> original air date and credits (actors, director(s) and so on)
> 
> There is a special format in the "extended event descriptor"
> for actors
> and stuff, but currently we're not parsing it but just dumping it all
> into the description string. Do you think this is what you
> have?

Maybe it is, the actor/director stuff is easy to read, as if it was inserted
in the description to be easily parsable.
It's lists separated by 2 or more spaces in a row.

> In that
> case it would be better if you could do that parsing directly in
> ProcessExtendedEventDescriptor instead.

I guess i'll have to take a look at that function and see if i can improve
things.

> BTW, we should also handle
> segmented extended decriptors by concatenating them but
> that's another
> story.

I guess this is why some long descriptions looks as if it has been cut off?.

>> I have an idea on how to move the subtitles from the description to
>> the subtitle field, but this will only be posibel on some channels.
>> So i need some kind of list of channels (serviceid maybe?) that i
>> can do this on. It woud be best if this was not hardcoded, maybe the
>> dtv_private types table coud be used? Any ideas? 
> 
> Private table is probably the place for it, but is it really
> necessary? Wouldn't it be possible to just test for it?
> 

Test how?
The reason i wanted it to only parse subtitles for some channels is because
it might do the wrong thing for some channels.

My idea is to do something like:
Find first ". " everything before this shoud be the subtitle.
As a safety, check that the subtitle is shorter than the rest of the
description.

This woud work just fine for discovery channel and most other, but take for
example Hallmark.
Trying to do this for hallmark woud cause some realy wierd subtitles and i
don't think they woud be of much use.

I can't think of any obvious way of differenciating the two cases without
checking what channel it is.

> The EIT code is already pretty hard on the CPU (it processes tons of
> events per second) so please keep this in mind when adding
> extra stuff. :)

Ok, will do.
But i run with a fast cpu so i might not notice it.