DirectTV SHEF IP Control Plugin for TVServer (4 Viewers)

[ajp8164]

The file belongs in the "c:\program files (x86)\team mediaportal\mediaportal tv server\plugins directory"

That's correct. Thanks for clarifying. I'll check the wiki and improve the instructions.
This plugin has been working great for me, hope you like it!

 

[ajp8164]

Yikes, I thought this thread was dead. I just got a email that there had been a reply to this thread today... maybe something wrong with the forum software for missing everything in-between?

Thanks to ajp8164 for updating this

It's a great plugin... No IR software needed with this plugin! Thanks for creating it!

 

[meinoc]

I went over to https://forum.team-mediaportal.com/forums/tv-server-plugins.294/
and I do not find my message there in that forum.
A) is this the correct forum?
B) can you confirm it's there?

Thanks as I really would like to get this going -- sounds very well done

 

[sjevtic]

Has anyone been successful using this plugin in MP 1.3.0 beta? What I have noticed is that when starting (i.e., from receiver off) live TV from the TV guide, the first channel set never works. Instead, the receiver comes up tuned to whatever channel it was last tuned to. Successive channel changes, as long as the receiver is not turned off, work fine.

I looked at Wireshark logs for both scnearios, and both appear to be roughly the same: a "/remote/processkey?key=poweron" request followed by a "/tv/tune?major=xx&minor=65535" request (where xx is the desired channel) and finally another "/remote/processkey?key=poweron". All are acknowledged by the receiver successfully (200). Perhaps there's something odd here about the timing?

Thanks.

Sasha

 

[sjevtic]

Has anyone been successful using this plugin in MP 1.3.0 beta? What I have noticed is that when starting (i.e., from receiver off) live TV from the TV guide, the first channel set never works. Instead, the receiver comes up tuned to whatever channel it was last tuned to. Successive channel changes, as long as the receiver is not turned off, work fine.

I looked at Wireshark logs for both scnearios, and both appear to be roughly the same: a "/remote/processkey?key=poweron" request followed by a "/tv/tune?major=xx&minor=65535" request (where xx is the desired channel) and finally another "/remote/processkey?key=poweron". All are acknowledged by the receiver successfully (200). Perhaps there's something odd here about the timing?

Thanks.

Sasha

I did a bit of investigating, and as it turns out, I was never able to reproduce the problem when manually sending HTTP requests to the STB in my web browser. Moreover, the results I got when doing so exactly matched those produced by TV Server and the DirecTV SHEF IP plugin--the only thing appreciably different was the timing. I was a bit surprised by the gratuitous power on request as well, but more on that in a bit. I was also surprised to see the order of SHEF-related events in my TV-Server log:

2012-12-22 10:04:00.261748 [(26)]: DirecTV_SHEF - DirecTV_SHEF_OnTvServerEvent(): Changing Channel - Card Id = 1, Channel = 11 (11 WTTWDT), Video Source: YRYBYInput1
2012-12-22 10:04:01.219803 [(26)]: DirecTV_SHEF - DirecTV_SHEF_OnTvServerEvent(): Power on receiver - Card Id = 1

Apparently, the TV-Server generated a channel change event prior to powering on the receiver. That seems counter-intuitive, but apparently that's just how things go. Also interesting is the author's comment in the channel change event handler:

// We must send a power on command since the TVE doesn't send a start timeshifting until after the channel is successfully tuned.

So, apparently the TV-Server doesn't send a power on event until after the channel change event, but yet requires that the signal be received before the channel change is considered complete. That seems to be a bit of a chicken and egg problem, so the author of the DirecTV SHEF IP plugin responded by sending a power-on request right before the channel change request. That explains the seemingly gratuitous power on request I saw in my WireShark logs.

So, I set out to experiment, and this is what I came up with (right file is my patched version, left file is original DirecTV SHEF IP plugin v1.2):

Left file: M:\DirecTV_SHEF 1.2\src\DirecTV_SHEF.cs
Right file: M:\DirecTV_SHEF\src\DirecTV_SHEF.cs
46a47,48
>    internal static bool[] DelayNeeded = new bool[4] { true, true, true, true };
>    internal const int DelayTime = 1000;
156,157c158,159
<          Log.Debug("DirecTV_SHEF - DirecTV_SHEF_OnTvServerEvent(): Power on receiver - Card Id = {0}",
<                    tvEvent.Card.Id);
---
>          //Log.Debug("DirecTV_SHEF - DirecTV_SHEF_OnTvServerEvent(): Power on receiver - Card Id = {0}",
>          //          tvEvent.Card.Id);
159c161
<          SendDTVCommand("remote/processKey?key=poweron", tvEvent.Card.Id);
---
>          //SendDTVCommand("remote/processKey?key=poweron", tvEvent.Card.Id);
173a176,181
>            if (DelayNeeded[tvEvent.Card.Id - 1])
>            {
>                Log.Debug("DirecTV_SHEF - Starting {0}ms receiver sanity delay because it was probably off", DelayTime);
>                System.Threading.Thread.Sleep(DelayTime);
>                DelayNeeded[tvEvent.Card.Id - 1] = false;
>            }     
184a193
>          DelayNeeded[tvEvent.Card.Id - 1] = true;

Basically, what I did was add a one second delay between the power on request and the channel change when it appears that the receiver is starting from the off state. One second seems like a lot, but on my setup, 500ms sure didn't work. In addition, I got rid of the power on request associated with the similarly-named TV-Server event since it appeared unnecessary considering that a channel change request will always precede it, and by necessity, that will include a power on request for the STB as well.

