Jump to content

Recording Service API features


Christian B.

Recommended Posts

Hi

 

I am trying to create a smart phone application (currently Windows Phone 7 only, but maybe Android/iPhone later) for the DVB Recording Service. My goal is to create smart phone application that makes it very easy manage recordings from the phone - browse the EPG, recordings and timers, schedule new recordings, check status etc.

 

I have got some basic functionality working on the phone using the Recording Service API (http://en.DVBViewer.tv/wiki/Recording_Service_API), but there are some missing pieces that I can’t find, so I hoping for a little help.

 

1) When I use the “/api/epg.html” to get the programs, I only get channel ID’s, not the display name for the channel. Is there a way to get a channel list using the Recording Service API or some other method (it would be nice with a URL to a channel icon)?

 

2) For the “/api/recordings.html” it would be nice to have access to thumbnail images. I can see that the thumbnails has a URL that looks like “..thumbnails/video/2746588569_SM.jpg”, but I can’t figure out how to generate the number based on information the recordings.html result. Is there a way to do that?

 

3) Also for the “/api/recordings.html” it would be nice to have access to the log information, is there a way to do that?

 

4) For the “/api/status.html” I had hoped the be able to get the current status for the tuners (same info as on the status page on the web). Is there a another way to do that?

 

I noticed the comment “This api is still in development and may change without warning”, are there any plans on freezing a version of the API in the near future?

 

I am sure that I could find some workarounds for these problems on my own server, but I am hoping to create a public available phone application and in that case it should work with a standard installation of the Recording Service.

 

Hoping someone can help or even better working together on improving the Recording Service API.

 

Regards,

Christian

Link to comment

Well the api ist foremost designed with the DVBViewer in mind. He already "knows" all the channels and gets certain update notifications via broadcasts or the connection with the unicast device. This works for a local network but is not useable in a WAN environment...

 

It might be time to make the api a little bit more general purpose.

 

I noticed the comment "This api is still in development and may change without warning"

It won't, this is just to be on the safe side, in case I mess something up. ;) I can't simply change the api, this would cause problems with older DVBViewer versions. Normally I extend them or introduce new functions. So do not worry about it. :)

 

ATM I'm working at the final touches for the next release (=translating the changelog to english and all these meanial tasks nobody likes to do ;) ) so I won't be participating in this discussion much for the next days.

 

Just think about what you really need, keep in mind there is a lot of data involved. A channels.dat is 300 kb, a channels.xml might be 5 or more MB (even with compressed transmission you have to process the amount of data). But do you need all the tuning data, or should a channels.xml consist more of a channelname, index, epgid and logourl as example? Or maybe a function would be better to get only the data for a specific channel based on whatever ID you already have...

 

And forget the existing API, if you can reuse or extend it fine, if not, well too bad, we just add something new (ah well you know what I mean, in a nice and orderly way not the clutter it is now...).

 

There are a lot of possibilities. We can give you at least data wise nearly everything you want, just leave the "heavy" processing to the server and only ask for the smallest amount of data possible.

 

The more refined the "concept" of the api is, the faster (and easier for me ) the implemtation is. And I have no problems providing development builds to developers of applications using the api, when we start changing it together. Well at least as long as it stays within limits... ;)

Link to comment

@Christian B.: I am developing an Android App right now. The first Public Beta is out since a couple of Days. I will open an english toppic very soon with one of the next Beta Versions. So I know about your problems. Right now you need to get the channels.dat and get the Informations out of it. You can get it via /api/getchannelsdat.html which is a not official API-Function. The description of the DAT-File is in the Members Area.

 

Then you can get the Favourites and try to sync them. Then you have the informations you need.

 

@Lars_MQ: Sounds like a release very soon for me :) Even if not: a more functional API is really necessary if you want cool Apps for the DVBViewer. I don't have a chance to get the Logos of the Channels. Or the Pictures from Recordings. Also an EPG Search is not possible for my App. But right now I have enough to do with the API functions already available. So no hurry because of me.

 

Cheers!

Link to comment

Hi Lars

 

Thanks for your reply!

 

Of course it would be nice with a new API, but I can easily work with the existing Recording Service API if it could get a few extensions. I like the concept of http-get / XML as the communication protocol; it works on all platforms, so the API could just grow (add new calls, so compatibility is maintained) over time without having to reinvent everything at once.

 

I would like to suggest a new Channel Information List http-get call:

 

http://[user:password@]IP[:port]/api/channelinfolist.xml[?id={channelId}]

 

<?xml version="1.0" encoding="utf-8"?>

<ChannelInfoList Version="1.0">

<!--

ChannelInfo

