[REQ] Additional web service API calls

[reven]

Hi Sub,

here's the running list (I'll update it as I go) of API calls I would like.

• Get recording conflicts: recording.list&filter=conflicts. Need all the same info returned that is displayed in the npvr gui
  
• Recurring recordings, get the schedule of the recurring (time of day, days of week etc)
  
• get epg listings passing in multiple channeloids. I'm also having problems getting whats just finished. If I pass in now-30minutes, I don't always get that, npvr seems to ignore listings that have "expired". but I would still like to display these
  
• Pending recordings
  
• include if recording service was stopped during a recording to the recordings.list call (so can display same warning as in npvr gui)
  
• epg, get whats on now and next (passing in the value for "now"). This is a nice to have, I'm using this info for the mini guide. Currently having to grab about 12 hours of all channels just to ensure I get the next epgevent (some channels have very long shows).
  
• Ability to search for listings by regex or simlar. So I can find all listings starting with "x" but also any listings with "batman" in its name
  
• Add more settings to Setting.list call (whats new days, skip steps, recording start screen etc)
  
• record based on epgevent oid and schedule type with optional prepadding/postpadding/folder/keep values (if optionals arent set, use defaults). Schedule type eg 0 = once, 1 = All new, 2 = this timeslot, mon-fri etc
  
• Ability to update a recording schedule. Passing in the recurring oid, and the new schedule
  
• Ability to delete a recurring recording
  
• Get comskip times for a recording (based on recording oid)
  
• Include "watched" status on recordings in recordings.list
  
• Include "playposition"/"resumeposition" in reocrdings.list
  
• Ability to set watched status of a recordign
  
• Ability to set playposition/resumeposition of a recording
  
• return JSON data if requested via content-type=application/json or a &type=json parameter (easier to test in browser with a url parameter, but correct method is content-type (i always do both in my apps))
  
• ability to get tuner status (live tv, currently recording)
  
• ability to get basic server information, free space on tv buffer drive (and drive letter), free space on recordings drive (and drive letter) (in case of multiple drives, return a list of all ones), OS version, system uptime.
  
• get a list of recording directories
  
• add default postpadding/prepadding/keep days to setting.list call
  

Sorry it's a pretty big list, just trying to mimic nextpvr which requires these

#1 is the recording stuff and JSON is pretty important to me.

[sub]

I have added a some of these already, and will work through the others when I'm in NZ next week. I'd say you'll end up with most of them.

JSON support for all calls is probably the least likely, since it'll require a lot of rework of existing stuff, but I could certainly try adding optional support for it with a couple of the calls. ie, probably EPG related calls, since they're most likely to benefit from the smaller transfer size.

[reven]

cheers, I wasn't sure what you were using (wcf or something similar, where its a simple thing to add in).

epg is definitely the most important as well as recordings (anything that requires a lot of iterate over lots of data. which is basically just those two calls.

[mvallevand]

Sub how fixed will your web api be? Can I assume if you make changes later on for Gotham that you will leave these calls alone and working and use some kind of versionning in the URL for new calls?

The reason I ask is I would like to use some of these calls in X-NEWA too as this should be more lightweight than SOAP. However it takes many months to get all my devices on the same version of XBMC so the backend needs a lot of support for previos version. I expect reven will have Samsung delays too, if Plex is any indication.

Martin

[sub]

I typically don't change my API, and I expect that to be the case here.

The existing calls are unchanged, other than additional nodes added to the xml results. The new calls are extending that api with adding additional calls.

[reven]

personally I would never expect an API call to change. Once an API call is added it needs to be left as is. Adding additional output (class property, xml elements/properties) is fine, but breaking the output or adding additional REQUIRED parameters for a call is a big no no, if the API it to be used by 3rd party devs.

In any case that requires breaking changes, its best to make a new api call and eventually deprecate an old one over time.

which I believe sub feels pretty much the same way.

I would love for ndroid to use this standard API service instead of its custom one (I can't for the life of me get that working on my androids...)

[bgowland]

I would love for ndroid to use this standard API service instead of its custom one (I can't for the life of me get that working on my androids...)

I'd be more than happy to look at any new "open" APIs that sub is willing to make available but there are reasons I'd probably keep the nDroid Service as a proxy even if I reduced the amount the app relied on it.

As for you not being able to get nDroid working on your devices - feel free to pursue any issues in the nDroid forums. I admit it's fiddly and by no means an ideal solution but at last count, according to Google Play and the Amazon Appstore stats , there are about 360 installations of nDroid v1.x and nDroid TE combined. Not saying they're all fully functional or being used on a daily basis (that's impossible to tell) but I'd expect a significant percentage are otherwise people would have un-installed the app or the nDroid forum would be a lot busier with problem reports.

[reven]

yeah im sure others have got it to work, and I didnt mean to sound like i was complaining. Just would make it a lot easier. It could very well have something to do with the fact I'm running on windows server 2012 (which has stronger security than your vanilla windows 7/8/xp install)

[bgowland]

yeah im sure others have got it to work, and I didnt mean to sound like i was complaining. Just would make it a lot easier. It could very well have something to do with the fact I'm running on windows server 2012 (which has stronger security than your vanilla windows 7/8/xp install)

It's pretty much just a case that the nDroid Service needs to run under an account with security to access the npvr program files and data folders, username / passwords need to be the same as the npvr web server and firewall ports need to be open. I can't think of much more than that. As I said, if you wan't to pursue it then start a thread in the nDroid folder. The service logs are fairly verbose so I should be able to spot what isn't working if you post them.

[reven]

sub are you back in nz now?