The index for recordings used to be optional. It's now mandatory.
What is it used for? I'm currently returning an incrementing number as I iterate over the list of recordings returned from the MythTV backend. This means that it could change due to a recording being added or deleted from the backend. Will this be a problem?
it's used to identify recordings, so changes can be detected in a tag. it shouldn't be a problem, since the list of recordings will just be replaced.
now that I think of it, it's also used in the filename of a recording at the moment. so if the numbers change and files were added to the library, the files won't be there anymore after the change or other files will be opened instead.
Hmmm, so that sounds like it will be a problem for the MythTV implementation. All of the Myth files are played back using the XBMC player by passing a URL. The MythTV addon doesn't need to use the index for anything. The playback URL contains all the "unique identifiers" that MythTV needs to play it (channel ID and start time) - at the moment as formatted query parameters to the MythXML interface.
The previous myth:// URLs used the "recording ID" to uniquely identify content, and that was a smashup of the channel ID and the start time passed across the Myth Protocol interface.
Suggestions? Thoughts?
How was the PVR stuff working before when the index was optional? Any chance it can go back to that? Or can the interface be changed to be a string rather than an integer. Much easier to make a synthetic unique ID that is a string than a number.
right, this is different from tvheadend then, which uses integers to identify items.
I'll have a look at changing those id's (make them optional or make them strings) when I got time.
could you post a list of suggested changes for the pvr api somewhere and why you need those things changed please. a trac ticket, github issue or a post in the sticky api thread, so I won't forget
thanks. I'll look into it as soon as I got time.