[mythtv-users] [RANT] mythtv-users] Deal with non-HD in SD only frontends?
gull at gull.us
Mon Dec 21 18:18:16 UTC 2009
On Mon, December 21, 2009 9:34 am, Bill Bogstad wrote:
> 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...
Digital TV is just a CF all around. Part of the problem is the cable
companies, which don't want or care about interoperability. It surprises
me, though, that no one has come up with a good solution for OTA yet. Am
I right in thinking that it still requires filling out channel IDs by hand
to get it working with Schedules Direct?
I suspect part of the issue is that the whole concept of a channel number
has become very abstract in the digital TV era, since they're no longer
tied to specific frequencies. TMS (and by extension, Schedules Direct)
started out in the analog era and probably still revolves heavily around
channel numbers as unique identifiers.
> But even the documentation for MythTV proper is inadequate.
A common problem with open-source software. Open source software only
solves problems that someone finds fun to work on. Writing documentation
isn't fun. Worse, programmers usually particularly hate writing
documentation, and they're the only ones who know how the thing works.
This is a long way of saying that this is a long-standing complaint and I
doubt it will be fixed any time soon.
The de facto solution seems to be to rely on the mailing list as a sort of
living source of documentation. Ironically, this is way more
labor-intensive than writing actual documentation would be...
> 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.
I think the official position is that end users shouldn't be messing
directly with the database, anyway, so I doubt documenting it is high on
the priority list.
> 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/.
That seems like the kind of thing that ought to be tested for in the code;
it sounds like an easy, basic sanity check.
More information about the mythtv-users