[mythtv-users] Patching .21-fixes for HDPVR

[john]

On Dec 25, 2008, at 9:10 AM, Michael Tiller wrote:

> On Thu, Dec 25, 2008 at 10:22 AM, Robert McNamara <robert.mcnamara at gmail.com 
> > wrote:
> <discussion on patches removed>
>
> Please *do not* write any more documentation on taking this path.  If
> people want to do this, there's nothing we can do to stop them, but
> codifying it only perpetuates broken DBs.  It is a *good* thing that
> getting .21 working with the HD-PVR is hard/not well documented-- we
> want to *prevent this*.
>
> So please, please, *please*.  Don't do this, don't advise people to do
> this, and especially don't put anything like this on the wiki where it
> could be misconstrued as an endorsed plan of action.  We have had a
> near-identical problem when people enabled UTF8 in mythtv before
> trunk/.22.  There was documentation in the wiki about it, and it led
> to corrupt data because people followed it.  Mike Dean has spent the
> better part of the last two weeks working on fixes for this and
> similar issues.  That is a literal parable about the kinds of things
> that will happen if people start doing this.  It causes other people
> (who could be adding features) to waste valuable time trying to fix
> it, and speaking only for myself, causes massive frustration.
>
> As the author and "maintainer" of the HD-PVR wiki page, I will revert
> any change made that that page that includes instruction on this
> topic.
>
>
> For clarity, not jumping down *your* throat per se, but I feel the
> need to address this before it gets any more out of hand than it
> already is.
>
> Don't worry, I understand that you are trying to reign in the chaos  
> that such a situation could create and to prevent it from being a  
> distraction for others.  I certainly didn't take this as a personal  
> thing.
>
> I really have just two comments.
>
> First, I'm confused because as the maintainer of the HD-PVR page,  
> there is a whole section titled "Steps to Add the HD-PVR as a  
> Capture Device in MythTV" that discusses applying patches.  It isn't  
> clear to me why that section is superior to the patch set I  
> referenced (they may even be the same).  Do those patches not  
> trigger DB issues?  Should they be considered a preferred  
> alternative to the route I was looking at?



The patches listed on the wiki are *extensions* to the HD-PVR support  
which is currently *included* in trunk.  Those patches fine-tune a few  
aspects of the interaction with the HD-PVR driver, and make using  
LiveTV with the HD-PVR possible.  As a side note, they do *not* fix  
the problem with input-resolution changes, so you must still have your  
STB set to output a fixed resolution if you want to use LiveTV.  They  
do fix input resolution changes for recording.  When I have time  
(hopefully over these holidays), I hope to improve the patches listed  
on the wiki, and possibly get some of them committed to trunk.

The patches that Mark Buechler put together for 0.21-fixes are based  
off of the functionality which is already *included* in trunk.  As far  
as I know, it does not included the patches listed on the wiki.



> Second, this is a very interesting situation and I wonder what we  
> could learn from it.  On the one hand you have the trunk which has  
> all this nice functionality but there are "danger" signs posted  
> everywhere about using it.  There is also a very strongly vibe from  
> the developers (and *understandably so*) about non-developers  
> venturing into the trunk.  I can appreciate the trouble that causes  
> and so I agree nobody should take that route lightly.
>
> On the other hand, you have a strong sentiment to not provide a back- 
> port of these features to 0.21.  Philosophically, I can understand  
> this approach as well (not wanting to move backward but rather  
> forwards).  But this closes off another potential avenue to users.
>
> Finally, you have the people who (for example, with these patches)  
> are trying to "make due" until a new release by coming up with a  
> kludge applies "on the side".  This approach is also frowned upon  
> (for reasons you pointed out).
>
> The result of this situation is that it seems to create tension  
> between the developers who, naturally, want to focus on moving  
> things forward rather than hand holding and users who, naturally,  
> want to get the most of out their system.  The downside of this  
> situation is that you have users with lots of enthusiasm for the  
> overall project and a willingness to spend not insignificant amounts  
> of money on putting together systems met with what probably feels to  
> many like a sentiment of "sit down, be quiet and wait for the next  
> official release".  I want to be clear that I don't see anybody at  
> fault here but it just seems like a shame to be in such a situation.
>
> So the question is...is there any strategy we could follow that  
> would avoid this situation and make things easier for both parties.   
> I'm not sure there is but I figured it was worth considering.
>
> I'm still not sure where this leaves me... :-(



Do you currently check-out, build and run the code from 0.21-fixes?   
If so, then you at least have the basic rudimentary skills to use  
trunk.  There are *many* changes from 0.21-fixes to trunk -- one of  
the biggest being the switch from QT3 to QT4.  If you want to try  
trunk, I would start by installing the latest-greatest version of  
Fedora or Ubuntu since they come with KDE4 (which equals QT4), on a  
separate partition or hard drive.  Then you can play around with Myth  
trunk without the danger of messing up your current installation.  If  
you are happy with the results, then you can decide to make it your  
production system.


John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20081225/baf05ba3/attachment.htm