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

[Travis Tabbal]

On Mon, Dec 21, 2009 at 11:44 AM, Bill Bogstad <bogstad at pobox.com> wrote:

>
> Do you use SchedulesDirect for listings?  If so, why did you decide to
> pick "-" rather then the
> more (to me) obvious "." as the channel seperator?  Should this be
> documented by MythTV
> or by SchedulesDirect?
>


Yes, I do use SD for listings. I don't recall ever changing the channel
separator, I probably just used the default. Everything mapped properly for
me, I haven't had to mess with XMLIDs or the like at all.



> A classic example of the "it's not really mythtv that is at fault"
> response.  It's some outside program or entity.  It may not be fair to
> MythTV to blame it for all of my problems, but end-users aren't going
> to care.  By the way, did you miss the part of my rant about nine
> submenus of undocumented pages of mythtv-setup's 'General' menu?  I
> forgot to mention in my original note about the fun I had when I was
> trying use user jobs to do transcoding for my MediaMVP and didn't want
> to use the built-in transcoding system because: 1) I didn't understand
> what it did.  2) I wanted to keep the original recordings around for
> when I got an HD capable FE.  Now why I wanted to keep two copies of a
> recording around wasn't directly MythTV related, but figuring out user
> jobs was.  I admit that this particular project was relatively easy
> compared to the ones I did list.
>


How is "It's not MythTVs fault that Comcast screws with channel mappings on
a whim" not a valid response? What, exactly, do you propose the devs do
about it? Do you know of a way to map that data programmaticly? If there is
a clean way to deal with it, by all means, write up a bug report and I'm
sure someone will look into it. I'm not a Myth dev and I haven't read that
code, so I can't really offer more than that.

No, I didn't miss that part, I simply didn't find the "General" menu
difficult to understand. There is help text in there, and google filled in
any missing bits I needed. I don't know about the transcoding bit, I never
bothered with that. I just used FEs that were capable of playing the
recordings I was making. I never did SD, I started using Myth when the HDHR
came out, so I have always worked with ATSC digital. Even HD MPEG2 isn't all
that difficult to play back, and I've never had a problem with those files.
If I were to try what you are talking about, I probably wouldn't use Myth at
all as it doesn't really seem suited to it. I'd just use the rename script
to give the files reasonable names and write my own script to transcode
them, keeping the originals around.


My change over from DataDirect? to SchedulesDirect was a BREEZE
> compared with the analog/digital and on much less warning for all
> concerned.  And if there was more modularity/documentation of
> interfaces in MythTV then on-the fly transcoding (for example) is
> something that a non-core developer could work on.  Yes, I know that
> there is/was? a project to work on this.  At least one of the ones I
> heard of had to do with the Iphone and the developer of that one
> decided to take a different route in the end and has stopped working
> on it.  That may be different then the one that was just posted about
> this week.
>


While that may be a valid point, perhaps those writing the code just aren't
that worried about that particular issue? Even the Linux kernel doesn't
maintain standard interfaces between versions, much to the dismay of some. I
will say that the few times I've been interested in something enough to dig
in the code, I've had little trouble finding the parts I was interested in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20091221/ab45eb10/attachment.htm>