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

Philip Brady phil.brady at hotmail.co.uk
Mon Sep 11 20:10:47 UTC 2023



________________________________
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?



mythbackend --version

Please attach all output as a file in bug reports.

MythTV Version : v34.0~master.202306020720.ed409bfc02~ubuntu22.04.1

MythTV Branch : master

Network Protocol : 91

Library API : 34.20220913-1

QT Version : 5.15.3

Options compiled in:

 linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_satip using_vbox using_ceton using_joystick_menu using_libcec using_libcrypto using_gnutls using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl using_egl using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_v4l2prime using_x11 using_system_libbluray using_system_libudfread using_systemd_notify using_systemd_journal using_drm using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_egl using_drm using_vaapi using_nvdec using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2 using_libmp3lame



With port 6544 I get this:

http://192.168.2.109:6544/Guide/GetProgramList?StartTime=2023-09-01T13:22:13Z&ChanId=11080&Count=6&Details=true

...

<Recording>

<RecordedId>0</RecordedId>

<Status>Unknown</Status>

<Priority>0</Priority>

<StartTs xsi:nil="true"/>

<EndTs xsi:nil="true"/>

<FileSize>0</FileSize>

<FileName/>

<HostName/>

<LastModified xsi:nil="true"/>

<RecordId>0</RecordId>

<RecGroup/>

<PlayGroup/>

<StorageGroup/>

<RecType>0</RecType>

<DupInType>1</DupInType>

<DupMethod>1</DupMethod>

<EncoderId>0</EncoderId>

<EncoderName/>

<Profile/>

</Recording>



but with port 6744 I get:

http://192.168.2.109:6744/Guide/GetProgramList?StartTime=2023-09-01T13:22:13Z&ChanId=11080&Count=6&Details=true

<Recording xsi:nil="true"/>



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.



Recording scheduled:

<Recording version="1.3">
<RecordedId>0</RecordedId>
<Status>10</Status>
<StatusName>Inactive</StatusName>
<Priority>0</Priority>
<StartTs>2023-09-01T20:01:00Z</StartTs>
<EndTs>2023-09-01T21:00:00Z</EndTs>
<FileSize>0</FileSize>
<FileName xsi:nil="true"/>
<HostName>rocinante</HostName>
<LastModified>2023-09-01T20:00:00Z</LastModified>
<RecordId>178</RecordId>
<RecGroup>Default</RecGroup>
<StorageGroup>Default</StorageGroup>
<PlayGroup>Default</PlayGroup>
<RecType>4</RecType>
<DupInType>15</DupInType>
<DupMethod>6</DupMethod>
<EncoderId>0</EncoderId>
<EncoderName xsi:nil="true"/>
<Profile>Default</Profile>
</Recording>

Not scheduled:
<Recording xsi:nil="true"/>



The old API would return a tag full of default, null and invalid values when no recording was scheduled. This, in my opinion, was a bug in the old code that is now fixed.



OLD Result for no schedule:

<Recording>
<RecordedId>0</RecordedId>
<Status>Unknown</Status>
<Priority>0</Priority>
<StartTs xsi:nil="true"/>
<EndTs xsi:nil="true"/>
<FileSize>0</FileSize>
<FileName/>
<HostName/>
<LastModified xsi:nil="true"/>
<RecordId>0</RecordId>
<RecGroup/>
<PlayGroup/>
<StorageGroup/>
<RecType>0</RecType>
<DupInType>1</DupInType>
<DupMethod>1</DupMethod>
<EncoderId>0</EncoderId>
<EncoderName/>
<Profile/>
</Recording>



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?



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?



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>



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/20230911/3f95f2f1/attachment.htm>


More information about the mythtv-users mailing list