[mythtv] Longterm direction of eitfixup -- and some specific advice sought.

Daniel Kristjansson danielk at cuymedia.net
Sun Jan 3 05:16:26 UTC 2010


On Sun, 2010-01-03 at 01:05 +0100, Håkon Alstadheim wrote:
> Hi all, I must admit I don't follw this list too closely, so maybe my 
> question has already been answered. A google search or an URI in answer 
> to this mail will be well received.
> 
> I'm working on some eit fixups for Norwegian DVB-T, specifically the 
> free-to-air channels I recieve. I'm dispatching off the network ID for 
> everything, like so:
> -- from eithelper.cpp: --
>     // Norway
>     fix[8770U  << 16] = EITFixUp::kFixNO;
> 
> This may be too broad. May I just go ahead, and leave it up to others to 
> write a narrower entry? Might possibly move special cases out to a 
> "FixNRK",

Please make the fixes as narrow as possible, i.e. only for services
you've tested.

> but it looks as if the number of customizations in these files 
> is going to grow pretty fast as DVB is spreading around the world. Are 
> we just letting things grow out of hand until we have enough "raw 
> material" for building a few hard-coded rules, and  moving the rest off 
> to user-scripts? Having a "FixPerlEmbed" would seem like a logical route 
> to me.

We don't want user scripts, we want to encourage fixes to be contributed
to MythTV. We used to allow fixes to be user controlled, but then people
just kept them to themselves. These are also run rather frequently so
efficiency matters. QRegExp is based on Perl regular expressions,
writing a fix-up shouldn't be difficult for someone familiar with Perl.

> It is easy to get carried away when tweaking the EPG visual result and 
> balancing against the ease of use in making recording rules. Do I leave 
> stuff like "Film: " at the start of descriptions in, or is it better to 
> remove them? The result certainly LOOKS more pleasing without thos 
> textual markers, especially since mythweb color-codes movies anyway.

Better to remove them from the text and populate the appropriate fields
in the DB, like the genre in this case. That way scheduler search code
will work worldwide and UI features such as color coding by genre will
work.

> Will there be a consolidation effort on the fixup-code, so that I should 
> try to keep commonalities as separable stretches of code, or do I just 
> follow my instinct and twirl the spaghetty as tightly as possible around 
> my fancy of the day?

Always make the code as readable as possible, hopefully other people
will look at the code and improve it, and we also update code en mass
when the APIs we use change. For instance when we upgraded from Qt3
to Qt4. When that happens the person doing the code changes is likely
to be unable to test the changes against real data, so the more clear
the code is the better.

The fixups are one of the less nice parts of the MythTV codebase, mostly
because there are rarely multiple folks looking at the code once it is
committed. So if you want to look for how to do something properly it
may make sense to look in other files in libs/libmythtv. One thing
to keep in mind with QRegExp is that when you first create a regular
expression it needs to be compiled into a state machine which can
take some time, so it is best to reuse them as much as possible.
Otherwise the same things that are expensive in Perl, like capturing
expressions are expensive in Qt. QRegExp is not thread-safe, but you
do not need to worry about this in the fixup code. There is a nice
long writeup at http://doc.trolltech.com/4.4/qregexp.html

-- Daniel




More information about the mythtv-dev mailing list