[mythtv] Services API : inputgroup

David Engel david at istwok.net
Fri May 27 02:30:50 UTC 2022

On Thu, May 26, 2022 at 05:44:29PM -0600, John P Poet wrote:
> On Thu, May 26, 2022 at 1:03 PM David Engel <david at istwok.net> wrote:
> > On Thu, May 26, 2022 at 11:46:52AM -0600, John P Poet wrote:
> > > On Thu, May 26, 2022 at 10:02 AM David Engel <david at istwok.net> wrote:
> > >
> > > > On Wed, May 25, 2022 at 07:22:42PM -0600, John P Poet wrote:
> > > > > Hi Peter, et al.,
> > > > >
> > > > > Is there a Services API endpoint for managing the inputgroup table? I
> > > > > didn't see one but figured I would ask before working on adding it.
> > > > >
> > > > > I have not been that active lately, so if there is a new and
> > improved way
> > > > > of writing Services API stuff, please let me know. Otherwise, I will
> > > > follow
> > > > > https://www.mythtv.org/wiki/Services_API_Development_Guide
> > > >
> > > > I'll defer to Peter, Stuart and Paul on the v2 API framework.  IMO,
> > > > though, the v1 API is severely lacking when it comes to tuners and
> > > > need not be kept as is in v2.
> > > >
> > > > As for input groups, I don't see any reason to allow direct access to
> > > > the table per se through the API.  Instead, I think there should
> > > > probably only be services like AddCaptureCardToGroup and
> > > > RemoveCaptureCardFromGroup where the group is identified by name only.
> > > >
> > > > David
> > > >
> > >
> > > Yes, I agree. There would also need to be AddGroup and RemoveGroup and
> > > GetGroups.
> >
> > I don't know that these are strictly needed.  GetGroups could be
> > synthesized by simply getting all tuners and seeing what groups are in
> > use.  AddGroup and RemoveGroup aren't really needed either as a group
> > iplicitly is created when it's added to a tuner and deleted when it's
> > removed from the last card using it.
> >
> I see that a "default" input group is created when a capture card is added.
> I don't see a way of creating custom groups though, without adding a
> AddGroup call. For example, when two different capture devices are sharing
> a video source, so only one can be used at a time (not multirec).

There are two types of input groups that share the same database

The first type is automatically created for inputs that support
multirec.  This type shound never ever be visible nor editable by
users.  The group name for this type uses the pattern

The second type is for users to manually tie inputs together.  An
[obsolete] example would be an STB used by both firewire (freely
copyable channels) and an HD-PVR (all other channels).  Only this type
should be editable by users and exposed in the API.  The group name
for this type uses the pattern "user:<some-text>" and the "user:"
should be hidden from the user.

When you say "I don't see a way of creating custom groups though,
without adding a AddGroup call", do you mean in the API or in
mythtv-setup?  I don't think the existing API supports input groups at
all.  mythtv-setup technially has an Add Group button but it's not
strictly necessary.  There could just as easily be an option to add a
new group in the spinbox used to choose from the existing groups.

Oh, instead of AddCaptureCardToGroup and RemoveCaptureCardFromGroup
calls, the new API could also just have an inputgroups field for each
tuner that is simply a list of group names.  When that field is
provided, the listed groups are added as needed and any existing ones
not listed are removed.

> > > If you have other suggestions for how the tuner API should be structured,
> > > let me know. I still don't have a lot of free time right now, but plan on
> > > starting to work some of this stuff.
> >
> > Look at the *Schedule functions for adding business rules.  One thing
> > those functions don't currently support and should be remedied and not
> > copied is optional parameters on updates.  IOW, if a parameter is not
> > specified in an "update", it should default to the current value of
> > the underlying object.
> >
> > One area of tuner configuration that I don't have a good idea of how
> > to handle yet is DiSEqC.  I'm not keen on having an API exposing the
> > entire tree but I also don't have any better idea either.
> >
> The current API for Capture card management does not seem to know anything
> about input groups:
> http://localhost:6744/Capture/GetCaptureCardList
> Are we trying to keep V2 API backwards compatible?

I know of no users of the old, v1 API for tuners and unless a really
importatn one steps up, I see no good reason to retain compatibility
with it.

And one more thing I forgot earlier.  Only the parent tuners should be
editable by users.  I'd probably even prefer that all child tuners not
even be visible but I'm not sure that's feasiable as their IDs are
still very meaningful within Mythtv.  To truly hide them, we'd have to
scour the entire API to make sure only parent IDs are visible.

David Engel
david at istwok.net

More information about the mythtv-dev mailing list