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

Tue Sep 12 13:56:27 UTC 2023

On 9/11/23 16:10, Philip Brady wrote:
>
>
> ------------------------------------------------------------------------
> *From:* mythtv-users <mythtv-users-bounces at mythtv.org> on behalf of 
> Peter Bennett <pb.mythtv at gmail.com>
> *Sent:* 03 September 2023 13:23
> *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/3/23 07:03, Philip Brady wrote:
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
>> Windows
>>
>> *From: *Peter Bennett <mailto:pb.mythtv at gmail.com>
>> *Sent: *01 September 2023 21:34
>> *To: *mythtv-users at mythtv.org <mailto:mythtv-users at mythtv.org>
>> *Subject: *Re: [mythtv-users] API call Guide/GetProgramList broken 
>> with port 6744.
>>
>> On 9/1/23 09:46, Philip Brady wrote:
>>
>>     The API call /Guide/GetProgramList is broken with port 6744.  It
>>     does not respect the Details=true parameter.
>>
>>     This breaks portability of my 'split film' utility.
>>
>>     I know that the right course of action for me is to submit a bug,
>>     but can anyone point me at a tutorial for doing that please?
>>
>>     ...
>>
>>     Phil
>>
>> When there is a recording scheduled, the Recording tags is filled in. 
>> When there is no recording scheduled for that program, it is reported 
>> as nil.
>>
>> ...

>> Can you handle this in your utility?
>>
>> Peter
>>
>> Thanks Peter.
>>
>> Yes, should be able to handle that and I’ll update the documentation 
>> accordingly.
>>
>> Would you clarify though – is it only the ‘Guide’ APIs or is it 
>> applied to the ‘Dvr’ ones too?
>>
>> Regards
>>
>> Phil.
>>
> The infrastructure that gets the requests and formats the results was 
> rewritten and all of the methods were converted. There are minor 
> changes throughout.
>
> I checked Dvr/GetRecordedList. Artwork is one structure that is optional.
>
> In the old API an empty Artwork shows like this
>
> <Artwork>
> <ArtworkInfos/>
> </Artwork>
>
> In the new API an empty Artwork shows like this:
>
> <Artwork xsi:nil="true"/>
>
> In case you want to run comparisons:
>
> In master, versions before v34-Pre-408-gdd35e85329 use port 6744 for 
> the new api and 6544 for the old.
>
> Versions after v34-Pre-408-gdd35e85329 use port 6544 for the new API 
> and have the old api on port 6550. This old API will not be updated 
> and will be removed at some point. Port 6744 is also still available 
> and runs the new API.
>
> I hope this helps.
>
> Peter
>
>
> -------------------------------------
>
> Hi Peter,
>
> Many thanks for you patience!
>
> Yes, the new interface with no recording info can be handled with an 
> application change and I’ve included a note about both this and the 
> new backend port numbers in the wiki article 
> https://www.mythtv.org/wiki/Recording_Status 
> <https://www.mythtv.org/wiki/Recording_Status>
>
> In time, I’ll also change Perl API examples to include the ‘no 
> recording information’ scenario.I suspect that it’s only Guide calls 
> which can meaningfully return an empty <Recording> section.
>
> I think there are still two things which are still a little unclear 
> and which I’m seeing with 
> v34.0~master.202306020720.ed409bfc02~ubuntu22.04.1 but a later version 
> may well be more consistent.
>
> The first is that Backend:6744/Dvr/RecTypeToString?RecType=7 and 8 
> both return ‘Override Recording’.See the wiki article.You say that 7 
> is still useful but 8 is obsolete so I presume that 
> Dvr/RemoveRecordSchedule is needed to stop a recording.Might you ever 
> need to post ’Override Recording’ in an UpdateRecordSchedule?
>
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.
>
> It would be clearer if RecTypeToString and RecTypeToDescription both 
> returned ‘Unsupported’ for unsupported values.As it is, the only 
> practical value for these calls seems to be to determine the values 
> and meanings for Type – are there any APIs which return a numeric Type?
>
We are trying to move away from numeric values for type, status, etc. 
and use strings with meaningful names. I don't know if there are APIS 
that return a numeric type for recording rules. If there are we can 
modify them to have an additional field with the string value, which 
would be the preferred value to use.
>
> The second issue is status
>
> Backend:6744/Dvr/RecStatusToString?RecStatus=3returns ‘Currently Recorded’
>
> ie – you already have this recording on your disk.I think that’s a 
> meaningful return value.
>
>
> But entries in my Dvr/ GetUpcomingList have Status=3, 
> StatusName=CurrentRecording
>
> which suggests that the program is currently in the process of being 
> recorded. The examples I’ve seen are all recorded already and will not 
> be recorded again so a better StatusName would be 
> ‘CurrentlyRecorded’.I think this is a bug – is it here?
>
> mythtv/mythtv/libs/libmythbase/recordingstatus.h at 
> 07439138c378fe07efcee8993721d7e3932ed4c6 · MythTV/mythtv · GitHub 
> <https://github.com/MythTV/mythtv/blob/07439138c378fe07efcee8993721d7e3932ed4c6/mythtv/libs/libmythbase/recordingstatus.h#L11>
>
The value CurrentRecording is the actual name in the code for value 3 
(see 
https://github.com/MythTV/mythtv/blob/eea10424c0bbe65133120ff2899d20d8068e07f1/mythtv/libs/libmythbase/recordingstatus.h#L35 
). There are 2 related values PreviousRecording and CurrentRecording. 
PreviousRecording means that you have in the past recorded it, watched 
it and deleted it. CurrentRecording means you have recorded it and it is 
still on your disk. The person who originally wrote the code thought 
this was meaningful. The GetUpcomingList now uses a QT feature that lets 
it get the enum name from the value. That way if new values are added to 
the list the programmer does not have to remember to also update the API.

Before we knew about the Qt metadata feature that allows this, somebody 
created a method to translate statuses to English, see 
https://github.com/MythTV/mythtv/blob/eea10424c0bbe65133120ff2899d20d8068e07f1/mythtv/libs/libmythbase/recordingstatus.cpp#L150 
. That is what is used in RecStatusToString. The RecStatusToString 
should really be changed and RecStatus::toString should be removed. That 
would make them consistent as CurrentRecording, which is not your 
preference.

The best way to fix it would be to change the names in the code to 
PreviouslyRecorded and CurrentlyRecorded. However this will affect 
people who already use the API and rely on PreviousRecording and 
CurrentRecording.

> Sorry to be so persistent about this – I just want help in creating 
> clear documentation.
>
> Regards
>
> Phil
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230912/97f4b6ee/attachment.htm>