<div dir="ltr"><div dir="ltr">On Thu, May 26, 2022 at 1:03 PM David Engel <<a href="mailto:david@istwok.net">david@istwok.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 26, 2022 at 11:46:52AM -0600, John P Poet wrote:<br>
> On Thu, May 26, 2022 at 10:02 AM David Engel <<a href="mailto:david@istwok.net" target="_blank">david@istwok.net</a>> wrote:<br>
> <br>
> > On Wed, May 25, 2022 at 07:22:42PM -0600, John P Poet wrote:<br>
> > > Hi Peter, et al.,<br>
> > ><br>
> > > Is there a Services API endpoint for managing the inputgroup table? I<br>
> > > didn't see one but figured I would ask before working on adding it.<br>
> > ><br>
> > > I have not been that active lately, so if there is a new and improved way<br>
> > > of writing Services API stuff, please let me know. Otherwise, I will<br>
> > follow<br>
> > > <a href="https://www.mythtv.org/wiki/Services_API_Development_Guide" rel="noreferrer" target="_blank">https://www.mythtv.org/wiki/Services_API_Development_Guide</a><br>
> ><br>
> > I'll defer to Peter, Stuart and Paul on the v2 API framework.  IMO,<br>
> > though, the v1 API is severely lacking when it comes to tuners and<br>
> > need not be kept as is in v2.<br>
> ><br>
> > As for input groups, I don't see any reason to allow direct access to<br>
> > the table per se through the API.  Instead, I think there should<br>
> > probably only be services like AddCaptureCardToGroup and<br>
> > RemoveCaptureCardFromGroup where the group is identified by name only.<br>
> ><br>
> > David<br>
> ><br>
> <br>
> Yes, I agree. There would also need to be AddGroup and RemoveGroup and<br>
> GetGroups.<br>
<br>
I don't know that these are strictly needed.  GetGroups could be<br>
synthesized by simply getting all tuners and seeing what groups are in<br>
use.  AddGroup and RemoveGroup aren't really needed either as a group<br>
iplicitly is created when it's added to a tuner and deleted when it's<br>
removed from the last card using it.<br></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> If you have other suggestions for how the tuner API should be structured,<br>
> let me know. I still don't have a lot of free time right now, but plan on<br>
> starting to work some of this stuff.<br>
<br>
Look at the *Schedule functions for adding business rules.  One thing<br>
those functions don't currently support and should be remedied and not<br>
copied is optional parameters on updates.  IOW, if a parameter is not<br>
specified in an "update", it should default to the current value of<br>
the underlying object.<br>
<br>
One area of tuner configuration that I don't have a good idea of how<br>
to handle yet is DiSEqC.  I'm not keen on having an API exposing the<br>
entire tree but I also don't have any better idea either.<br></blockquote><div><br></div><div>The current API for Capture card management does not seem to know anything about input groups:</div><div><br></div><div><a href="http://localhost:6744/Capture/GetCaptureCardList">http://localhost:6744/Capture/GetCaptureCardList</a></div><div><br></div><div>Are we trying to keep V2 API backwards compatible?</div><div><br></div><div>John<br></div></div></div>