TiVo Community Forum banner

No Streaming (MRS) Discovery thread?

17326 Views 53 Replies 9 Participants Last post by  chrispitude
I am surprised we haven't seen an MRS discovery thread similar to the iPad thread. I would love to see MRS from the server integrated into pytivo!

Just trying a friendly nudge... :)

I do realize that this may not be as easy to discover. :D
1 - 20 of 54 Posts
What were you looking to accomplish?

*Edit: saw that you wanted to have pytivo serve up MRS. I can't saw for sure, but drawing an analogy to the original MRV introduced back in sw 4.0+, the reversing done there (which ultimately lead to the creation of "tivoserver") required hacked units (both for the reversing process as well as to use tivoserver to transfer shows), so that wouldn't bode well. That said, it would be quite snazzy to have pytivo allow MRS access to its videos.*

After streaming a video, you can simply pull the drives from the MRS client and server units to look through their logs to find the request URL to initiate the stream.

IIRC, the URL was just a suffix permutation of the MRV URLs, but I can't recall if the stream setup first required a mutual certificate authentication or not. Any such authentication (if present) plus the stream encryption means there's little that can be done, unless you have a way to crack those.
mutual certificate authentication
I suspect this is correct. As I said, I suspect this is a lot easier said then done.

It was fun to follow the iPad discovery thread and I was surprised that we didn't see a similar thread evaluating some of the new functionality.

I suppose it might be happening in the shadows - or - it might just be a whole different animal and not as discoverable.

Either way - have I said that I love pyTiVo!
Well, I don't have 20.2 yet. :) Even then, I only have one Premiere.

Of course, on the extreme end of optimism, it's possible that implementing streaming will be as simple as adding "<StreamingPermission>Yes</StreamingPermission>" to the container XML.
Well, I suppose I will just have to be patient!

Thanks for all the work wmcbrine - it is appreciated.
Of course, on the extreme end of optimism, it's possible that implementing streaming will be as simple as adding "<StreamingPermission>Yes</StreamingPermission>" to the container XML.
Just tried that, after modifying your latest commit to add the tag, it's easy to see that pyTiVo is definitely sending the StreamingPermission tag in the right place (correctly CamelCased), but no change on the TiVo. I also noticed the TiVo sends some new stuff for QueryContainer:
Code:
<?xml version="1.0" encoding="utf-8"?>
<TiVoContainer xmlns="http://www.tivo.com/developer/calypso-protocol-1.6/">
<Details>
<ContentType>x-tivo-container/tivo-server</ContentType>
<SourceFormat>x-tivo-container/tivo-dvr</SourceFormat>
<Title>Mercury</Title>
<TotalItems>2</TotalItems>
</Details>
<ItemStart>0</ItemStart>
<ItemCount>2</ItemCount>
<Item>
<Details>
<ContentType>x-tivo-container/tivo-videos</ContentType>
<SourceFormat>x-tivo-container/tivo-dvr</SourceFormat>
<Title>Mercury</Title>
<UniqueId>Mercury</UniqueId>
</Details>
<Links>
<Content>
<Url>https://192.168.1.42:443/TiVoConnect?Command=QueryContainer&amp;Container=%2FNowPlaying</Url>
<ContentType>x-tivo-container/tivo-videos</ContentType>
</Content>
</Links>
</Item>
<Item>
<Details>
<ContentType>x-tivo-container/tivo-videostream</ContentType>
<SourceFormat>x-tivo-container/tivo-dvr</SourceFormat>
<Title>Mercury</Title>
<UniqueId>Mercury</UniqueId>
</Details>
<Links>
<Content>
<Url>https://192.168.1.42:443/TiVoConnect?Command=QueryContainer&amp;Container=%2FNowPlaying</Url>
<ContentType>x-tivo-container/tivo-videostream</ContentType>
</Content>
</Links>
</Item>
</TiVoContainer>
So I also tried hacking the root template to send an extra Item with a 'x-tivo-container/tivo-videostream' ContentType and with the UniqueId set to the same as the Title, but still no change. Everything looks correctly formatted, and pytivo still functions without complaint fine for push and pull transfers.

Haven't had the time to play more than that.
See less See more
As is the norm for TiVo these days the entire MRS communication between TiVos is SSL encrypted, so packet sniffing MRS communication didn't yield anything useful for me (unlike MRV which did show useful info in the past).
Gotta get me some MITM for that.

The annoying thing for me right now is that I can't even get my Premiere to accept a transport-stream .TiVo file (from the same unit) via pyTivo. Same file via TiVo Desktop, no problem. I've got the TiVo to request the file from pyTivo, but as soon as the file starts to transfer, the TiVo drops the connection. I've copied (almost) all the TD behavior I can see by hitting it with a browser, and clearly it's not enough.

