API call needed for retain recording

What would you like to see in MythTV and why? Find others who might want to help implement your ideas!
Forum rules
Please be reasonable and positive with your feature requests, remember that all contributions to MythTV are by volunteers in their spare time. MythTV won't support piracy in any form, including torrents and use of soft cams, so to avoid embarrassment please do not ask.

* One suggestion per thread please. Do not post new suggestions in replies. *
Post Reply
Posts: 163
Joined: Sun Aug 09, 2015 3:51 am
Location: Calera, OK
United States of America

API call needed for retain recording

Post by sfatula » Sun Apr 08, 2018 6:18 pm

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.

Posts: 175
Joined: Tue Feb 23, 2016 7:33 am
United States of America

Re: API call needed for retain recording

Post by daraden » Mon Apr 09, 2018 12:41 am

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.

Posts: 163
Joined: Sun Aug 09, 2015 3:51 am
Location: Calera, OK
United States of America

Re: API call needed for retain recording

Post by sfatula » Mon Apr 09, 2018 2:39 am

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.

User avatar
Posts: 1817
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: API call needed for retain recording

Post by bill6502 » Sat Jun 16, 2018 12:19 am

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"

Post Reply