Mailing List Archive

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

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Peter Bennett<mailto:pb.mythtv@gmail.com>
Sent: 01 September 2023 21:34
To: mythtv-users@mythtv.org<mailto:mythtv-users@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.

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@gmail.com>
> *Sent: *01 September 2023 21:34
> *To: *mythtv-users@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
> <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
> <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

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

On 9/11/23 16:10, Philip Brady wrote:
>
>
> ------------------------------------------------------------------------
> *From:* mythtv-users <mythtv-users-bounces@mythtv.org> on behalf of
> Peter Bennett <pb.mythtv@gmail.com>
> *Sent:* 03 September 2023 13:23
> *To:* mythtv-users@mythtv.org <mythtv-users@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@gmail.com>
>> *Sent: *01 September 2023 21:34
>> *To: *mythtv-users@mythtv.org <mailto:mythtv-users@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
>
>
>

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

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
)

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

________________________________
From: mythtv-users <mythtv-users-bounces@mythtv.org> on behalf of Peter Bennett <pb.mythtv@gmail.com>
Sent: 13 September 2023 00:33
To: mythtv-users@mythtv.org <mythtv-users@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 )

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?

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.

Regards
Phil

On 9/14/23 06:50, Philip Brady wrote:
>
>
> ------------------------------------------------------------------------
> *From:* mythtv-users <mythtv-users-bounces@mythtv.org> on behalf of
> Peter Bennett <pb.mythtv@gmail.com>
> *Sent:* 13 September 2023 00:33
> *To:* mythtv-users@mythtv.org <mythtv-users@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
>
>