[mythtv] ivtv settings patch

[Chris B]

Geoffrey Hausheer wrote:

> On Fri, 05 Sep 2003 19:20:16 +0200, "Chris B news-at-semperpax.com
> |mythtv/1.0-Allow|" <d14ahk4yan0t at sneakemail.com> said:
> 
>>What about:
>>
>>- Leave the Profile setup screen as it is
>>- Remove all hard-coded profile name in the code ("Default", "Live TV", 
>>"Transcode")
>>- Add 2 db fields to the "capturecard" table ("LowRecProfile" - 
>>"HighRecProfile") pointing to arbitrary profiles
> 
> Sure this is a possibility.
> 
> 
>>- Add a new setup screen as to associate the high/low fields to profiles 
>>per capture card and to specify the "default" transcode profile (that 
>>leaves an open path to allow specifying the transcode profile at will, 
>>even though I agree that will probably be hard work. Anyway, I think 
>>there should be more ways to schedule a transcode than the "X". I'm 
>>testing now a simple patch for mythweb)
> 
> Dealing with the transcoder is tricky.  1st, there is little reason to
> schedule a transcode if you haven't done the commercial cut (in which
> case, use 'X'), or when you want to save space by doing RTJpeg to MPEG4
> (use AutoTranscode).  I don't really see the use for control from
> mythweb.

Well, just a matter of personal taste, I don't like going on 
automatically (especially lengthy and disk-consuming processes) and 
besides, I don't want to transcode stuff that I'll just watch and 
scratch. Secondly, IMHO, I find the fact of having to watch the 
recording in order to transcode it counter-intuitive. Thirdly, for 
recordings I know I'll not watch soon, I like the fact of launching the 
transcode after the recording, from the office, knowing that it'll be 
probably done when I'm back.
But, I agree these likings are maybe not the ones of the majority.

> The other issue with the transcoder, is that the profile used to record
> isn't stored in the recording.  Thus enabling/disabling the Autotranscode
> can be done per profile (or perhaps better would be per card, since it
> would be confusing to allow you to enable the transcoder for a LiveTV
> profile).  

I see what you want to achieve. From a design perspective, I'd find more 
gracefull to leave the "Auto-transcode" setting global, as it is now and 
add a transcoding profile association to each profile which could be 
"None". This would achieve the same result.
> 
> 
> 
>>- Assume low profile for live TV and high profile for recordings (it 
>>could be possible to add a shortcut to switch profiles in the middle of 
>>a live session)
> 
> I think this is overly complex, but that's just me.  i certainly don't
> think it is high-priority

If you speak about the switch shortcut, I agree this is pure 
"Nice-to-have", and I even can't find what that could be useful for ;-)
> 
> 
> It all makes sense, but it is quite a bit more effort than what I was
> actually plnning on implementing.  I'm also not sure it is very intuitive
> for a user. If you have a 'MJPEG' profile, you can't attach it to a bttv
> or pvr card (same for all others), so to me it seems backwards to have a
> pool of profiles associated with random cards.

I totally agree that card-profile associations should be restricted 
based upon types.
I'm rather thinking in terms of database normalization and openness. 
There are myriads of codec and/or encoder cards and/or technically 
specific profiles (e.g. VCD) which could be potentially used with MythTV 
and associated with different cards.
Your multiple set approach is most the easiest to implement (and 
again...), but it kind of de-normaize Myth as you can end-up with 
exactly the same profile being duplicated several times.
In terms of implementation, after having a look at the code, I think it 
would be "technically" very easy to do, actually, if we add the db 
fields to add the association. The complicated part will be to create an 
intuitive setup frontend ;-)

> Instead, I think the user
> should select the card, and then create profiles for it (then myth can be
> smart enough not to offer him profile-types that aren't compatible with
> the card).  This is effectively what my method would allow (though I want
> to start simple (create per-card hard-coded Default/LiveTV profiles), it
> is fully extensible to an arbitraty number of profiles per card, and the
> ability to select from them at will when scheduling a program..whenever
> someone gets around to coding that).  I do like the idea of adding the
> default profiles to the capturecard table, so that it is easy to change
> these whenever someone puts together a screen to allow that in the
> future.
>