DRAFT: Delta between API 20140530 and 20141201

rkulagow
SD Staff
Posts: 915
Joined: Tue Aug 14, 2007 3:15 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by rkulagow » Tue Mar 31, 2015 10:22 am

I'm flexible, but at this point the entire satellite thing seems to be something which has a very, very low adoption rate. :(

Basically, if you're the only one, then by default you'll be the loudest!

What would you like it to be?

rkulagow
SD Staff
Posts: 915
Joined: Tue Aug 14, 2007 3:15 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by rkulagow » Tue Mar 31, 2015 6:14 pm

"subType" in a program is now deprecated - it was a duplicate of "showType" and will be removed from the data effective immediately. showType values are:
  • Feature Film
    Short Film
    TV Movie
    Miniseries
    Series
    Special
    Sports event
    Sports non-event
    Paid Programming
    Theatre Event
New program elements:

"audience" - (Work-in-progress) if the element is included, it will be a string containing the intended audience. Possible values are
  • Children
"holiday" - (Work-in-progress) if the element is included, it will be a free-form string containing the holiday associated with the program.

"animation" - (Work-in-progress) if the element is included, it will be a string containing the following:
  • Animated
    Anime
    Live action/animated
    Live action/anime

rkulagow
SD Staff
Posts: 915
Joined: Tue Aug 14, 2007 3:15 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by rkulagow » Thu Apr 02, 2015 7:48 am

When requesting the lineups in a postal code, the response will now explicitly indicate the lineup rather than requiring the client to parse it from the uri.

Code: Select all

{
        "headend": "CA67310",
        "transport": "Cable",
        "location": "Eagle Rock",
        "lineups": [
            {
                "name": "Time Warner Cable City of Los Angeles - Cable",
                "lineup": "USA-CA67310-DEFAULT",
                "uri": "/20141201/lineups/USA-CA67310-DEFAULT"
            },
            {
                "name": "Time Warner Cable City of Los Angeles - Digital",
                "lineup": "USA-CA67310-X",
                "uri": "/20141201/lineups/USA-CA67310-X"
            }
        ]
    }

gtb
Posts: 88
Joined: Thu Oct 02, 2014 2:07 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by gtb » Thu Apr 02, 2015 2:58 pm

rkulagow wrote:I'm flexible, but at this point the entire satellite thing seems to be something which has a very, very low adoption rate. :(

Basically, if you're the only one, then by default you'll be the loudest!

What would you like it to be?
To be honest, I highly doubt I will be using satellite stuff, nor would anyone who happens to think the code I am writing is useful and ends up running it will. I just tend to walk to the edge just to see what I can see. Let someone who actually uses Freesat/FTA services (mostly in the non-US market (I am in the US market)) have the most votes.

I, too, am still trying to get a handle on possibilities, and was thinking about prompting a user to select the region first (before asking them to select from a now smaller country list in that region) made a bit of sense. But maybe not. My thinking is still a bit of a work in progress, and since managing lineups is something most people will do only a few times in their lifetimes (other than testing, of course), I am still not sure the best way to present it.

That background now complete, I believe the region name should be more meaningful (since there is currently no description regarding the region), and while I believe I can remember what a "North America" is (well, geography class is a long long time ago, but still...), but "ZZZ" is not a region that was ever taught to me, so I would prefer something to prompt the user with that is meaningful to them. I am not a sales/marketing person, so I do not know how to spin the name, but something with a "Satellite" in the name makes sense to me.

I believe there is some ITU nomenclature that says these are all BSS (Broadcast Satellite Services), with DBS (DIrect Broadcast Satellite) and DTH (Direct To Home) being related/subsets/supersets, but the ITU tends to categorize things by frequency, so I tend to get confused as to which is which is which.

But, back to the start, since *I* will likely never use it, I am also happy to just see things stay the same (region named ZZZ). It can always change in a future API if there are strong opinions.

rkulagow
SD Staff
Posts: 915
Joined: Tue Aug 14, 2007 3:15 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by rkulagow » Thu Apr 02, 2015 3:30 pm

I already track "zones" on the server side based on longitude, but some satellites are fuzzy because they could potentially be seen in multiple regions.

I could emulate what Lyngsat has; I think they have 5 or 6 categories.

Since I have the two big satellites in Europe; 19.2E and 28.2E, I'm hoping that I can get some adoption and then guidance from those users on what works for them. At this point it's all black box, so difficult to do anything with.

gtb
Posts: 88
Joined: Thu Oct 02, 2014 2:07 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by gtb » Thu Apr 02, 2015 4:08 pm

rkulagow wrote:A new call is now available.
.....
GET /available/countries

Token: Not required.

Currently returns:

Code: Select all

{
    "North America": [
        {
            "fullName": "United States",
            "shortName": "USA",
            "postalCodeExample": "12345",
            "postalCode": "/\\d{5}/"
        },
        {
            "fullName": "Canada",
            "shortName": "CAN",
            "postalCodeExample": "K1A0B1",
            "postalCode": "/[A-Z]{1}[\\d]{1}[A-Z]{1}[\\d]{1}[A-Z]{1}[\\d]{1}/gm"
        }
    ],

}
(Code truncated for brevity).

The regex for canada seems a bit, um, unusual, in that it is specifying a multiline global match? This seems a bit strange to me. Should the regex modifiers exist?

