[mythtv] Mythtv/DVB enhancements

Steve Davies steve at one47.co.uk
Wed Feb 11 05:43:53 EST 2004


On Wed, 11 Feb 2004, Simon at the Threshold wrote:

> Hi there,
>
> I recently subscribed to the mythtv-dev list as I would like to become
> more invovled in the mythtv development process.  Although oddly enough
> I'm still at the bottom of a nice steep ramp up on the codebase so its
> slow going for the time being.
>
> So I'm looking for advice and suggestions for getting into the code base
> and how I might implement the things I need to.

I know the feeling - I've been tinkering with the scheduler and with some
possible DVB enhancements, but it IS slow going. There is a lot of cool
code in there!

> Three items up for discusion
>
> The first one is the simplest I've seen this bug since 0.13 and it
> occurs on the simple recording menu off the epg. Basicly if the
> description text is too long it forces all of the useful buttons off the
> bottom of the visible screen (Things like Record once etc.).  My inital
> attempt to fix this was to truncate the description text to a safe
> ammount.  It occurs to me this is a bit of a botch fix?, if so any
> suggestions on a better fix and which area of the code I should ramp up
> first on? As an ammendment to this one I also notice that html &
> characters are sneeking into the descriptions which I assume are
> unconverted chars anyone know where this is supposed to be done?

Okay, I think that the unconverted characters are the responsibility of
mythfilldatabase - Once they are in the database, they should already be
as clean as they are going to get.

Same applies to truncation - This on the other hand is a display/rendering
issue, and would probably be best fixed by limiting the vertical size of
the text box on the screen to a certain %age of the screen height. Qt
should then clip, or perhaps scroll the overflow.

> Secondly since I have a marginal DVB-T connection I notice I get
> "no-dataed" quite a lot from the DVB driver. Saddly this causes the
> mythback to lockup (loop of death) and for the frontend to die in a xvmv
> assert. So I kind of figured it might be nice to harden that code to
> cope with missing data.  So how about a "lost transmission" error
> displayed on the mythfrontend instead?.  This appears to be quite a in
> depth fix so I'd appreciate any hints.. <Chuckle>

If you were to add a generic "transmission lost" screen, I think you would
become VERY popular - I always wondered whether it is possible to send a
fake MPEG2/MPEG4/RTjpeg packet to the frontend if no data is available...
Way beyond my skills though :-)

> Thirdly an enhancement to DVB, I understand that the DVB drivers allow
> for multiple streams to be read from the same frequency (ahh the joys of
> multiplexing). I guess it would be good enhancement for mythtv to be
> able to cope with this one. Bit of a mythtv expert change but I'd be
> interesting in hearing how it could be implemented?

Kenneth has already posted a prototype for this facility a while back -
Adding this feature would also require teaching the scheduler to handle
the availability of multiple channels from an input, and probably require
that DVB cards be treated differently than at present (probably so that
one DVB mux == one card input)

>
> Regards
> Simon
>

Just my 2c.
Hope that helps
Steve


More information about the mythtv-dev mailing list