Help get this topic noticed by sharing it on Twitter, Facebook, or email.
I’m confused

Why doesn't iRule treat "Devices" truly independently even if they are attached to the same gateway? It causes problems when doing things like querying directv channel data

I have a setup where I query DTV for what is on my favorite channels, using the HTTP query: http://192.168.0.17:8080/tv/getProgIn... for example.

This works great although as you might expect if you have multiple channels doing this iRule overwrites the data for every channel with the most recent refresh (so it looks like every channel is showing the same thing.

example: if I query channel 501 and then query channel 502, whatever is showing on channel 502 will be listed for channel 501's feedback as well.

To get around this I create a "virtual device" for each channel I intend to query and attach a feedback to each channel's virtual device.

example: I setup a device called "501 query" which does the call above for channel 501, I also set up a device called "502 query" which does the call above for channel 502 (just by changing the url parameter passed). Then I set up 2 feedbacks that are exactly the same but attach one to the 501 query device and the other to the 502 query device.

Boom, this works with one caveat. While logically each "virtual device" is it's own entity they are all really just pointing to one DTV receiver. So my initial setup was to just choose the gateway for that receiver and add all of these virtual devices to it. That's where it breaks.

Even though they are separate "devices" having them attached to the same gateway causes the same problem you'd have with using just one device, the feedback gets over written for all of the virtual devices every time a new one is queried. As soon as I set up separate gateways for each virtual device everything works fine.

This is illogical to me, why wouldn't a "device" have it's own buffer for feedbacks, etc.? Tying it to the gateway seems like a strange approach given that the gateway is really just the communication channel not the information source.

It also causes a whole lot of needless configuration effort for each handset since I have to add so many individual gateways. More concerning than that is the issue with how iRule maintains connections with gateways, since it maintains persistent connections I assume it's opening as many connections with my devices as I have gateways. So my poor DTV box is dealing with as many open connections as I have favorite channels.

It would be great to get someone from the dev team to weigh in here, maybe there's a better way to do what I'm doing, that said, what I've set up is working, it's just a lot of effort to maintain.
1 person has
this question
+1
Reply
  • Thanks to some guys on AVS I have a partial workaround for this but it's unfortunately only partial given the way that DTV's SHEF API orders things in their response... Is no one else doing this? It's real nice to have your favorite channels page list what's on for each channel, so you can glance at the iRule screen quickly and see what to watch without pulling up a guide. Even more powerful for Sunday Ticket.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • Here are just some of my thoughts at first glance. Keep that in mind. I haven't looked at the code or your devices or feedbacks.

    The reason feedbacks are routed through gateways and not devices is because of the other gateways, serial and TCP / IP. When a persistent connection is required, which is required for Serial and TCP / IP connections, how would we know which feedback is supposed to parse the data? Think about a Receiver that has 2 iRule devices, one for the main zone and one for zone 2. When the feedback comes back how do we know which device to route the feedback to? It's not possible so we took a lot less restrictive approach and parse the feedback through all the device feedbacks that are attached to that gateway.

    Your case is a bit different because you have a device that sends a request and a feedback that should parse that request. For your case what your saying makes a lot of sense, and we might look at the implementation, but I don't know if we want to change things for this specific scenario. I will make sure to bring this up at our next development meeting.

    I don't have Direct TV so I can't tell you if there may be a better way to do things. Can you send me an example request to the Direct TV box for a specific channel and then send me the response, then maybe I can help you.

    I don't want to get super technical on here, but HTTP does not maintain connections, it is a connection-less protocol. You ask for information and get a response then the connection is closed. So your Direct TV is not doing anymore work because you have more gateways.

    Sorry if anything is vague or hard to understand, I struggle a bit explaining this in a few hundred words.

    Alex
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • I’m happy
    Thanks your response makes a ton of sense. The only bit that's confusing to me is why we assign feedbacks to devices vs. gateways in that case. Granted there is no concept of a gateway in the builder, only a device so I think that's where things begin to feel a bit disjointed.

    All of this said I've come up with a work around that is functional by utilizing other known data in the feedback. It does force me to relate a query and feedback together using known data that is different than what I'm querying which I typically don't find ideal but it does work.

    Here's an example query: http://192.168.0.18:8080/tv/getProgIn...

    Which returns the following result:

    {
    "callsign": "USAHD",
    "date": "20061003",
    "duration": 3600,
    "episodeTitle": "Recall",
    "isOffAir": false,
    "isPclocked": 3,
    "isPpv": false,
    "isRecording": false,
    "isVod": false,
    "major": 242,
    "minor": 65535,
    "programId": "3423224",
    "rating": "No Rating",
    "startTime": 1356930000,
    "stationId": 3900971,
    "status": {
    "code": 200,
    "commandResult": 0,
    "msg": "OK.",
    "query": "/tv/getProgInfo?major=242"
    },
    "title": "Law & Order: Special Victims Unit"
    }


    So my query is built like this:
    tv/getProgInfo?major=242

    and my feedbacks use the following prefix:
    "callsign": "USAHD"*
    plus whatever I'm looking for, ie:
    "callsign": "USAHD"*"title": "
    or
    "callsign": "USAHD"*"startTime":

    with the suffix as dictated by the data above.

    I've actually shared out my setup for direcTV in the hopes others can use it as well.
    The device is named: DirecTV Channel Queries
    and the feedback set is named: DirecTV Channel Data

    If you guys feel like having a look

    Next I'll be bugging you about EPOCH time conversions, any guesses why? ;)

    Honestly I'm loving iRule, anything I post here is because I'm feeling like I can do so much and I'm always wanting to do more. Also I'm a little obsessive about everything being just so, you guys have made that closer to reality than anything else I've used, including Control4 and Crestron.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • I’m happy
    I meant to mention this and forgot in my diatribe. The comment I made about having to base queries off information that I'm not passing in my query is related to having to use the callsign as the prefix vs being able to pass the channel I'm sending in the query (ie: 242 in the example above).

    It's generally a practice that stresses me out as a coder. I know what I send will be consistent and reliable banking on something in the response that isn't what I've defined feels unreliable. In reality for this case it may be ok, perhaps I'm obsessing needlessly.
    • Why not use "major": 242* instead of "callsign": "USAHD"* . Relying on an extra parameter callsign would require an extra lookup for each channel.

      Using the major parameter will only require the knowledge of the station. That is the only thing I really see wrong with your current setup. It's really just a matter of style, but it would bug me to have to look up the callsign every time.

      If you are really good at math you can probably work something out for the EPOCH time, but I don't want to get into that as I haven't tried it in a very very very long time.

      Who started the whole EPOCH time thing?, lol, I always learned it as Unix Time.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned

  • perhaps I'm misinterpreting "prefix" but I take it to mean that it has to be something in the response that occurs before the data I'm after.

    in the case of "title" I can use major, in the case of "episodeTitle" I can't because "major" occurs after episode title in the response from the directv box.

    is that right? or am I over reading into how you guys are using "prefix". Also FYI in the iRule default dtv feedbacks you use "episode Title" as opposed to the correct "episodeTitle" without the space. easy to fix by the user but at some point worth checking out.

    on the epoch time front it's funny you say that. I've always known it as epoch as it's just a number of seconds since the epoch (in the case of posix/unix that's midnight Jan 1 of 1970. the math to convert isn't terribly fun to hand write as it is calendar math and has to account for leap years, leap seconds and other such BS. That said most modern languages have built in methods for converting it natively. including objective-c, java, JavaScript, etc.

    sorry if this reads weird. iPhone and get satisfaction don't appear to be friends.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned