[mythtv-users] API call Guide/GetProgramList broken with port 6744.

Peter Bennett pb.mythtv at gmail.com
Thu Sep 14 12:57:07 UTC 2023


On 9/14/23 06:50, Philip Brady wrote:
>
>
> ------------------------------------------------------------------------
> *From:* mythtv-users <mythtv-users-bounces at mythtv.org> on behalf of 
> Peter Bennett <pb.mythtv at gmail.com>
> *Sent:* 13 September 2023 00:33
> *To:* mythtv-users at mythtv.org <mythtv-users at mythtv.org>
> *Subject:* Re: [mythtv-users] API call Guide/GetProgramList broken 
> with port 6744.
>
>
> On 9/12/23 13:13, Philip Brady wrote:
>>
>> Sorry but I'm still confused.
>>
>> " 7 and 8 are both still in use. The are both overrides, but 
>> different types of override. 7 is for a rule that overrides a 
>> specific recording to change some values, for example to record one 
>> episode into a different recording group. 8 is for a rule that 
>> overrides a rule and tells MythTV not to record a specific showing of 
>> a series. It would make more sense if 8 returned a string like Don't 
>> Record. The GetRecordSchedule API returns "Do not Record" if the 
>> value is 8.2
>>
>>
>> I have always submitted text values for <Type> in 
>> UpdateRecordSchedule.  eg 'Record One';
>> The text values are the same for both 7 and 8.
>> Are you saying that it will also accept both text and numeric values 
>> for <Type> ?
>>
>> Phil
>>
>>
> UpdateRecordSchedule takes a string for type, not a number. It 
> converts the string to a number for its internal use. It uses 
> recTypeFromString to do that 
> (https://github.com/MythTV/mythtv/blob/eea10424c0bbe65133120ff2899d20d8068e07f1/mythtv/libs/libmythbase/recordingtypes.cpp#L101 
> <https://github.com/MythTV/mythtv/blob/eea10424c0bbe65133120ff2899d20d8068e07f1/mythtv/libs/libmythbase/recordingtypes.cpp#L101> 
> )
>
> You can see from that routine that it allows various options, for 
> example "record all" or "all" (lower case, upper case or mixed) will 
> convert to kAllRecord (4). Note also that the default value if you 
> specify something that is not valid, is kDontRecord. If a numeric 
> value was supplied it would be defaulted to kDontRecord.
>
> A lot of this is not documented, except by looking in the code. Also a 
> lot of it is not ideal. I can fix stuff that is broken or wrong, but I 
> want to avoid doing anything that will break somebody else's use of 
> the APIs.
>
> Peter
>
>
>
> Hi Peter,
>
> Thanks for your replies.
>
> Recording Type:
> ---------------
> You say that  "7 is for a rule that overrides a specific recording to 
> change some values, for example to record one episode into a different 
> recording group. 8 is for a rule that overrides a rule and tells 
> MythTV not to record a specific showing of a series."
>
> That's clear but I'm still puzzled because that distinction is not 
> available to Dvr/UpdateRecordSchedule as it demands a string value.
> If I post an UpdateRecordSchedule with Type=Override Recording will it 
> impose type 7 action or type 8?
> What should I post if I want the other one?
>
Pass "Override Recording" to override recording values. Pass "Do not 
Record" to prevent a recording.
> The 'CurrentRecording' issue.
> -----------------------------
> Having made Status consistent between json and xml (even if it is now 
> numeric!) there is this further incompatibility whereby StatusName 
> gives 'CurrentRecording' but RecStatusToString?RecStatus=3 gives 
> 'Currently Recorded' for upcoming recordings.
>
> Existing json applications should be unaffected - they will not look 
> at StatusName anyway.
>
> Existing API/xml applications using this family of calls though are 
> quite different.  Between v33 and v34 they are all thoroughly broken 
> and authors are faced with THREE changes already (more complex tags, 
> missing recording info, numeric status).  Now seems as good time as 
> any to impose consistency by changing StatusName to give 
> CurrentlyRecoded rather than CurrentRecording as they will all have to 
> review their code anyway.  It is of course something else to go in the 
> wiki to support them.
> Please consider changing it.
>
Do you have a list of users of the API that we can notify. I have no 
problem with changing it, but I think we should have agreement among the 
developers. I suggest you create a ticket in github explaining the 
problem. (https://github.com/MythTV/mythtv/issues) Developers can review 
it and if there is agreement I can change it.
> Regards
> Phil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230914/d0a5df2e/attachment.htm>


More information about the mythtv-users mailing list