Skip to content
This repository

JSON-RPC: basic PVR support #1594

Merged
merged 10 commits into from over 1 year ago

6 participants

Sascha Montellese da-anda Lars Op den Kamp Memphiz Rainer Hochecker Joakim Plate
Sascha Montellese
Collaborator

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:

  • added "channelid" as a possible parameter to Player.Open which allows to play any PVR channel (tv or radio)
  • extended Player.GetItem with some CPVRChannel logic and some new properties like starttime, endtime etc
  • adjusted Player.GetProperties to take PVR into account and added a new "live" property
  • Player.Seek and Player.PlayPause are only executed when the active player supports it Player.GoTo supports switching a channel based on the channelnumber in the currently active channel group in the GUI

Furthermore I've added a new PVR namespace with the following methods:

  • PVR.GetProperties with "available", "recording" and "scanning"
  • PVR.Record which can take "current" or a channelid to toggle recording (no scheduled record support yet)
  • PVR.Scan to scan for channels
  • PVR.GetChannelGroup(Detail)s to access channel groups
  • PVR.GetChannel(Detail)s to access channels in a specific group

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.

da-anda
Collaborator

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)

Sascha Montellese
Collaborator

@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?

Lars Op den Kamp
Collaborator

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?

Sascha Montellese
Collaborator
Lars Op den Kamp
Collaborator

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.

Sascha Montellese
Collaborator

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.

Lars Op den Kamp
Collaborator

i see you discussed it on irc :)

Sascha Montellese
Collaborator

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.

Lars Op den Kamp
Collaborator

let's go for the easy option (in pvrmanager) for now and move it later on if/when required

Sascha Montellese Montellese merged commit 504e9c4 into from
Memphiz
Owner

Looks like this one needs osx/ios and makefile adaptions - am i right?

Sascha Montellese
Collaborator

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?

Memphiz
Owner

Sure once i hit my home later ... :)

Rainer Hochecker

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

Collaborator

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.

Collaborator
Collaborator

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.

Collaborator

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.

Collaborator

Thanks for fixing the crash/deadlock.

Rainer Hochecker FernetMenta referenced this pull request from a commit in FernetMenta/xbmc
Rainer Hochecker FernetMenta Revert "Merge pull request #1594 from Montellese/jsonrpc_pvr"
This reverts commit 504e9c4, reversing
changes made to 21f7d94.
ecf9f81
Rainer Hochecker
Collaborator

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.

Sascha Montellese
Collaborator

@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.

Rainer Hochecker
Collaborator

@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.

Lars Op den Kamp
Collaborator

the deadlock makes sense and needs fixing, but i don't see anything slowing down here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.