[mythtv-users] [RANT] mythtv-users] Deal with non-HD in SD only frontends?

Bill Bogstad bogstad at pobox.com
Mon Dec 21 17:34:33 UTC 2009

On Mon, Dec 21, 2009 at 9:53 AM, Greg Woods <greg at gregandeva.net> wrote:
> On Mon, 2009-12-21 at 09:43 -0500, Josh White wrote:
>> I'm not a coder, and since I was sick of the same problem, I made the
>> only change I could to make it work as I wanted, which was to upgrade
>> all my frontends computers to be capable of displaying HD content,
> I did this as well, and it didn't take that much. All I really needed
> was a VDPAU-capable PCI video card. This allows my little Celeron to
> display HD content letterboxed on my SD secondary TV just fine.

I've retired my MediaMVP (which was my primary front end) for the same
reasons. In my case, it couldn't handle the ac3 audio that was part of
the ATSC/QAM streams.  So I couldn't even use it for SD recordings
without transcoding everything.  From what I could tell about
transcoding, there was just no
way in MythTV to handle FEs which only do SD  without compromising the
output to FEs that can handle HD.


As for not being a coder, I find it hard to believe that people even
get MythTV to work over the long
term without having some programming experience.   Going through the
switch to digital only in the US;
I've spent way too much time digging into MySQL tables, scouring
obscure web pages for hints on why
mythfilldatabase wasn't importing listings from SchedulesDirect for my
OTA ATSC tuner, compiling the SVN version of scte65scan so I could
specify a mplexids base for my QAM tuners on Comcast, reading the
source for mythcommflag to figure out why it was taking so long when
the CPU was idle, delving into lirc to figure out how to get my remote
to work.

Now I expect to be told that some of this isn't part of MythTV, but a
real end-user doesn't care whose responsible for what part they just
want the whole thing to work.  But even the documentation for MythTV
proper is inadequate.   The official documentation for mythtv-setup:


has a few paragraphs for each of the top-level menu items.  Storage
Groups is the longest entry when it is in fact probably the most
straightforward of all.  The Channel Editor warrants a SINGLE
Even though the 'General' menu has 9 sub screens of obscure settings,
it gets only seven (short) paragraphs.

The next response I'm going to get is that I should contribute updates
to the documentation.  So
let's take my most recent problem with mythcommflag and the
JobQueueCPU entry in the settings table. I now have (some) idea of
what this entry does to mythcommflag.  Michael Dean informs me that
it is settable (to a restricted) range from one of those obscure
pulldown entries in a sub-menu of 'General'.  I still don't know to
what extent it may be used by other jobs that the mythtv scheduler
might run.  I have no idea if what it currently does is an accident of
the code or a deliberate design decision.
There is no programming documentation (contract) to specify any of
this.   And this is just one of probably over 100 settings under the
'General' menu which is poorly documented.

Most large software projects impose modularity and then document
interfaces.  In the case of MythTV, the most obvious places to do so
would be in the network protocol and in the MySQL database schema.
As far as  I can tell the network protocol has been best documented by
people who wanted to interoperate with MythTV. The database schema can
be found in the wiki, but some of the tables are not documented and
even for those that are many of the fields have no description.

As far as I can tell, fixing this situation would require me to read
and understand much of MythTV's source code.  It might be technically
possible for me to do so, but it would take way more additional time
then I have to spend on MythTV and I have little faith that as the
code changed that the documentation would be updated as needed by the
core developers.  So I took the easy way out
and posted what I found out about JobQueueCPU to this mailing list.
If the next person who has problems with mythcommflag being slow is
particularly good  with Google searches they might find that thread in
a mailing list archive somewhere.


If some poor unfortunate soul who can't get ATSC listings to import
from SchedulesDirect finds
this note, the solution is to set your ATSC separator to a dash "-"
not a period ".".  The only reference
I found to this is on a blog. http://murraysaul.wordpress.com/.

Maybe this would have been obvious if I had read the source for
mythfilldatabase and understood the magic by which xmltv listings and
channels are matched up.  I haven't found the documentation on this
either.  However, it does seem to come up on this list frequently.
You might be able to piece together a complete understanding by
reading multiple threads in the mailing list archive without resorting
to the source code.

Bill Bogstad

More information about the mythtv-users mailing list