[mythtv] [Preliminary patch[ Add profile groups

[Geoffrey Hausheer]

On Thu, 11 Sep 2003 18:01:06 -0700, "Bruce Markey bjm-at-lvcm.com
|mythtv/1.0-Allow|" <2obvhk58d70t at sneakemail.com> said:
> Geoffrey Hausheer wrote:
> > In case anyone was wondering, here are the results of my efforts at
> > building profile groups.  This patch is not quite ready yet, but I
> > thought I'd get it out there, and see if anyone has any suggestions.
> 
> I applied the patch to a clean copy of cvs and installed on
> a test machine with one WinTV 401, one PVR-250 and a test
> scratch mysql database. It seems work and do the right things.
> A couple little bumps along the way:
> 
> + I needed to modify programs/mythtranscode/main.cpp to
> modify loadByName on line 190 to get it to compile (didn't
> 'fix' it, just got it to compile ;-)
Yeah, as I said, the transcoder was broken.  I didn't even try to build
it

> 
> + cvs.sql is missing the "=" after "name" on the last six INSERTs.
> 
> + I created a new profile group which seems to have added
> four Default and no LiveTV for profilegroup 4.
I have reworked the patch in line with Isaac's recomendations such that
there is no need to associate a card with a profile-group  TRhis should
make it much easier to comprehend

> 
> mysql> select * from recordingprofiles;
> +----+---------+------------+------------+--------------+
> | id | name    | videocodec | audiocodec | profilegroup |
> +----+---------+------------+------------+--------------+
> |  1 | Default | MPEG-4     | MP3        |            1 |
> |  2 | Live TV | MPEG-4     | MP3        |            1 |
> |  3 | Default | RTjpeg     | MP3        |            2 |
> |  4 | Live TV | RTjpeg     | MP3        |            2 |
> |  5 | Default | NULL       | NULL       |            3 |
> |  6 | Live TV | NULL       | NULL       |            3 |
> |  7 | Default | NULL       | NULL       |            4 |
> |  8 | Default | NULL       | NULL       |            4 |
> |  9 | Default | NULL       | NULL       |            4 |
> | 10 | Default | NULL       | NULL       |            4 |
> +----+---------+------------+------------+--------------+
> 
Yeah that is a bug in the patch.  It is already fixed.

> ...
> > A card can only exist in one profile-group
> > A card which is already in the current group is marked with a '*'
> > profile groups that have cards associated with them are marked 'IN USE'
> > (I should probably swap this, and make unused groups marked 'EMPTY')
> 
> I like what you've done but I'd like to make suggestion
> that I think will address these issues and make it easier
> for users to understand.
> 
> Setting the codecparams for each profile certainly belongs
> in TV Settings->Recording. However, since the card type does
> not change at runtime I think the profile groups and card
> association should happen in the backend setup. Setup step 2
> for "Capture Cards" could had a spinbox for "Profile Group"
> right after "Card Type". This would assure that each card 
> would be in exactly one group.
As I said, this is no longer necessary, since cards are associated only
at record time.  It makes the interface a lot better.
> 
> If the profile groups are set in setup, TV Settings->Recording
> could be much simpler for the 95% of users that have one card
> or multiple cards of the same type (and simpler for the other
> 5% of us too ;-). If group creation and card assignment don't
> happen on the "Recording" page then only the IN USE names need
> to be exposed. 95% of us would just see one group name and drill
> down to set the profiles for that group. If we had setup a card
> to be in a second group then the Recording page would show two
> group names. 
> 
> > There are 4 profiles (Default, Live TV, Low-Quality, High-Quality).
> > These can be easily changed by modifying availProfiles in
> > recordingprofile.cpp (but if you change Default or Live TV, other things
> > need to be changed too)
> 
> Now here's a nit. "Low-Quality" doesn't sound like a desirable
> goal. "Low-Res" maybe but it would be better if it expressed
> space efficient, compact, maximum record time, low bandwidth,
> (where are those marketing people when you actually need them?).
Sure, find a name, and I'll change it.  It is a one line change in
recordingprofile.h and a trivial change to the db.

> 
> Overall, I was very impressed by how effective this patch is at
> solving this long standing issue. I'm now confident that a very
> welcome solution will be in place very soon.
Implementing Isaac's sugestion basically solved all of the issues I
initially listed.  There are only two things left to do: (1)  I seem to
have a race in generating the GUI.  It is pretty reproducable, whenever I
create a new profile-group (actually it seems to happen mostly when
editing a non-default program-group.  I have no idea what is going on and
gdb is very unhelpful:
#0  0x40aeff8c in mallopt () from /lib/libc.so.6
#1  0x40aef173 in malloc () from /lib/libc.so.6
#2  0x40a2c74e in operator new(unsigned) () from /usr/lib/libstdc++.so.5
#3  0x40a2c87f in operator new[](unsigned) () from
/usr/lib/libstdc++.so.5
#4  0x4071fd4c in QString::setLength(unsigned) () from
/usr/lib/libqt-mt.so.3
#5  0x40720017 in QString::grow(unsigned) () from /usr/lib/libqt-mt.so.3
#6  0x40726f82 in QString::operator+=(QString const&) ()
   from /usr/lib/libqt-mt.so.3
#7  0x407202c0 in QString::arg(QString const&, int) const ()
   from /usr/lib/libqt-mt.so.3
#8  0x4007b84b in MythContext::GetSetting(QString const&, QString const&)
(
    this=0x84b30f0, key=@0xbfffd310, defaultval=@0xa8000000)
    at mythcontext.cpp:569
It is weird because there is only one thread active (that I can see), and
I've touched nothing in GetSetting (and none of my code calls that
function directly (I'd provide a full backtrace, but truest me, it is
completely useless).  It may be memory corruption, but the failure
doesn't happen every time, and it isn't always in the same function.  I
really have no idea what is going on at the moment.  This is compounded
by me not fully undersatdning how the GUI stuff works (even if I've
figured out how to put the blocks together to make it work).  If I can't
figure it out, I might just have to submit what I've got and hope someone
out there is smarter than I am.

2) The transcoder is still broken.  I know how to fix it now, and I can
probably do so in an hour or two, but I really want to find this segfault
first.

.Geoff