[CrashX]

that wouldn't fit in any structure on the current interface. what does it represent? it doesn't match anything in the current htsp interface from tvheadend.

could you define "enough information" for me please.

For more information about programid ( http://forum.xbmc.org/showthread.php?tid...+programid )

Basically, what I wanted to know do you have enough metadata information to add recordings to the XBMC Library ( fanarts, plot, cast, etc ) ? Can you tell now if the recording is a tv show or movie ?

http://forum.xbmc.org/showthread.php?tid=65644

[opdenkamp]

I haven't spend time on getting the recordings into the library. dteirney said on irc he wanted to spend time on that a couple of weeks ago.

we'll probably could use some more metadata on the interface for recordings. most of the metadata that is in there now is vdr specific and will be removed later. just didn't do it yet cause I didn't check whether vdr uses that somewhere.

that programid is something specific to myth. it's not available on any other pvr backend as far as I can see. so I won't add it to the interface in that form.

if dteirney hasn't implemented recordings in the library after the binary add-on interface is implemented, I'll have a look at it myself.

the recording infotag extends from videoinfotag, so if metadata is to be added to the interface, it should be members of those tags.

[opdenkamp]

I forgot to mention something which is important for add-on authors:
the pvrmanager no longer "auto updates" timers, channels, recordings and channel groups. if something changed on the backend and if you think the pvrmanager needs to update it's data, you call a trigger:
TriggerTimerUpdate - when timers need to be updated in xbmc
TriggerRecordingsUpdate - same for recordings
TriggerChannelsUpdate - for channels
TriggerChannelGroupsUpdate - for channel groups

these triggers currently update the data from all connected backends, which will be changed later so only the data from the add-on that calls the trigger will be updated.

as you might expect from something called "trigger": all updates are async.

[opdenkamp]

and yet another change, but minor this time: instant timers (recordings that are started immediately on the channel that is currently playing) will have their start time set to 0/invalid. I'm changing this because a time difference between xbmc and the backend might prevent these instant timers from working correctly.

[danips]

Hello dushmaniac,
is there any plan for adding triggers to force the update of the EPG info?

I think it would be useful because I am having this problem: if I launch my test addon and I haven't the complete EPG info for the actual day, the first chronological program found is stretched down to the beginning of the timeline. And then I have to wait the "EPG update interval" (15 minutes minimum) in order to be asked again for the EPG info and get a correct timeline.

BTW is this the correct behaviour? I think I remember it was leaving a blank gap if there was no program at he beginning of the timeline in earlier versions.

[opdenkamp]

that's a bug in the timeline view. the actual event isn't "stretched", as you can see in the
"now playing" lines in the channels list, where it will say "no information available".

I'll add a trigger to update the epg later.

[danips]

thanks for your answer, do you know if somebody is working on a fix for it?

[opdenkamp]

nope, I'm the only one working on pvr, except for some people who are working on add-ons and are sending me a patches from time to time.
please create a ticket for this on trac and add me to the cc list. I'll look into it later.

another API change:
bIsRecording has been removed from the PVR_CHANNEL struct. this can be determined by timers.

[javich]

Hi dushmaniac

I think one of the most requested features for the MediaPortal Backend is the ability to record tv series but, as Margro points out (see http://forum.xbmc.org/showpost.php?p=769...tcount=665), in order to implement that the PVR API needs to be extended to allow this. Are you considering this feature in your current changes to the API?

From what I read in the forums, my guess is that this would complete a very standard feature set for the different backends.

PS have you noticed that your consider donating to me link takes you to a Fatal Failure page?

Thanks,
Javier.

[dubstar_04]

Could this be made a stickie?

it would be good to use this tread for issues once the binary add-ons are working. thanks.

[opdenkamp]

stickied.

and I completely missed that previous post.

I think one of the most requested features for the MediaPortal Backend is the ability to record tv series but, as Margro points out (see http://forum.xbmc.org/showpost.php?p=769...tcount=665), in order to implement that the PVR API needs to be extended to allow this. Are you considering this feature in your current changes to the API?

depends on the changes. what changes are we talking about exactly?

PS have you noticed that your consider donating to me link takes you to a Fatal Failure page?

never noticed it. fixed it so it takes you to the "xbmc pvr binaries page" with a button under the links to the binaries

[opdenkamp]

two API changes:

m_bSupportsChannelLogo has been removed. set an url or path that's readable by the xbmc vfs to the logo in the PVR_CHANNEL struct.

bIsActive and bIsRecording have been removed from the PVR_TIMER struct and a new enum PVR_TIMER_STATE has been added:

Code:

typedef enum
{
  PVR_TIMER_STATE_INVALID   = 0,
  PVR_TIMER_STATE_SCHEDULED = 1, /*!< @brief the timer is scheduled for recording */
  PVR_TIMER_STATE_RECORDING = 2, /*!< @brief the timer is currently recordings */
  PVR_TIMER_STATE_COMPLETED = 3, /*!< @brief the recording completed successfully */
  PVR_TIMER_STATE_ABORTED   = 4, /*!< @brief recording started, but was aborted */
  PVR_TIMER_STATE_CANCELLED = 5  /*!< @brief the timer was scheduled, but was cancelled */
} PVR_TIMER_STATE;

I've edited the add-ons in the tree to use the new interface, but add-on authors should check whether I did it properly.

[dteirney]

I'd say that there is no problem when they're on the same channel, but when they're on different channels (which would most likely be the case) one will have to "win", you either run the risk of losing the end of one recording or the beginning of the other.

Because of you decide to not take into account the margins for back-to-back recordings you run risk of losing BOTH the end AND the beginning of the two recordings!

On the other hand if your channel providers have good EPG data and almost never have under/overrun of their programs and you have the margins "just to be sure" it might actually be better to just change the moment the next program starts.

It not simple to come up with something that always works

This isn't the case if your backend can record the overlap, either due to multiple tuner cards or other packet magic for multiplexed channels using DVB-T. My MythTV setup using DVB-T with mutliplexing can record the overlap for both shows. The MythTV scheduler takes this into account when assigning recording tuners to channels that need to be recorded.

[opdenkamp]

been a while since I posted here, but another change is pending:
I've changed the tvheadend add-on a bit, so it no longer uses /lib/libPlatform and /lib/libTcpSocket anymore, but /lib/platform instead. This implementation is no longer using pthread-win32, and uses mutex protected sockets instead of raw sockets.

/lib/libPlatform and /lib/libTcpSocket will be removed in the near future, and won't be included when we'll merge PVR with mainline XBMC later on. FernetMenta will change the vnsi add-on, and I will take care of anything else that's still using that code.

Add-ons that are not in our main tree should be updated by their authors, or they'll break when they are using this code.

[margro]

Thanks for reporting. I will take care of the MediaPortal addon and send you a pull request when done...