Mailing List Archive: Service API RecordSchedule shortcoming

Service API RecordSchedule shortcoming

Sep 4, 2020, 2:17 PM

Post #1 of 6 (1130 views)

When creating or updating a recording schedule with the service API, you
can specify a Recording Group (recgroup). However if you provide a new
recording group, the service API disregards it and sets the Recording
Group to "Default".

There is no service API method to create a new recording group.

In MythFrontend, recording groups are created just by entering a new one
when setting up a recording rule.

Note there is no way to delete a recording group, either with the
frontend or the API.

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 with how the frontend works, and will solve my problem.

Anybody have any comments or objections?

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: Service API RecordSchedule shortcoming [ In reply to ]

keemllib at gmail

Sep 4, 2020, 5:10 PM

Post #2 of 6 (1130 views)

Permalink

On 9/4/20 4:17 PM, Peter Bennett wrote:
>
> When creating or updating a recording schedule with the service API, you can specify a Recording Group (recgroup). However if you provide a new
> recording group, the service API disregards it and sets the Recording Group to "Default".
>
> There is no service API method to create a new recording group.
>
> In MythFrontend, recording groups are created just by entering a new one when setting up a recording rule.
>
> Note there is no way to delete a recording group, either with the frontend or the API.
>
> 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
> with how the frontend works, and will solve my problem.
>
> Anybody have any comments or objections?
>
> Peter

Just tested the above and agree, the new RecGroup was ignored. Dvr/GetRecGroupList
didn't display it either. So, it doesn't exist in any record.recgroup or in
recgroups.

No objections, it's broken.

--
Bill
_______________________________________________
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: Service API RecordSchedule shortcoming [ In reply to ]

jppoet at gmail

Sep 4, 2020, 5:35 PM

Post #3 of 6 (1130 views)

Permalink

On Fri, Sep 4, 2020 at 6:10 PM Bill Meek <keemllib@gmail.com> wrote:

> On 9/4/20 4:17 PM, Peter Bennett wrote:
> >
> > When creating or updating a recording schedule with the service API, you
> can specify a Recording Group (recgroup). However if you provide a new
> > recording group, the service API disregards it and sets the Recording
> Group to "Default".
> >
> > There is no service API method to create a new recording group.
> >
> > In MythFrontend, recording groups are created just by entering a new one
> when setting up a recording rule.
> >
> > Note there is no way to delete a recording group, either with the
> frontend or the API.
> >
> > 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
> > with how the frontend works, and will solve my problem.
> >
> > Anybody have any comments or objections?
> >
> > Peter
>
> Just tested the above and agree, the new RecGroup was ignored.
> Dvr/GetRecGroupList
> didn't display it either. So, it doesn't exist in any record.recgroup or in
> recgroups.
>
> No objections, it's broken.
>

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.

John

Re: Service API RecordSchedule shortcoming [ In reply to ]

mythtv at mythqml

Sep 5, 2020, 4:09 AM

Post #4 of 6 (1127 views)

Permalink

On 05/09/2020 01:35, John P Poet wrote:

> On Fri, Sep 4, 2020 at 6:10 PM Bill Meek <keemllib@gmail.com
> <mailto:keemllib@gmail.com>> wrote:
>
> On 9/4/20 4:17 PM, Peter Bennett wrote:
> >
> > When creating or updating a recording schedule with the service
> API, you can specify a Recording Group (recgroup). However if you
> provide a new
> > recording group, the service API disregards it and sets the
> Recording Group to "Default".
> >
> > There is no service API method to create a new recording group.
> >
> > In MythFrontend, recording groups are created just by entering a
> new one when setting up a recording rule.
> >
> > Note there is no way to delete a recording group, either with
> the frontend or the API.
> >
> > 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
> > with how the frontend works, and will solve my problem.
> >
> > Anybody have any comments or objections?
> >
> > Peter
>
> Just tested the above and agree, the new RecGroup was ignored.
> Dvr/GetRecGroupList
> didn't display it either. So, it doesn't exist in any
> record.recgroup or in
> recgroups.
>
> No objections, it's broken.
>
>
> 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.
>
> John
>

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.

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.

Just my tuppence worth feel free to ignore :)

Paul H.

Re: Service API RecordSchedule shortcoming [ In reply to ]

pb.mythtv at gmail

Sep 5, 2020, 6:35 AM

Post #5 of 6 (1125 views)

Permalink

On 9/4/20 8:35 PM, John P Poet wrote:
> On Fri, Sep 4, 2020 at 6:10 PM Bill Meek <keemllib@gmail.com
> <mailto:keemllib@gmail.com>> wrote:
>
> On 9/4/20 4:17 PM, Peter Bennett wrote:
> >
> > When creating or updating a recording schedule with the service
> API, you can specify a Recording Group (recgroup). However if you
> provide a new
> > recording group, the service API disregards it and sets the
> Recording Group to "Default".
> >
> > There is no service API method to create a new recording group.
> >
> > In MythFrontend, recording groups are created just by entering a
> new one when setting up a recording rule.
> >
> > Note there is no way to delete a recording group, either with
> the frontend or the API.
> >
> > 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
> > with how the frontend works, and will solve my problem.
> >
> > Anybody have any comments or objections?
> >
> > Peter
>
> Just tested the above and agree, the new RecGroup was ignored.
> Dvr/GetRecGroupList
> didn't display it either. So, it doesn't exist in any
> record.recgroup or in
> recgroups.
>
> No objections, it's broken.
>
>
> 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.
>
> John
>
Hi John

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.

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.

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.

Peter

Re: Service API RecordSchedule shortcoming [ In reply to ]

jppoet at gmail

Sep 5, 2020, 7:14 AM

Post #6 of 6 (1125 views)

Permalink

On Sat, Sep 5, 2020 at 7:36 AM Peter Bennett <pb.mythtv@gmail.com> wrote:

>
> On 9/4/20 8:35 PM, John P Poet wrote:
>
> On Fri, Sep 4, 2020 at 6:10 PM Bill Meek <keemllib@gmail.com> wrote:
>
>> On 9/4/20 4:17 PM, Peter Bennett wrote:
>> >
>> > When creating or updating a recording schedule with the service API,
>> you can specify a Recording Group (recgroup). However if you provide a new
>> > recording group, the service API disregards it and sets the Recording
>> Group to "Default".
>> >
>> > There is no service API method to create a new recording group.
>> >
>> > In MythFrontend, recording groups are created just by entering a new
>> one when setting up a recording rule.
>> >
>> > Note there is no way to delete a recording group, either with the
>> frontend or the API.
>> >
>> > 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
>> > with how the frontend works, and will solve my problem.
>> >
>> > Anybody have any comments or objections?
>> >
>> > Peter
>>
>> Just tested the above and agree, the new RecGroup was ignored.
>> Dvr/GetRecGroupList
>> didn't display it either. So, it doesn't exist in any record.recgroup or
>> in
>> recgroups.
>>
>> No objections, it's broken.
>>
>
> 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.
>
> John
>
> Hi John
>
> 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.
>
> 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.
>
> 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.
>
> Peter
>

Ah, right. I forgot those were two separate things. Please proceed!

John