rkulagow
SD Staff
Posts: 915
Joined: Tue Aug 14, 2007 3:15 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by rkulagow » Thu Apr 02, 2015 4:16 pm

I didn't have time to test the regex in my own client code yet, so there may be some issues with the fancier ones. I think I found the Canadian one online and forgot to look at the tail end modifiers.

If you have a regex that works for Canada please post it.

gtb
Posts: 88
Joined: Thu Oct 02, 2014 2:07 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by gtb » Thu Apr 02, 2015 4:53 pm

There appears to be a slight inconsistency between the transport types that are returned for a individuals current lineup (transport = Antenna) and in a headend lookup for a country/postal (transport = Over-the-Air) for the same lineup for OTA lineups.

Similarly, the name returned for (at least a sample) individuals lineup (name = "Local Over the Air Broadcast") and the headend lookup (name = "Antenna") are different.

It sort of feels like there is a bit of conflating of terms here, and I would prefer to see some consistency between the results (so that the user gets a consistent name/transport).

I can easily argue that the transport should be consistently set to "Antenna", and the name should be consistently set to "Local Over The Air Broadcast", but I am certainly willing to accept your wisdom.

(There may be other inconsistencies, but I have hit my limit of add/delete for the day, so I cannot check for the satellite or cable transports today; maybe tomorrow, if I have time).

I can get specific examples if you wish, but your API documentation shows it clearly.

Thanks for considering this request (I think it is more of a Feature request; it is certainly not a bug since there is no assurance that the transport/names have any specific meaning).

gtb
Posts: 88
Joined: Thu Oct 02, 2014 2:07 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by gtb » Thu Apr 02, 2015 6:03 pm

rkulagow wrote:I didn't have time to test the regex in my own client code yet, so there may be some issues with the fancier ones. I think I found the Canadian one online and forgot to look at the tail end modifiers.

If you have a regex that works for Canada please post it.
Here is the one I believe is correct based on the current definitions (there are some characters not valid). Technically, the CA postal code can be written as 'K1A0C9' or 'K1A 0C9', but I understand that what matters is how it is formatted in the SD database.

/[ABCEGHJKLMNPRSTVXY]\d[ABCEGHJKLMNPRSTVWXYZ]\d[ABCEGHJKLMNPRSTVWXYZ]\d/

No modifiers.

Technically, depending on the language implementation, the regex really should usually have start/end anchors /^<whatever>$/ to insure it is a complete string match.

I could also argue that the '/'s are not part of the actual regex, and should not be returned (if your language requires them for the match, add them yourself). The regex for a US zipcode should be simply "^\d{5}$". But this is a nit.

No, I am not about to volunteer to check the other regexs, I just noticed the Canadian one since I tested (or tried to test) with it in my code, ran into a issue with my code, and then looked more carefully at what was presented to me.

Thanks for checking (yes, I know I can be a PITA).

gtb
Posts: 88
Joined: Thu Oct 02, 2014 2:07 pm

Re: DRAFT: Delta between API 20140530 and 20141201

Post by gtb » Thu Apr 02, 2015 6:15 pm

Bug accessing Canadian postal code H0H0H0.

It appears Santa Claus is not able to receive guide data from SD. When asking for the headends for postal code H0H0H0 in Canada one receives a response code 500, with the following content:

Code: Select all

<html><head><title>Slim Application Error</title><style>body{margin:0;padding:30px;font:12px/1.5 Helvetica,Arial,Verdana,sans-serif;}h1{margin:0;font-size:48px;font-weight:normal;line-height:48px;}strong{display:inline-block;width:65px;}</style></head><body><h1>Slim Application Error</h1><p>The application could not run because of the following error:</p><h2>Details</h2><div><strong>Type:</strong> ErrorException</div><div><strong>Code:</strong> 2</div><div><strong>Message:</strong> Invalid argument supplied for foreach()</div><div><strong>File:</strong> /var/www/html/functions/func.20141201.php</div><div><strong>Line:</strong> 390</div><h2>Trace</h2><pre><div>#0 /var/www/html/functions/func.20141201.php(390): Slim\\Slim::handleErrors(2, \'Invalid argumen...\', \'/var/www/html/f...\', 390, Array)</div><div>#1 /var/www/html/index.php(242): getHeadendsForPostalCode(\'CAN\', \'H0H0H0\', \'1417\')</div><div>#2 [internal function]: {closure}()</div><div>#3 /var/www/html/vendor/slim/slim/Slim/Route.php(468): call_user_func_array(Object(Closure), Array)</div><div>#4 /var/www/html/vendor/slim/slim/Slim/Slim.php(1338): Slim\\Route->dispatch()</div><div>#5 /var/www/html/vendor/slim/slim/Slim/Middleware/Flash.php(85): Slim\\Slim->call()</div><div>#6 /var/www/html/vendor/slim/slim/Slim/Middleware/MethodOverride.php(92): Slim\\Middleware\\Flash->call()</div><div>#7 /var/www/html/vendor/slim/slim/Slim/Middleware/PrettyExceptions.php(67): Slim\\Middleware\\MethodOverride->call()</div><div>#8 /var/www/html/vendor/slim/slim/Slim/Slim.php(1283): Slim\\Middleware\\PrettyExceptions->call()</div><div>#9 /var/www/html/index.php(920): Slim\\Slim->run()</div><div>#10 {main}</pre></body></html>
The Clause house WAF is going down......

Yes, I know this has a really really really low priority (but you have been added to the naughty list).

Post Reply