Page 1 of 1

API call needed for retain recording

Posted: Sun Apr 08, 2018 6:18 pm
by sfatula
Here is an example workflow we would like to use but currently cannot.

We have a daily TV show, do not wish to specify. My wife loves this show. In a normal case. show records, wife watches, all is well, it eventually rolls off due to max # to keep. At times though, life gets in the way. Shows can pile up, therefore, we have a large # to keep before rolling off but even with that, we reach the limit so recordings do roll off.

Now and then, she encounters an episode that is really good and helpful. For those, the ideal scenario would be to be able to set do not expire and preserve so it does not auto expire or roll off. This would allow her to watch that again in the future. We mark those as watched also, which is currently possible with the api, so she would be able to tell it's one she wants to rewatch eventually, even a year down the line.

My view is that frontends will continue to be less and less PC based, and web based is not as good. So, for us, we use 2 Apple TV and 1 Roku. We also use iPad. Those all work by API. So, we cannot do what we want right now as the API does not allow preserve and do not expire. If this could be added to the API, then, the next step could be to modify the frontend software used, which I believe I can "encourage" or make happen. Seems like a necessary step for good app based frontends and typical workflow. Also seems like it would apply to others on certain shows as well.

Right now, I see no good way to accomplish this. I just manually copy the recording into another directory for retention. Ideal is to retain all metadata, still show up in recordings, etc. This would allow her to just mark it to keep and that's it, simple. Hard to be easier! And surely those features are in mythfrontend for a reason, they are hopefully useful to many. I see some discussions on them.

If you think this is a worthwhile feature, I would even potentially do the code and submit it since it's pretty important to us and I think enabling more access to stuff from apps is a good thing in the long run as it makes mythtv more functional for more people. I see api as more important than work on web based frontend for the future of mythtv. Would just want direction on how it should work, naming, etc. I get the difference, but there are 2 flags right now, preserve and do not expire, so, api could go several ways here if you plan on keeping both or not. Saw a ticket somewhere about this.

Thank you for the consideration.

Re: API call needed for retain recording

Posted: Mon Apr 09, 2018 12:41 am
by daraden
I think a better way to go about it would be to make tns:Program(return of /Dvr/GetRecorded) include all of the recorded entry's from the database. Then add an UpdateRecorded call to modify the data in the database. So rather than a call for every item someone may wish to modify you have one call that can modify all of the items.

Re: API call needed for retain recording

Posted: Mon Apr 09, 2018 2:39 am
by sfatula
Sure, that would be great and even better. Previously, an endpoint was added for updating watched status (Dvr/UpdateRecordedWatchedStatus), as you say you can add a whole lot of endpoints that update one column in the db, or, do them all in one. There may be some things you might not want to allow updating, not sure it is necessary or desirable to update every database column. Seems like some maybe shouldn't be or involve even more data from other tables that perhaps would make sense as a separate endpoint.. I think that's a great idea. I presume one would only pass data they want to update. Anything not passed in would be retained as is.

If that is so, what would be needed is defining which database columns should be allowed to be updated, and, what the rules are for each. i.e., care would be needed to make sure values are validated and referential integrity is maintained.

Re: API call needed for retain recording

Posted: Sat Jun 16, 2018 12:19 am
by bill6502
Done, not pushed. I didn't put lots of parameters here because they're
used at record time and didn't make sense (to me) to allow changing
them. This should care for the high runners.

Code: Select all

bool Dvr::UpdateRecordedMetadata ( int              nRecordedId,
                                   bool             bAutoExpire,
                                   bool             bDamaged,
                                   const QString   &sDescription,
                                   int              nEpisode,
                                   const QString   &sInetRef,
                                   bool             bPreserve,
                                   int              nSeason,
                                   const QString   &sSubTitle,
                                   const QString   &sTitle,
                                   bool             bWatched     )
Who wants to contribute by writing the addition to the Wiki?
All the parameters except the first are optional.

You can write it off-line and I'll add it to the Wiki. Here's a start
with one parmaeter:

Code: Select all


The <span style="color:LimeGreen">UpdateRecordedMetadatat</span> API takes the following arguments:

:<span style="color:SteelBlue">RecordedId</Span> ('''Required''')
:: '''Parameter Type:''' Integer
:: The unique id for a single recording.

Repeat the above three lines for the other ten parameters.
Example Query:


Example Return (JSON for a change):
    "bool": "true"