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

Tue Sep 12 17:13:51 UTC 2023

________________________________
From: mythtv-users <mythtv-users-bounces at mythtv.org> on behalf of Peter Bennett <pb.mythtv at gmail.com>
Sent: 12 September 2023 13:56
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/11/23 16:10, Philip Brady wrote:

________________________________
From: mythtv-users <mythtv-users-bounces at mythtv.org><mailto:mythtv-users-bounces at mythtv.org> on behalf of Peter Bennett <pb.mythtv at gmail.com><mailto:pb.mythtv at gmail.com>
Sent: 03 September 2023 13:23
To: mythtv-users at mythtv.org<mailto:mythtv-users at mythtv.org> <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/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

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=3  returns ‘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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230912/f882ead7/attachment.htm>