Id: string, required, unique id of the channel (should match channel id's used in EPG, timers etc.)

Name: string, required, display name of the channel

Logo: string, optional, URL (absolute or relative) to a channel logo

Kind: string, optional*, specify if it's a Audio (radio) or Video channel [do we need this?]

Index: integer, optional*, defines a sort order when listing channels

Category: string, optional*, category as specified in Channel list editor

Group: string, optional*, group as selected in Channel list editor

ExcludeFromEpg: bool, optional, Exclude from EPG flag as selected in Channel list editor (if not specified false should be assumed)

Language: string, language, category as specified in Channel list editor

 

* Could be required as I thing they are required in the Channel list editor?

-->

 

<ChannelInfo Id="560750996357330" Name="Film HD"

Logo="/Logos/Film+HD.png" Kind="Video|Audio"

Index="1" Category="Danish TV"

Group="A|B|C|D|E|F|G|H" ExcludeFromEpg="true|false"

Language="DEN|GER|SWE|..." />

...

</ChannelInfoList>

 

 

 

 

If no “id” query string parameter is specified all channels are returned, otherwise only the specified channel or none (if not found) is returned. I don’t see the need for more detailed querying on this call.

 

I intend to download the channel list and cache it on the phone, so it would be very nice if the http-get call could support HTTP ETag (http://en.wikipedia.org/wiki/HTTP_ETag). By using the ETag standard it would be possible check for changes during download and only get the content when it’s actually was changed. ETag support would of course also be nice on some of the other calls like recordings, EPG and timers.

 

You are already supporting compression, so that helps a lot with the size of the XML files.

 

@KobiP: Please comment, how does this ChannelInfoList fit your needs?

 

As soon as I find some time I will get back with a few other suggestions.

 

Regards

Christian

 

PS: Keep up the great work with DVB Recording Service, it’s such a nice product!

Link to comment

@Christian: On the one hand I like your proposal of the XML file. So much easier to parse than a bit-encoded File. On the other Hand most of it you can get out of the Channels.Dat. Not that easy, but perhaps more efficient when it comes to >1000 channels. And channel lists usually don't change that often. But I really miss the chance to get the Channel-Icons.

 

The Idea with the ETag is a good Idea! Right now I have to download everything all the time again and again cause I cannot know if something changed.

 

What I am currently worrying about is how to get the Data for a timeline in my app. Of course I have two chances right now: get the EPG for all channels at once for a time period (so much data to transmit, a no go for a mobile app) or get it for one channel and a time period. And repeat this for all channels of interest.

 

Perhaps it would be possible to HTTP-post a XML-File and recieve a tailored XML-File from the service? This would also reduce the transmitted data for the XML-Channellist.

 

like I post a XML-File to the Service

 

<EPG Request Start="X" Stop="Y">
<FFolder>Sky</FFolder>
<Channel>ChannelID 1</Channel>
<Channel>ChannelID 2</Channel>
<Channel>ChannelID 3</Channel>
<Channel>ChannelID 4</Channel>
</EPG Request>

This would get the EPG for all the Channels in the Sky Folder (from the Favourites) as well as four other channels.

 

But like I said the basics are already here. No need to invent something new, only to extend the existing one.

And a better description would also be nice. When I get the Timers or Recordings the XML contains so much Data where I don't know what it means. (I know that it's not a fun work ;) )

 

Cheers

Link to comment

Shure, but the DVBViewer as a good algorithm to match the channelname with the Filename. It does not have to be exactely the same. And you would only have one place to keep your pictures up-to-date. Of course, they don't change very often too.

 

But when it is about preview Pictures of Recordings there is nothing I could do right now. Not that it would be a killer feature.

 

Cheers

Link to comment

Something that would be very useful would be the possibility to delete a recorded file. Like a Timer, same procedure. Should be easy to implement (I think).

 

Cheers

Link to comment
  • 6 months later...

And forget the existing API, if you can reuse or extend it fine, if not, well too bad, we just add something new (ah well you know what I mean, in a nice and orderly way not the clutter it is now...).

 

There are a lot of possibilities. We can give you at least data wise nearly everything you want, just leave the "heavy" processing to the server and only ask for the smallest amount of data possible.

 

The more refined the "concept" of the api is, the faster (and easier for me ) the implemtation is. And I have no problems providing development builds to developers of applications using the api, when we start changing it together. Well at least as long as it stays within limits... ;)

 

Are you still interested in extending or rewriting the API?

I guess you already know that there is a small nice Android App whistle.gif. It is already quite usable, but it lacks of some features (and of course some unfixed bugs biggrin.gif), because of the API limitations.

For example i am hosting MarkusK`s logopack on my own server to provide the channel logos....

I dont hear any complains, but i could bet my algorihtmus doesnt always find the right channel logo for all the channels out there :-)

 

I could give you detailed information about what i am missing. But it would take me some time to document this stuff ;-)

 

Just let me know if its worth the work, or if u have other plans meanwhile.

 

 

 

Link to comment
  • 3 weeks later...
Just think about what you really need, keep in mind there is a lot of data involved. A channels.dat is 300 kb, a channels.xml might be 5 or more MB (even with compressed transmission you have to process the amount of data). But do you need all the tuning data, or should a channels.xml consist more of a channelname, index, epgid and logourl as example? Or maybe a function would be better to get only the data for a specific channel based on whatever ID you already have...

 

Are you still considering this?

 

I really like the Christian B.'s proposal (for me, the essential data is: channel number, name, ID, group, logo, isRadio, isFTA) and that file wouldn't be that big.

Edited by A600
Link to comment

To get the channels data I finally used the channels.dat (it's not that hard with the info from the members area)

 

About the logos: would it be possible to get them with an url like this: "http://127.0.0.1:8089/Logos/[number].png" where [number] is the channel number?

Edited by A600
Link to comment

Dont bother yourself, your requests will be ignored......

 

Its not worth the effort...

 

I know but at least, a "Yes, no or we don't care" answer from the developers would be nice.

Link to comment

Dont bother yourself, your requests will be ignored......

 

Its not worth the effort...

Oh yeah, that is the truth of the day.....unfortunately :(

Link to comment
×
×
  • Create New...