Mailing List Archive: MythTV: Dev

Improving playback groups

Index | Next | Previous | View Threaded

stichnot at gmail

Feb 8, 2010, 7:42 PM

Post #1 of 3 (921 views)
Permalink

Improving playback groups

It would be nice if many more settings could be overridden by a
Playback Group, such as fill mode, captions, playback profile, aspect
ratio, OSD properties, audio options, etc. For example, all of my
children's recordings should play without captions and should exit
playback at the end without prompting (in contrast to recordings for
grownups). Some subset of these should play with an Adjust Fill mode
of Full. Certain programs on certain channels should use an Adjust
Fill mode of Half.

Let's say, just hypothetically :) , that I wanted to tackle this. It
could be a somewhat large and invasive set of changes, so I would want
to be sure that I have the right approach and haven't overlooked
anything important. Here are some ideas.

1. I would organize the playback group settings hierarchically with
single inheritance. Each playback group inherits from a parent
playback group. The root (Default) playback group inherits from the
global or host-specific settings. Playback groups themselves are
global, i.e. shared across frontends, except to the extent that they
inherit from host-specific settings.

2. Each setting in a playback group is either a specific value or
inherits from its parent.

3. In the Settings UI, each setting would have an additional checkbox
to say whether it has a specific value or inherits from its parent.
The label for this checkbox would include the parent's current value
so you know what you're likely to inherit. If the checkbox is set to
Inherit, the override setting disappears or is grayed out.

4. The DB gets a new table, playgroupsettings, which is similar to the
existing settings table, except that there is a playgroupname column
instead of a hostname column, and there is a boolean column indicating
Inherit versus Override. To define the inheritance tree structure,
playgroupsettings has a row for each playback group where
value='playgroupparent'. The existing playgroup table gets deprecated
or removed, and its values are migrated into playgroupsettings.

5. Suppose playback group A is the parent of B, and B is the parent of
C. If B is deleted, C's parent becomes A. If B is renamed, C's
parent value is updated to B's new name. Consistency checks ensure
that parents exist and don't lead to a cycle.

6. Mythvideo playback would use the root (Default) playback group.
When mythvideo becomes unified with recordings, videos could also have
non-Default playback groups.

7. A lot of this work would be in the Settings UI. I counted about 75
host-specific settings that would be suitable for playback groups,
plus the 5 existing playback group settings. Are there plans to
overhaul the settings UI, like converting it to MythUI? If not, a lot
of the existing code should be reusable, but at a high level, it would
probably be a ~10 page dialog to fully configure a playback group.

8. Some more work in the playback code to make sure the playback group
name is available wherever corresponding entries from the settings
table are currently needed.

9. I would also use this to solve the problem of painstakingly
configuring a new frontend. Put all the common settings in the
Default playback group, and allow the Default playback group to
inherit only the host-specific settings.

What do people think? Is this a reasonable approach? Would there be
any real interest in putting something like this into 0.24? If not, I
would probably just implement it locally for the handful of settings I
care about and skip the entire Settings UI portion.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Feb 14, 2010, 10:55 AM

Post #2 of 3 (750 views)
Permalink

Re: Improving playback groups [In reply to]

On Mon, Feb 08, 2010 at 07:42:13PM -0800, Jim Stichnoth wrote:
> It would be nice if many more settings could be overridden by a
> Playback Group, such as fill mode, captions, playback profile, aspect
> ratio, OSD properties, audio options, etc. For example, all of my
> children's recordings should play without captions and should exit
> playback at the end without prompting (in contrast to recordings for
> grownups). Some subset of these should play with an Adjust Fill mode
> of Full. Certain programs on certain channels should use an Adjust
> Fill mode of Half.
>
> [much deletia]
>
> What do people think? Is this a reasonable approach? Would there be
> any real interest in putting something like this into 0.24? If not, I
> would probably just implement it locally for the handful of settings I
> care about and skip the entire Settings UI portion.

Hi Jim,

