<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 05/09/2020 01:35, John P Poet wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CACSqvJ=2Si9kahQU3rye=2O1y69ar=QurabfU3+M4TE8vnfx0Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Fri, Sep 4, 2020 at 6:10 PM Bill Meek <<a
href="mailto:keemllib@gmail.com" moz-do-not-send="true">keemllib@gmail.com</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 9/4/20 4:17 PM, Peter
Bennett wrote:<br>
> <br>
> When creating or updating a recording schedule with the
service API, you can specify a Recording Group (recgroup).
However if you provide a new<br>
> recording group, the service API disregards it and sets
the Recording Group to "Default".<br>
> <br>
> There is no service API method to create a new
recording group.<br>
> <br>
> In MythFrontend, recording groups are created just by
entering a new one when setting up a recording rule.<br>
> <br>
> Note there is no way to delete a recording group,
either with the frontend or the API.<br>
> <br>
> I propose to change the Service API so that it will
create a new recording group if one is supplied that does
not already exist. This is in line<br>
> with how the frontend works, and will solve my problem.<br>
> <br>
> Anybody have any comments or objections?<br>
> <br>
> Peter<br>
<br>
Just tested the above and agree, the new RecGroup was
ignored. Dvr/GetRecGroupList<br>
didn't display it either. So, it doesn't exist in any
record.recgroup or in<br>
recgroups.<br>
<br>
No objections, it's broken.<br>
</blockquote>
<div><br>
</div>
<div>Personally, I think a new call should be added for the
creation of a new recording group. That would allow the
specification of a recording group "template" including the
filters and such. While that is different than the current
frontend behavior, I would argue that the current frontend
behavior is not ideal.</div>
<div><br>
</div>
<div>John<br>
</div>
</div>
</div>
<br>
</blockquote>
<p><br>
</p>
<p>Well one of the original premise of the Services API was to
separate the clients from needing to use or even know what the
underlying DB format was so ideally when you set up a new
recording schedule using the services API that uses a new
Recording Group it should just do the right thing without the
client having to worry about checking to see if the Recording
Group exists or not.</p>
<p><br>
</p>
<p>Of cause you can do both - have a more high level API that always
tries to do the right thing and a low level one that allows you to
add/delete/modify recording groups as needed. The important thing
in my view is the services API should be consistent though out so
what we do here will determine the future direction the API will
take. <br>
</p>
<p><br>
</p>
<p>Just my tuppence worth feel free to ignore :)<br>
</p>
<p><br>
</p>
<p>Paul H.<br>
</p>
</body>
</html>