Mailing List Archive

Services API : inputgroup
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

Thanks,

John
Re: Services API : inputgroup [ In reply to ]
On 5/25/22 21:22, 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
>
> Thanks,
>
> John
>
>
>
Hi John

That page is out of date. We have since converted all of the services to
a new framework, called services V2. That page documents the old services.

Currently in V32 and master the old services run on port 6544 and the
new services are on 6744. Both should be compatible with each other. The
old will be phased out. I am now using the new 6744 on my production
system, it is working well. The old services will be shut down and the
new ones moved to port 6544 at some point.

This page documents the conversion of old to new:

https://www.mythtv.org/wiki/Services_API_V2_Conversion

This documents developing the new V2:

https://www.mythtv.org/wiki/Services_API_V2_Development_Guide

I need to put a note in the old document to refer readers to the new one.

New services are only developed for the V2 API.

If there is a service for input groups it would be in
http://localhost:6744/Myth/wsdl . I do not see one. However, we are
developing web based setup pages to replace mythtv-setup using the
service API. So we will have to develop APIs for everything needed by
mythtv-setup. It may be that Stuart or Paul is working on some new APIs,
otherwise one of us will get to it at some point. Stuart, Paul and I are
working on the new web based setup. You are welcome to help :)

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API : inputgroup [ In reply to ]
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
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API : inputgroup [ In reply to ]
On Thu, May 26, 2022 at 10:02 AM David Engel <david@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.

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.

John
Re: Services API : inputgroup [ In reply to ]
On Thu, May 26, 2022 at 8:58 AM Peter Bennett <pb.mythtv@gmail.com> wrote:

>
> On 5/25/22 21:22, 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
> >
> > Thanks,
> >
> > John
> >
> >
> >
> Hi John
>
> That page is out of date. We have since converted all of the services to
> a new framework, called services V2. That page documents the old services.
>
> Currently in V32 and master the old services run on port 6544 and the
> new services are on 6744. Both should be compatible with each other. The
> old will be phased out. I am now using the new 6744 on my production
> system, it is working well. The old services will be shut down and the
> new ones moved to port 6544 at some point.
>
> This page documents the conversion of old to new:
>
> https://www.mythtv.org/wiki/Services_API_V2_Conversion
>
> This documents developing the new V2:
>
> https://www.mythtv.org/wiki/Services_API_V2_Development_Guide
>
> I need to put a note in the old document to refer readers to the new one.
>
> New services are only developed for the V2 API.
>
> If there is a service for input groups it would be in
> http://localhost:6744/Myth/wsdl . I do not see one. However, we are
> developing web based setup pages to replace mythtv-setup using the
> service API. So we will have to develop APIs for everything needed by
> mythtv-setup. It may be that Stuart or Paul is working on some new APIs,
> otherwise one of us will get to it at some point. Stuart, Paul and I are
> working on the new web based setup. You are welcome to help :)
>
> Peter
>

Thank you Peter. I plan to start working on some of this stuff.

John
Re: Services API : inputgroup [ In reply to ]
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@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.

> 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.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API : inputgroup [ In reply to ]
On Thu, May 26, 2022 at 1:03 PM David Engel <david@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@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).


> > 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?

John
Re: Services API : inputgroup [ In reply to ]
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@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@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
table.

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
"<host>|<some-text>".

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
--
David Engel
david@istwok.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Services API : inputgroup [ In reply to ]
On Fri, May 27, 2022 at 2:31 AM David Engel <david@istwok.net> wrote:

> 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.

While never released, I had a prototype of an app that
used the Capture service(*). However, as the app was
never finished/released, I think it does not *really* count
as a real user.

Gary

(*) Does it surprise anyone that I toyed with the
Capture service to enhance my unofficial 3rd
party MythTV apps?
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org