But, I digress.
Not sure how one would MITM easily with both sides of the communications being TiVos. Guess you would have to set Gateway for both TiVo network setups to go through a computer implementing MITM instead of a router.
The annoying thing for me right now is that I can't even get my Premiere to accept a transport-stream .TiVo file (from the same unit) via pyTivo.
Figured it out.

80+ Mbps, here we come. :D
Now the fun begins!
Figured it out.

80+ Mbps, here we come. :D
Does mpeg2 Transport Stream container with H.264 video work as well?
So far no, it transfers but I get a blank screen. This is with 14.9.
Will be interesting to see if 20.2 works any differently. With 20.2 I noticed that choosing secondary audio (SAP) from the Info screen for TV recordings now actually works. Also txporter recently discovered that mp4 with H.264 and multiple audio streams also allows you to switch audio streams. i.e. If you want to make a video that plays on a portable player that requires 2-channel AAC but also plays on a TiVo with the original 6-channel AC3 now it's possible to do so. (maybe that already worked before 14.9/20.2 but I'm not sure). It also looks like TiVo decoder actively looks for Dolby audio stream as first choice regardless if it's the 1st or 2nd audio stream.

The interesting thing about TS container with H.264 would be to eliminate the need for MOOV atom nonsense that mp4 container requires which would also open up possibility/option for pyTivo to transcode to H.264 instead of mpeg2.
Will be interesting to see if 20.2 works any differently. With 20.2 I noticed that choosing secondary audio (SAP) from the Info screen for TV recordings now actually works. Also txporter recently discovered that mp4 with H.264 and multiple audio streams also allows you to switch audio streams. i.e. If you want to make a video that plays on a portable player that requires 2-channel AAC but also plays on a TiVo with the original 6-channel AC3 now it's possible to do so. (maybe that already worked before 14.9/20.2 but I'm not sure). It also looks like TiVo decoder actively looks for Dolby audio stream as first choice regardless if it's the 1st or 2nd audio stream.

The interesting thing about TS container with H.264 would be to eliminate the need for MOOV atom nonsense that mp4 container requires which would also open up possibility/option for pyTivo to transcode to H.264 instead of mpeg2.
That's interesting about the multi-audio streams. Now I have to do some tests and see if I can come up with a handbrake or ffmpeg recipe that produces a file both the Roku and TiVo will accept and play.

If we get streaming enabled from pytivo, I'll be happy with mpeg2. It's faster/easier to encode when using general purpose cpus. I guess if I wanted to store content on the box, h.264 would still be preferable :).
My triumph was pitifully short-lived. 20.2 appears to throttle all connections, in and out, to around 20 Mbps. Perversely, MPEG-2 transfers are now faster than MP4, and program streams are the fastest of all (though not by much), turning everything on its head.

They also broke the transfer of many metadata items, even via real .TiVo files. Apart from all that, it doesn't seem much different (for pyTivo's purposes) from 14.9 -- same kinds of weirdness with transport streams, MP4 pulls still look like they're going to work but don't, etc.
OK, I'm an idiot. Or, put it down to being tired... I was testing from my laptop, which was connected via G. That's where the throttle was.

Metadata is still broken, though.
Naive attempt:

Code:
http://downloadurl&Format=x-tivo-container/tivo-videostream
does not work. I didn't expect it to, but I thought it was worth a try, since I just got streaming enabled. :)

In case you're wondering, x-tivo-container/tivo-videostream comes from QueryFormats:

Code:
<TiVoFormats>
  <Format>
    <ContentType>video/x-tivo-mpeg</ContentType>
    <Description/>
  </Format>
  <Format>
    <ContentType>video/x-tivo-mpeg-ts</ContentType>
    <Description/>
  </Format>
  <Format>
    <ContentType>x-tivo-container/tivo-videostream</ContentType>
    <Description/>
  </Format>
  <Format>
    <ContentType>video/x-tivo-raw-tts</ContentType>
    <Description/>
  </Format>
</TiVoFormats>
It's the only new one. Interesting that it's "x-tivo-container" where the others are "video".
See less See more
There's a Zeroconf announcement of a service associated with streaming. It looks exactly like the "tivo-videos" service, except that it's called "tivo-videostream" (other fields are identical AFAICT).

I tried having pyTivo put out an announcement for tivo-videostream, while adding to QueryFormats and QueryContainer as outlined above. So far, no luck.
I assume you already have <StreamingPermission>Yes</StreamingPermission> added to the XML container for pyTivo video shares right?
1 - 20 of 54 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top