

- DFIND IP ADDRES OF HOMERUN DUO MANUAL
- DFIND IP ADDRES OF HOMERUN DUO FULL
- DFIND IP ADDRES OF HOMERUN DUO CODE
- DFIND IP ADDRES OF HOMERUN DUO SERIES
Is this going to be 100% reliable? It seems hokey to extract the series ID from a URL, but I've done stranger things.Ģ. The HDHomeRun series ID for a program isn't exposed other than as part of the programme/icon element. I've had an initial run through this and am in the process of getting it hooked up to replace the JSON request, but I do have a few issues:ġ. Sorry I know I had requested combining channel numbers under a single "channel", but this method is better. The XMLTV is lighter and the amount of logic required to assemble and disassembly/identify is simpler.ĮDIT: I must add. This method, however, satisfies everyone I would think. I'm one to champion putting all the channel numbers under one station (channel) just for the sake of reducing the size of the XMLTV file. Interesting approach that I hadn't thought of. However, in XMLTV, the xml (sort of) represents a "station". Typically, in the real world (especially for cable), many "channels" deliver the same "station". A "channel" is a technical means of delivering a particular "station". The way I try to explain it, a "station" is a programming entity which has a schedule of programs. (*) It is complicated (and arguably the XMLTV DTD contributes to the confusion).
DFIND IP ADDRES OF HOMERUN DUO MANUAL
It is also true, that for that well known app, manual adjustments to the local EPG configuration these things really don't matter as much.Įxample (of what your service returns, multiple tuner numbers):

There is a proposal (get-lineup, implemented by just one (the more advanced) grabber at this point) that addresses the overloading of the display-name for tuner information to allow applications to better deal with that difference. Should that app do things different? Perhaps (I would say yes, but I did not get a vote). So, for example, if the same stations is broadcast on both tuner channel 2, and tuner channel 1002, one needs to create two 's with the different display names (as the app decodes the display names with the presumption that the third display-name is the tuner number for selection). In particular, at least one well known application (sort of) requires there to be two xml channel definitions, with the same (xml) attribute if "id", for channels that have different broadcast numbers because during automated setup it makes some assumptions. I note that this XMLTV output appears to fall a bit victim to the challenge of channels vs stations(*), and certain applications making assumptions regarding the differences. (*) Which likely means that I they only way I am going to get to it quickly is if I am trying to avoid working on something else I am should be working on. Is there any rate limiting (too many requests per minute, too many requests per day)? I presume there is no advantage to cache the data locally, as your service just returns everything available at each request.
DFIND IP ADDRES OF HOMERUN DUO CODE
It would seem to be fairly straightforward (but all projects look easy until the code hits the interpreter).
DFIND IP ADDRES OF HOMERUN DUO FULL
I presume you will not object, if, in my copious free time (which has about a dozen other higher priority items to accomplish just over the next three days)(*), if I choose to look at creating a full formal grabber (full wrapper) for the XMLTV project ( code at ) and submit it to that project for evaluation and possible inclusion into that project?Īt first blush, it would just involve getting the current deviceid from local devices configured for that grabber (all, or a subset), and calling your service (and then dealing with the offset / days requirement to subset the data to maintain their baseline config requirements).
