These commits add basic PVR support to JSON-RPC. My main goal was to focus on being able to start a pvr channel and control it through the Player methods already available. Information retrieval like EPG or Timer control are secondary IMO.
I made the following adjusments to the Player methods:
Furthermore I've added a new PVR namespace with the following methods:
As stated this is IMO the most basic support necessary. We could even drop PVR.Record and PVR.Scan if there's a problem with those two.
We'll probably have to add an extra method to either CPVRManager or CPVRChannelGroupContainer to get a list/vector of all channelgroups without having to use the FirstGroup() and NextGroup() methods which are not save in case a channel scan is started while JSON-RPC works through that list.
NB: This is lacking the Xcode project file updates and I was only able to test the changes on tv channels so far. @mizaki was kind enough to test all the changes on his backend (tvheadend) on both tv and radio channels. PVR.Record is completely untested.
I don't think we need a channel scan via JSONrpc atm - but beeing able to trigger a recording would be great (even if only instant recording for now)
@opdenkamp: Could you take a look at the CPVRChannelGroups::GetMember() method I added? And could you provide me with a pointer to where I should add the stop/play announcements in CDVDPlayer upon a channel switch?
added method looks fine. as for the play/stop announcements, these are hidden in CApplication. do we really want to notify OnStop + OnPlay, when we actually didn't stop and play, but just switched to another file?
This is how it works for video and music playlists. When an item is done amd the next one is started, OnPlaybackStopped and OnPlaybackStarted is called which send the OnStop and OnPlay notification. I guess the reason is that the player doesn't have to know about the playlist.
let's just do OnStop+OnPlay now then so it matches the other code. but only sending OnPlay, or creating a new OnChannelSwitch seems cleaner to me.
Actually I'm kinda confused right now. OnStop should really only be called when a user manually stops playback (with "end": false) or if XBMC stops playback because it reached the end of a playlist (with "end": true). CDVDPlayer (and CAMLPlayer and COMXPlayer) calls CApplication::OnPlayBackStopped/OnPlayBackEnded() in OnExit() whereas CPAPlayer calls CApplication::OnPlayBackStopped() in CloseFile(). I don't have any media available right now so will have to test at home. Last time I worked on announcements it was because the PAPlayer re-write didn't have all of them and IIRC PAPlayer sends a Player.OnStop after every file it finished playing.
i see you discussed it on irc :)
Yeah figures it makes sense to call OnPlaybackStopped (and send the OnStop announcement) after every item as the playback of that specific item has stopped (independent of what happens afterwards). The question is where to put this in CDVDPlayer for channel switching or if it should stay in CPVRManager as it is now.
let's go for the easy option (in pvrmanager) for now and move it later on if/when required
CEpgInfoTag: implement ISerializable
CPVRChannel: implement ISerializable
CEpgInfoTag: add Progress() method to return the progress in seconds
CPVRChannelGroups: add GetMember() to get a full list of the channel …
…groups currently available
jsonrpc: integrate CPVRChannel with type "channel"
jsonrpc: add PVR support in Player namespace
pvr: add OnPlay and OnStop notifications when switching channels
jsonrpc: add PVR namespace
Available methods are GetProperties, GetChannelGroups,
GetChannelGroupDetails, GetChannels, GetChannelDetails,
ScanChannels and Record
[win32] update VS project files
jsonrpc: add "channelid" property to Player.Open's "item" parameter t…
…o start a PVR channel
Looks like this one needs osx/ios and makefile adaptions - am i right?
Makefile is already updated (you scared the hell out of me. I was already half way to retrieving my anti-cptspiff-armour) but yes I forgot about the xcode project files. Sorry about that. Can you please fix it up for me?
Sure once i hit my home later ... :)
This causes a dead lock. While this is called from dvdplayer thread, grabs the lock in CAnnouncementManager and waits for the lock in GuiWindowManager::IsWindowActive. Meanwhile the main thread waits for the lock in CAnnouncementManager. Main thread is in GuiWindowManager::Process
Hm that's not good. Thanks for tracking it down. I already discussed this with opdenkamp when I posted the PR and ideally this would be done in CDVDPlayer and ideally it would call the appropriate IPlayerCallback methods. But opdenkamp decided to put this in as-is and clean it up afterwards. I don't use PVR and I don't know the CDVDPlayer code so I didn't dare just hacking around in there.
I didn't say it's a dvdplayer issue. I said these announcements should be replaced with a call to IPlayerCallback::OnPlayBackStopped() and OnPlayBackStarted() which would result in calling these callbacks on CApplication which would then automatically send these announcements.
@opdenkamp proposed to move these callbacks to wherever we do the channel switching in CDVDPlayer because CDVDPlayer knows the proper implementation of IPlayerCallback and already calls these callback methods.
But that will probably not solve the dead lock. The cause of the dead lock is our very ... let's say limited ... implementation of slideshows. The announcement manager needs to figure out which player is active when one of the IPlayerCallback methods is called. The only way to determine whether a slideshow is playing is to ask CGUIWindowManager whether CGUIWindowSlideShow is active or not.
not a very pretty solution, but this does the trick too: beca8d8
the announcements are sent by the pvrmanager's bg thread,after this. not very pretty, but that can be fixed later.
Thanks for fixing the crash/deadlock.
Revert "Merge pull request #1594 from Montellese/jsonrpc_pvr"
This reverts commit 504e9c4, reversing
changes made to 21f7d94.
Those changes seem to slow down navigation in pvr window. I noticed that a lot of remote button pressed were not recognized. Scrolling down the channel list was very slow on my system.
@FernetMenta do you know if the unrecognized remote button presses are related to the dead lock you tracked down? The only real changes in this PVR that could affect the general behaviour of PVR are the changes in CPVRManager AFAICT.
@Montellese I noticed some strange behavior when I was testing this. First I thought something is wrong with my remote, then I encountered the dead lock and tracked this down. That's all I know at this time.
the deadlock makes sense and needs fixing, but i don't see anything slowing down here