I thought about adding the delay flags as members of the DirecTV_Receiver objects. That would have been the truly OO-ish way to do this, but I gave up on that since the DirecTV_Receiver objects aren't all nicely stored in an array making them easy to access.

As an additional optimization, I could have avoided performing the the power on request if the receiver is already on, but I don't have a good and easy way of truly knowing that, and making an incorrect assumption would cause an ugly mess when trying to start TV with the receiver off. I did, however, avoid needlessly performing the delay if I believe the receiver is already on. That prevents the average-case channel change from becoming slower, and even if I get it wrong (e.g., because the receiver's front panel switch was used), the worst consequence is an occasional slow channel change or coming up with the wrong channel.

Is this approach reasonable? Is there a better way to make this work? Sadly, I don't have any logs or Wireshark traces from my old MP 1.2.3 setup. I'm kind of curious how this all managed to work before, but given that DirecTV is always messing around with their receiver firmware (and you don't get a choice regarding upgrades), it's anybody's guess as to what happened. I've attached my DirecTV_SHEF.cs in case anyone wants to take this for a spin--just drop it in over the original and rebuild. If the response is positive, I'd be happy to post a new "official" build of the plugin.

In summary, I think there are two issues here that got us here:

• TV-Server sends a channel change event before sending a power on event. There may be architectural reasons for this that I don't understand.
• The DirecTV STB cannot tolerate a power on request immediately followed by a channel change request, but only when the STB is starting out in the off state. This is almost certainly a bug in the DirecTV STB firmware.

Sasha

 

[karhill]

I'm a MP newbie (coming from SageTV). I just discovered this plugin. I'm wondering if the plugin can control set top boxes other than ones from DirectTV? I've got some Motorola DCX700 set top boxes supplied by my cable company. These boxes have an ethernet port. But I don't know if they support SHEF (set-top http exported functionality).

 

[sjevtic]

I'm a MP newbie (coming from SageTV). I just discovered this plugin. I'm wondering if the plugin can control set top boxes other than ones from DirectTV? I've got some Motorola DCX700 set top boxes supplied by my cable company. These boxes have an ethernet port. But I don't know if they support SHEF (set-top http exported functionality).

No, the plugin is for DirecTV STBs only. As far as I can tell, SHEF is some proprietary protocol that DirecTV invented for automation environments to control their receivers over some sort of JSON/HTTP over IP interface. I haven't seen it implemented in any other STBs.

Now, with that said, the plugin does provide a reasonable framework for controlling a STB over IP, or, with a bit more modification, over a variety of other interfaces. So, if you can find (or reverse engineer) the protocol for controlling your Motorola STB over IP, it shouldn't be that hard to modify the plugin to support it. The design is pretty simple.

By the way, in the time since I've last posted in this thread, I found another issue with the plugin which causes a variety of problems when multiple streams (e.g., from multiple STBs) or multiple clients (e.g.,interactive timeshifting from TV client plugin, recordings, or MPExtended users) are present, the result of which is typically the loss of a or multiple streams for all clients as soon as one client moves away from a stream. I implemented a workaround, though I won't claim it's airtight. There might be some issues with the underlying events that TV-Server generates, though I haven't fully convinced myself of that yet. In any case, as soon as I have a bit of time, I'll post my source changes and a build of a new version of the plugin against TV-Server 1.3.0 binaries.

Sasha

 

[karhill]

Thanks for the info, it confirms what I've seen, namely that SHEF is a DirectTV protocol.

As for modifying the plugin for Motorola, I could probably code the changes, but the hard part would be coming up with the Motorola protocol for STB control over the network port. I'm not even sure the Motorola box supports that functionality and whatever documentation I've found about the Ethernet port on the Motorola box is vague about it's capabilities. It would be hard to reverse engineer the protocol with Wireshark if I'm not able to get the device to generate any traffic over the network port.

Thanks again.

 

[sjevtic]

Thanks for the info, it confirms what I've seen, namely that SHEF is a DirectTV protocol.



As for modifying the plugin for Motorola, I could probably code the changes, but the hard part would be coming up with the Motorola protocol for STB control over the network port. I'm not even sure the Motorola box supports that functionality and whatever documentation I've found about the Ethernet port on the Motorola box is vague about it's capabilities. It would be hard to reverse engineer the protocol with Wireshark if I'm not able to get the device to generate any traffic over the network port.



Thanks again.

There really is no guarantee that the device is controllable over IP/Ethernet, or even that the Ethernet port performs any useful function. I've found it interesting and disturbing how slow the adoption of Ethernet has been for a lot of applications where it would be amazingly useful, such as A/V control and automation. Although I've noticed Ethernet ports popping up on a variety of embedded devices over the past few years such as receivers and low-end PBXes, all too often these ports are inactive or at least do not have any documented functionality. Presumably the ports are showing up just because Ethernet support is included in the microcontroller (err, system-on-chip, to use the currently hip buzzword). I wouldn't be surprised if that were the case with your STB.

As you pointed out, Wireshark will be pretty much useless here unless you can catch your STB in the act of being controlled by a device that supports its control protocol, assuming it supports that.
Sasha

 

[dabineri]

I am finding that after a power outage, the DirecTV STB will change its ip address and, therefore, MP is unable to change the channels.

Am I correct in this observation? How is this remedied? Thanks, Dave