<div dir="ltr"><div dir="ltr">On Fri, Sep 4, 2020 at 6:10 PM Bill Meek <<a href="mailto:keemllib@gmail.com">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>