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

[Devin Heitmueller]

On Mon, Dec 21, 2009 at 1:44 PM, Bill Bogstad <bogstad at pobox.com> wrote:
> On Mon, Dec 21, 2009 at 1:09 PM, Travis Tabbal <travis at tabbal.net> wrote:
>>
>>
>> On Mon, Dec 21, 2009 at 10:34 AM, Bill Bogstad <bogstad at pobox.com> wrote:
>>>
>>> <RANT>
>>
>>
>> Really? I found it quite simple to set up. Part of that, in my case, is that
>> I'm using ATSC, not cable. Comcast seems to go out of their way to make life
>> difficult for people that aren't using one of their boxes. I told it what
>> tuner I have, did a channel scan, and off to the races. Really, the TV
>> recording config for the backend was the simplest part for me to set up.
>
> 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?
>
>> I agree that the docs could use improvements, but most of the things you
>> complained about sound to me like they fall on Comcast, not Myth. Myth
>> simply doesn't have the necessary data to map the channels properly, so
>> various people have tried to hack around the problem. My wife still misses a
>> couple cable shows, but we just get them on DVD. That seems to make her
>> happy and we save a lot of money. I'd be willing to pay for Comcast if they
>> worked properly with Myth, but as they refuse to be reasonable, I see no
>> reason to keep paying them $100/mo.
>
> 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.
>
>>
>> The SD/HD thing is an area I can see people being irritated, but it seems to
>> me that adding the code to deal with it takes devs away from more important
>> matters for something that will have very limited usefulness. As HD capable
>> FE machines drop below $200 and SD phases out, it doesn't make much sense to
>> me to spend the time on it. I see not wanting to buy new hardware, but it's
>> not like we didn't all have fair warning that the DTV changeover and HDTV
>> were coming.
>
> 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.
>
> Bill Bogstad
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

Patches are always welcome - when you find some case where you have a
problem, take the time to debug and figure out what is causing it, one
should be asking him/herself, how can I avoid others having the same
problem?  In many cases, it means adding an error message dialog,
improving documentation, etc.

If the situation bugs you enough, pick the one problem that bothered
you the most, and figure out how to fix it.  Bitching and moaning that
the current developers aren't doing a good enough job (when they are
working for free) isn't particularly productive.
Patches/Fixes/Documentation are what *is* productive.

We've got more than enough people out there willing to offer critiques
about what can be improved, and very few willing to actually help out
by doing something about it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com