No matter how I modify this, the function test always gets called twice when clicking the menu item in the menu. Removing the @route doesn’t change anything, the randomize parameter doesn’t change anything there (anymore).
If I remember correctly, this used to work - I could “redirect” the user to the main view of my channel by returning the main view itself with a randomized URL parameter.
I’m sorry, but I don’t really get what you’re trying to tell me.
What has the fact, that my main route always gets called twice when I click on the item “test” to do with caching?
When I skip the randomize attribute, the click on the test item will do nothing, because PMS’s routing thinks it’s the same route as the current one.
Is there an official way to refresh the current view? I’ve picked up the randomize technique from the traktscrobbler plugin if I remember correctly. And it should work without calling the main handler twice, from a logical point of view.
As for the redundant handler/route combination: I’ve said in the initial post, that removing the route from the main handler doesn’t change anything (it actually squelches the warning for an unregistered route).
some clients seem to call routes twice. I did a test and PHT and Android both do it.
Plex Web,iOS and PMP just do a single request.
When a client does two requests, the plex media server log shows:
Request: [192.168.1.113:44795] GET /video/test/testroute (13 live) TLS GZIP
Request: [192.168.1.113:44795] GET /video/test/testroute (13 live) TLS Page 0-49 GZIP
the difference in the requests is in Request.Headers
1462471575.21 OpenPHT: GET
# no container headers
1462471575.22 OpenPHT: GET
X-Plex-Container-Size: 50
X-Plex-Container-Start: 0
afaik channels don’t even make use of these paging headers.
test code:
import time
NAME = 'Test'
PREFIX = '/video/test'
def Start():
pass
@handler(PREFIX, NAME)
def MainMenu():
oc = ObjectContainer(title2='test')
oc.add(DirectoryObject(key=Callback(Test), title='test'))
return oc
@route(PREFIX + '/testroute')
def Test():
Log.Info('{} {}: {}'.format(time.time(), Client.Product, Request.Method))
for k, v in sorted(Request.Headers.iteritems()):
Log.Info(' {}: {}'.format(k, v))
oc = ObjectContainer()
oc.add(DirectoryObject(key=Callback(Test), title='test'))
return oc
so some really hacky solution could be to put
if (Client.Product in ['Plex for Android', 'OpenPHT'] and
'X-Plex-Container-Size' not in Request.Headers and
'X-Plex-Container-Start' not in Request.Headers):
Log.Info('skipping request')
return ObjectContainer()
at the start of a route function so those clients only run code below it for the 2nd request.
@coryo123 thanks - I really don’t know why Plex behaves like that. It doesn’t really make any sense to me.
Also in my case it’s not related to any direct pagination requests.
Does that also apply to my example, where I try to “refresh” the main route by returning the original ObjectContainer with a randomized parameter?
# initial menu
INFO (logkit:16) - MainMenu: None OpenPHT: GET
INFO (logkit:16) - X-Plex-Container-Size: 50
INFO (logkit:16) - X-Plex-Container-Start: 0
# press button, double request
INFO (logkit:16) - Sub Menu
INFO (logkit:16) - MainMenu: 1462486849.5 OpenPHT: GET
INFO (logkit:16) - X-Plex-Container-Size: None
INFO (logkit:16) - X-Plex-Container-Start: None
INFO (logkit:16) - Sub Menu
INFO (logkit:16) - MainMenu: 1462486849.51 OpenPHT: GET
INFO (logkit:16) - X-Plex-Container-Size: 50
INFO (logkit:16) - X-Plex-Container-Start: 0
no_history only works on PHT though, so every other client is going to end up with a large history stack to back out of. and you will also have the double calls because of the client paging.
Thanks for the tip, I’ll try that. Though I mainly noticed that problem with PlexWeb.
I’m using the technique I’ve posted above for a “refresh” button in the main menu. That results in a real refresh of the main menu and the user doesn’t have to go through another menu for a refresh.
As for handler+route: not using @route with @handler results (resulted?) in warnings in the log and it didn’t impact anything else.
It’s weird that the most used (?) client, PlexWeb, seems to support the least of the available channel development features (no_history, replace parent etc.).
based on the trends with client development, I think it’s safe to assume the history related properties (no_history, replace_parent …) are deprecated. they work for PHT, but plexinc doesn’t develop it anymore.
what you’re trying to do definitely isn’t intended behaviour for the new clients, so it will take some dumb hacks to get something working and even then it might only work on a few clients.
Don’t get me wrong, I want to ditch those hacky solutions. But what’s happening is, that documented features get abandoned and channel development gets ridiculous.
A refresh-current-view feature wouldn’t be too hard for plexinc I think
