GetRecorded and RemoveRecorded api calls

[PhilB]

I'd really appreciate it if someone would tell me what I'm doing wrong here.

I'm trying to persuade the backend to remove a recording via a perl script. If anyone has a working example I'd be very grateful.
I'm trying to use the /Dvr/RemoveRecorded api call but I'm not too sure of my perl so I'm trying something a little simpler with just the Firefox browser.
I noted that /Dvr/GetRecorded uses the same parameters (it's also a 'get' not a 'post' so should be really simple).

Code: Select all

http://192.168.1.67:6544/Dvr/GetRecordedList?StartIndex=3&Count=1

returns this:

<ProgramList version="1.0" serializerVersion="1.1">
<StartIndex>3</StartIndex>
<Count>1</Count>
<TotalAvailable>648</TotalAvailable>
<AsOf>2014-11-17T17:22:24Z</AsOf>
<Version>0.27.20141016-1</Version>
<ProtoVer>77</ProtoVer>
<Programs>
<Program>
<StartTime>2012-01-18T21:30:00Z</StartTime>
[ . . . ]
<ChanId>1002</ChanId>

Now if I plug those details into GetRecorded with:

Code: Select all

http://192.168.1.67:6544/Dvr/GetRecorded?StartTime=2012-01-18T21:30:00Z&ChanId=1002

I get a blank template but with timenow substituted for times:
All field are blank or zero; in particular:

<Program version="1.11" serializerVersion="1.1">
<StartTime>2014-11-17T17:37:21Z</StartTime>
<EndTime>2014-11-17T17:37:21Z</EndTime>
<Title/><SubTitle/><Category/><CatType/>
<Repeat>false</Repeat>
<VideoProps>0</VideoProps>
<AudioProps>0</AudioProps>
<SubProps>0</SubProps>
<SeriesId/><ProgramId/>
[. . . . ]
<Channel>
<ChanId>0</ChanId>

Can anyone explain what I'm doing wrong?

Phil

[bill6502]

Hi,

Maybe.

You didn't include enough of the 1st endpoint's output. The timestamp you should use is: <StartTs>,
not <StartTime>. The above suggests that they may not be the same (e.g. the recording was started
after the scheduled start time.)

[PhilB]

yes! That's it. Thanks Bill6502.

So startime is what's in the schedules (21:30 in this instance) but StartTs (21:26) is when the recording actually started (I allow 4 mins at start).

The api needs a parameter which says StartTime=<StartTS> eg
http://192.168.1.67:6544/Dvr/GetRecorde ... hanId=1002

Next question is how did you work that out? Is there some documentation other than the api wiki which explains it?
Thanks again
Phil

[stuartm]

It's very unfortunate that this old internal confusion has been carried over into the Services API. It should not have happened, but the good news is that from 0.28 we introduce a new 'recording id' value which is intended to be used instead, it should be less confusing and less error prone than providing the correct starttime/chanid combo in the correct format.

[bill6502]

Next question is how did you work that out? Is there some documentation other than the api wiki which explains it?

It's not a good answer, but you asked how and it's here:
https://code.mythtv.org/cgit/mythtv/tre ... r.cpp#n146
Note the recstarttsRaw argument.

[PhilB]

Thank you both.
I now have my backend removing recordings so am closer to testing my SSD to HD migration system.
I have added a note to the api wiki about the format of StartTime,but it will be overtaken by events.

It's good to be warned of the forthcoming change, but will GetRecorded and RemoveRecorded have two versions in 0.28 - the new plus the legacy or will applications stop working?

Yes, I feared the documentation might have been the source code! The old protocol stuff is also valid for interpreting bits in the objects returned. There's a place for a list of what everything is - will ponder that given the time constraints on the devs.

That code referred to also has the GetRecordedList routine and somewhere in it is the bug that gives same results for StartIndex=0 and StartIndex=1. I thought I bug reported that yesterday but for the life of me I cannot find it today!

Thanks again both.
Phil

[stuartm]

The Services API will remain backwards compatible, at least for a good while and we will advise well ahead of time when older endpoints or arguments are dropped. At least that's the plan, the API is still young and evolving as design errors are put right.