HME createStream long delay

[moyekj]

When using HME createStream for creating a video stream there is a several second delay during which Tivo builds up a stream buffer before displaying the stream.

Was wondering if there is any control over this at all on the HME side? Perhaps a URL option of some sort to specify buffer size or display delay time?

The reason this is important is I'm working on a way to allow jumping ahead of Tivo's stream buffer when streaming video. Thus, for example if the Tivo buffer is at 5 minute mark but user wants to jump to 8 minute mark (or any arbitrary point beyond the Tivo buffer end point). Only reliable way I've found to do this is to close down the current stream and start a new stream at a specified byte offset. That works, but there is a several second delay on the Tivo side displaying the newly started stream. I was hoping with some additional control I could somehow reduce that delay.

[wmcbrine]

Undoubtedly there is some such option, because the YouTube videos don't take 13 seconds to start up. But I don't know what it is (I've posted everything I know about the subject in the "Video Streaming in HME" thread), TiVo isn't publishing it (so far), and no one else seems to be investigating.

[moyekj]

Undoubtedly there is some such option, because the YouTube videos don't take 13 seconds to start up. But I don't know what it is (I've posted everything I know about the subject in the "Video Streaming in HME" thread), TiVo isn't publishing it (so far), and no one else seems to be investigating. Good point about YouTube. Perhaps it's time for me to pull out the old hub and do some network sniffing during YouTube streaming to see if that reveals anything.

[moyekj]

Not sure anything useful can be gleamed from network sniffing YouTube. Here's a snapshot of the most interesting/relevant lines:

1844 22.305604 192.168.1.1 192.168.1.107 DNS Standard query response CNAME vp.video.l.google.com A 209.85.139.176

1849 22.357611 192.168.1.107 209.85.139.176 HTTP GET /videodownload?version=0&secureurl=pgAAALxRpszUgTK_K_xaZ04iy5uC7Q4tXbv1F2HPywwi8bpANh n7uRBwayqUsi5EHmXpoliqwcwMDMHwfsQt4OnRpnm9WmAEzORjpyPSqcctK5 kcSoo1Fk_OSkVOBQRgLkxdnTlPctXMhWDegOPreYu51tJfmLw5q4XystFMXP vy0NxLmufjoVa0HHUyVyXpqxZKdVFY72FUx4S2zFVCuOpmXYST4oTLxYmPMW 0FWu0RJ_Q2&sigh=HwVtUInwj4QAQlaOXm2HOUVo5f8&begin=0&len=821000&docid=2230210229661132749&client=337482713933&key=wgv9zkrJNjHGVAHpaF2MoGD9LlbsOl3qUImVMV6ramM HTTP/1.1

1863 22.660892 192.168.1.107 209.85.141.176 HTTP GET /videodownload?version=0&secureurl=pgAAALxRpszUgTK_K_xaZ04iy5uC7Q4tXbv1F2HPywwi8bpANh n7uRBwayqUsi5EHmXpoliqwcwMDMHwfsQt4OnRpnm9WmAEzORjpyPSqcctK5 kcSoo1Fk_OSkVOBQRgLkxdnTlPctXMhWDegOPreYu51tJfmLw5q4XystFMXP vy0NxLmufjoVa0HHUyVyXpqxZKdVFY72FUx4S2zFVCuOpmXYST4oTLxYmPMW 0FWu0RJ_Q2&sigh=HwVtUInwj4QAQlaOXm2HOUVo5f8&begin=0&len=821000&docid=2230210229661132749&client=337482713933&key=wgv9zkrJNjHGVAHpaF2MoGD9LlbsOl3qUImVMV6ramM&rdc=1 HTTP/1.1

There are &begin and &len options in the above...

[wmcbrine]

I think the side you want to look at is the HME side. Of course it's probably SSL'd.

[moyekj]

I think the side you want to look at is the HME side. Of course it's probably SSL'd. Yes unfortunately most of the communications are secure/encrypted so it's hard to pull anything useful out of the packet dump.