<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/4/20 8:35 PM, John P Poet wrote:<br>
</div>
<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>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<p>Hi John</p>
<p>The recgroups table only has recgroup, display name and password.
The frontend always sets the display name the same as the recgroup
name. The display name is not used. I updated the display name of
a recgroup in the database as a test and the frontend still
displays the recgroup name.<br>
</p>
<p>There is already the ability to create templates through the
AddRecordSchedule service API call, but only for a recgroup that
already exists. My proposed change would allow template creation
for a new recgroup.</p>
<p>A new add recgroup api would only be adding a regroup name. The
GetRecGroupList api only returns the recgroup name, not the
display name or password, so it would not be logical for an add
recgroup api to supply those.<br>
</p>
<p>Peter<br>
</p>
</body>
</html>