The suggestion to greatly extend playback groups comes up
periodically. I don't know about the other developers, but I've yet
to hear a suggestion that I like for a couple of reasons.

First, there is the difficulty in deciding which parameters should be
included and which ones shouldn't. I wrote the feature specifically
for the skip ahead amount and the default timestretch speed. That
should be enough for everyone, right? :) OK, I did make the API
extensible, but I honestly didn't expect it to be done much, if at
all. In my current opinion, any significant extension needs to
cleanly and simply handle virtually any playback related setting.

Second, and probably much more importantly, the UI needs to add more
value than complexity. For example, the multi-level, nested scheme
you described sounds great in theory, but I really can't see it
working well in practice. I've used applications that implemented
such a scheme and it was always a pain to move around several dialogs
or tabs to see the small handful of settings that were changed from
the parent settings. IMO, any UI needs to make it easy to quickly
identify all settings that are changed from the default (or parent).

I haven't given this a lot of thought, but I'm going to throw out an
idea for s simple UI to handle a greatly extended playback groups
feature. What if the guts of the interface was simply a multi-line
text box for listing key=value pairs to override the default settings?
No, it wouldn't be idiot proof, but it would be simple, make it easy
to see exactly what settings are changed and be immensely flexible.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stichnot at gmail

Feb 14, 2010, 2:24 PM

Post #3 of 3 (740 views)
Permalink

Re: Improving playback groups [In reply to]

On Sun, Feb 14, 2010 at 10:55 AM, David Engel <david [at] istwok> wrote:
> Hi Jim,
>
> The suggestion to greatly extend playback groups comes up
> periodically. �I don't know about the other developers, but I've yet
> to hear a suggestion that I like for a couple of reasons.
>
> First, there is the difficulty in deciding which parameters should be
> included and which ones shouldn't. �I wrote the feature specifically
> for the skip ahead amount and the default timestretch speed. �That
> should be enough for everyone, right? :) �OK, I did make the API
> extensible, but I honestly didn't expect it to be done much, if at
> all. �In my current opinion, any significant extension needs to
> cleanly and simply handle virtually any playback related setting.
>
> Second, and probably much more importantly, the UI needs to add more
> value than complexity. �For example, the multi-level, nested scheme
> you described sounds great in theory, but I really can't see it
> working well in practice. �I've used applications that implemented
> such a scheme and it was always a pain to move around several dialogs
> or tabs to see the small handful of settings that were changed from
> the parent settings. �IMO, any UI needs to make it easy to quickly
> identify all settings that are changed from the default (or parent).
>
> I haven't given this a lot of thought, but I'm going to throw out an
> idea for s simple UI to handle a greatly extended playback groups
> feature. �What if the guts of the interface was simply a multi-line
> text box for listing key=value pairs to override the default settings?
> No, it wouldn't be idiot proof, but it would be simple, make it easy
> to see exactly what settings are changed and be immensely flexible.

Hi David,

Thanks for reading through and commenting. I've been slowly working
on an implementation, and it's really great as far as playback goes.
You're right that the UI design is the tricky part.

I implemented a hierarchical model where all roots implicitly inherit
from the Default group and Default inherits from the host-specific
settings. I find that the Default group may override a lot of
host-specific settings because I prefer many changes from the myth
default, whereas non-Default groups need only a few changes from
Default. So it's probably reasonable to limit the hierarchy to
Host>Default>{all groups}.

For the settings UI, I am trying to reuse the code in the
PlaybackSettings and OSDSettings classes, where I think all the
relevant playback settings are located. However, some of those
settings are not really relevant to playback, such as pages 4, 5, and
6 of Playback Settings as well as several on page 1. Reusing the code
will give a layout that is familiar and similar to the existing
settings UI, which would be helpful to that handful of people who
actually remember where the settings are. :) As you say, this needs
to be made so that it is easy to clearly call out settings that are
overridden, and I'm working on that.

I like the idea of an "expert mode" to give direct access, though it
comes with its own challenges, such as finding the names of all
settings that are covered by expanded playback groups.

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads