View Full Version : PyHME support of trickplay
12-01-2011, 08:48 AM
I am in the process of writing an MP3 player app for PyHME and I noticed that the server built into PyHME does not seem to support the "seek=" parameter on the URL that would allow trickplay to work. I originally thought I could work around this by doing a set_position when I notice the resource dropping from SEEKING back into PLAY. I haven't tried this yet, but as I think about it I don't think it will work because the set_resource is directed at the player which already thinks we're at that position (and even if it didn't think that, I imagine that the set_position simply results in a new HTTP request with seek= specified).
Not having trickplay is not the end of the world. There is no audio if speed != 1, but it would be nice to have a basic FF/REW capability.
Are there any plans to support seek=?
12-03-2011, 03:39 PM
I think this is outside the scope of what I want to do in HME for Python's start.py, but if you use pyTivo as the server for the stream, its music plugin understands the HMO-style Seek parameter.
I'm tentatively planning on modifying pyTivo so it can also take the place of start.py.
12-03-2011, 07:36 PM
I never thought of using pytivo as the server here. That should be easy enough to do as both processes are running on the same host and therefore know the filename by the same path. I was actually looking for other servers that might be out there, but pytivo would be the easiest.
Right now I am taking the datapath portion of the file name and stripping it off in the URL so that start.py can put it back together correctly. I guess when I am using pytivo as the server, I'd have to use the share name as the root of the name of the file to be served, and then the path to the file relative to the share root.
12-22-2011, 05:06 PM
I took your advice and switched my server to pytivo and everything worked like a champ. Recently, however, I upgraded from hme 0.18 to 0.19 and now it's not working. Everything seems fine until I create the stream and then nothing happens. I can see via print statements that I am creating the stream with the correct URL, and if I copy that URL into a wget command line, I get the MP3 file (from pytivo) just fine. However I see no evidence that the URL from the creation of the stream is actually sent to the Tivo. Certainly pytivo never sees anything because I added a print statement there also.
Any Idea what could be broken here? Is there something drastically different about 0.18 versus 0.19 that could have caused this?
Here is the URL I am creating. the IP address and port number are correct for pyTivo, and the share name is correct (My Music). PyTivo never even sees the request. This is occurring from two different tivos.
EDIT: I reverted back to 0.18 and it plays fine once again. The only differences I see are 1) the second parameter to self.put is the string 'ssbd' instead of 'ssb', and in 0.19 there is an additional parameter - a dictionary named params which defaults to being empty.
12-22-2011, 08:11 PM
I assume you saw this:
0.19 -- HME for Python now reports itself as implementing version 0.49
of the HME protocol. This version has not been publicly
documented by TiVo, but the change is necessary in order to
properly support direct text input (including from the Slide
remote). In addition to the new keyboard handling (see above),
there's an added parameter for stream creation: a dict called
"params". None of its possible values are known.
I hadn't seen any difficulties with the empty dictionary in my own testing, but that was probably only with video streams, as I think of it.
12-22-2011, 10:17 PM
No - I hadn't noticed that before, but since none of the values are known, this doesn't give me much to go on. I have tried tinkering with it all night long tonight and nothing seems to work. I create a resource, and it just seems to get lost; I never see the request come in to pytivo. For now, I'm going back to 0.18, but that's not really a solution. I'll keep digging though.
12-26-2011, 10:14 PM
Good news here - I got it to work under 0.19 by just explicitly specifying the mime type. The comment in hme.py stating that mime type doesn't seem to matter led me to just omit it from my call. On a whim, I decided to try adding it to the call, and voila - it worked. I guess now the mime type matters.
vBulletin® v3.6.8, Copyright ©2000-2013, Jelsoft Enterprises Ltd.