Trying to use Data API in service code gives me an error. It works fine in plugin init. Any ideas? Can I import it somehow?
if Data.Exists(video_hash): NameError: global name 'Data' is not defined
Thanks.
Hmm that's a good question that I don't have an answer for. Maybe Mike will know. Have you tried accessing it from Shared code?
Thanks for the reply.
What do you mean by shared code? How do I do that? I was hoping the service code and the channel code could share code, but how?
Thinking about the short request lifecycle of service code, maybe it doesn't make sense to store data there. I just thought that since I'm making a lot of repeated HTTP requests and parsing of the same urls that I could cache the results. I know plex will cache those HTTP requests internally, but I did some testing and doing my own caching with the data api is faster than the http caching.
By design, URL Services do not have access to stored data and do not cache data. If you're making that many requests to your URL Service, you're probably not using it correctly.
Loading a list of videos in the plugin should not make any calls to the URL Service aside from checking that a Service exists for any URLs provided (done automatically). Ideally, an URL Service should only be called via the plugin when the play request is made. All other metadata should be gathered in the plugin. That may seem like some code duplication in that both the plugin and URL Service are expected to return metadata but that's the way it was designed and there was good reason to do so. Not every channel will fit the mold for which URL Services were designed but most can be made to work well within the scheme.
So, if your plugin is timing out due to calls to the URL Service, consider why the it's doing so before starting to design your own cache.
The only thing that sucks about not having access to stored data generated by the plugin side is authentication. Not being able to access username/password or other plugin generated info such as a session ids causes a lot of issues for the more security conscious content providers. Someone mentioned 6 or 8 months ago that Plex was working on the problem, but i haven't seen anything recently. I asked Sander1 via email recently but didn't get a response.
By design, URL Services do not have access to stored data and do not cache data. If you're making that many requests to your URL Service, you're probably not using it correctly.
Loading a list of videos in the plugin should not make any calls to the URL Service aside from checking that a Service exists for any URLs provided (done automatically). Ideally, an URL Service should only be called via the plugin when the play request is made. All other metadata should be gathered in the plugin. That may seem like some code duplication in that both the plugin and URL Service are expected to return metadata but that's the way it was designed and there was good reason to do so. Not every channel will fit the mold for which URL Services were designed but most can be made to work well within the scheme.
So, if your plugin is timing out due to calls to the URL Service, consider why the it's doing so before starting to design your own cache.
Ok, thanks. The site I'm working with requires 2 http requests: first for the page at the given url, second for the iframe with the video data. There's no way around that, so I just thought since I have to request and parse both pages in both the MetadataObjectForURL and MediaObjectsForURL, it might make sense to cache it the first time and save a few resources. I guess not.
Using the same session ID in the URL service as in the plugin is definitely desirable but not really a feature of the current setup. Username and password prefs are accessible in the URL Service if you keep the URL service in the channel bundle (rather than the global Services.bundle) and use a ServicePrefs.json file rather than the DefaultPrefs.json. It is also possible to “cheat” and pass the session ID (or other necessary data) in the URL itself by appending it preceded with a ‘#’, eg.
http://myurl.org/myvideo/video_id#session_id=blah
Then the session ID is parsed out of the URL in the service code. This method is not generally encouraged but, IMO it can be very helpful in bridging the gap where an URL Service might not otherwise work well.
A couple HTTP requests for metadata and then again when requesting playback is not uncommon. I wouldn’t think that the delay would be significant, as long as you’re not making the requests in the MediaObjectsForURL() function. Any requests necessary to find the final playback URL should be handled via a callback so that MediaObjectsForURL() can return without any delay.
Using the same session ID in the URL service as in the plugin is definitely desirable but not really a feature of the current setup. Username and password prefs are accessible in the URL Service if you keep the URL service in the channel bundle (rather than the global Services.bundle) and use a ServicePrefs.json file rather than the DefaultPrefs.json. It is also possible to "cheat" and pass the session ID (or other necessary data) in the URL itself by appending it preceded with a '#', eg.
http://myurl.org/myvideo/video_id#session_id=blahThen the session ID is parsed out of the URL in the service code. This method is not generally encouraged but, IMO it can be very helpful in bridging the gap where an URL Service might not otherwise work well.
A couple HTTP requests for metadata and then again when requesting playback is not uncommon. I wouldn't think that the delay would be significant, as long as you're not making the requests in the MediaObjectsForURL() function. Any requests necessary to find the final playback URL should be handled via a callback so that MediaObjectsForURL() can return without any delay.
Mike,
Out of curiosity (and lack of being near my computer at the moment to test) does the service code automatically parse out variables from the URL that you declare using this method? (URL#variable=value) Or is this something you have to do in the service code manually? The reason i ask is because this is exactly the method that i use in my Crunchyroll plugin. (Although i use the & symbol instead of the #) The only downfall to this method that I've seen is that since the URL is used as the rating_key for the episodeobject it messes with Plex's ability to track that video as a unique object. (Watched status, etc) Every time your session_id changes the URL is going to change for that video. Thus Plex thinks it's a different object/video. Or am i wrong here? Using this method i was never able to get watched/unwatched statuses working.
The Service code will not automatically parse our “cheater” args when appended with the #. That needs to be done manually in the code. The reason I suggest using ‘#’ rather than ‘&’ is that standard behaviour for HTTP servers is to ignore everything after the first instance of ‘#’ in a URL. That way we don’t have to worry about what possible ill effects might arise by passing our “cheats” to the website host.
The watched/unwatched status is a different issue entirely. At present, there is no support for tracking watched status for channel content. My understanding is that it requires some (non-trivial) work on the PMS side to keep track of channel content as a part of the larger library scheme. IIRC, it’s on the list of things which will hopefully be added someday. In the meantime save your energy trying to get it to work 
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
