[mythtv] Mythtv/DVB enhancements

Simon at the Threshold dweller at the-threshold.org
Wed Feb 11 08:04:35 EST 2004


Steve Davies wrote:
> On Wed, 11 Feb 2004, Simon at the Threshold wrote:
> 
> 
>>Hi there,
[snip]
>>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!

Indeed, its easy to get hacking its less easy to understand what been 
done and why and write sympathticly.. Still even the longest journey 
starts with the first step.


>>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.

These two seem easier then the next two, so I think I'll try them first. 
Seems reasonable that something at the mythfilldatabase does the 
conversion and that the entire description text is stored in the 
mythconvg database. So I'll see if I can't modify the recording menu and 
do a more elegant patch.

>>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 :-)

Indeed although I can't help thinking faking a stream is the long way 
round, probably better for the backend to tell the frontend there is no 
data stream.  We'll see


>>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)

Yes this one sounds like the mother of all changes.. Figures.. I think 
I'll leave off contemplating this one until I've mastered some more of 
the system.. (Learning to walk before I can run etc.)..


Thanks guys...



More information about the mythtv-dev mailing list