Page 1 of 2

Schedule queue stuck?

Posted: Mon Jun 15, 2015 8:07 am
by GameGod
I am getting the "schedule queued" message, but usually the system returns the schedule data after a couple of retries. However, it seems to be stuck today.

Code: Select all

Getting listings for FYI (Pacific) [Channel 275]
Warning: Station 'FYI (Pacific) [Channel 275]' will become available from 6/15/2015 5:00:00 PM
Warning: Operation returned an error. Response: {
  "stationID": "92371",
  "code": 7100,
  "message": "The schedule you requested has been queued for generation but is not yet ready for download. Retry."
}
Known issue?

Re: Schedule queue stuck?

Posted: Mon Jun 15, 2015 9:44 am
by rkulagow
Not yet, but it is now. Let me investigate.

Re: Schedule queue stuck?

Posted: Mon Jun 15, 2015 4:34 pm
by GameGod
Any updates on this? FYI, I'm still seeing the error.

Thanks.

Re: Schedule queue stuck?

Posted: Mon Jun 15, 2015 4:54 pm
by rkulagow
Believe it or not, Schedules Direct isn't my $DAYJOB. :)

I will be looking more into this tonight. Is this the only stationID that's causing a problem?

Re: Schedule queue stuck?

Posted: Mon Jun 15, 2015 4:55 pm
by rkulagow
Which API are you accessing; 20140530 or 20141201?

Re: Schedule queue stuck?

Posted: Tue Jun 16, 2015 6:37 am
by GameGod
20141201 and I don't know if this issue is only with this station id, since my app gives up when it encounters such an error.

I disabled that channel to see if the grab would complete, but ran into the same issue on another channel.

Code: Select all

Getting listings for Bravo HD (Pacific) [Channel 733]
Warning: Operation returned an error. Response: {
  "stationID": "73994",
  "code": 7100,
  "message": "The schedule you requested has been queued for generation but is not yet ready for download. Retry."
}
Thanks.

Re: Schedule queue stuck?

Posted: Tue Jun 16, 2015 8:04 am
by GameGod
It went further, but now am getting a different error that I've never seen before:

Code: Select all

Warning: Operation returned an error. Response: {
  "stationID": "57439",
  "code": 7020,
  "message": "Date requested (2015-06-29) not within 2015-06-16 -> 2015-06-28 for stationID 57439."
}
The date range used was 6/16 -> 7/1.

Re: Schedule queue stuck?

Posted: Tue Jun 16, 2015 8:10 am
by rkulagow
I've updated the code to sanity check the request. It looks like maybe your code isn't running the request for the MD5 hashes for a stationID first? It looks like your requests are out of range. Here's the MD5 hash response for 20141201/schedules/md5:

Code: Select all

{
    "92371": {
        "2015-06-16": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:23Z",
            "md5": "9r6Q9gEIi02YMqqk3WXFzA"
        },
        "2015-06-17": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:23Z",
            "md5": "IiycHJ7G4QrA8EVSFdPWtQ"
        },
        "2015-06-18": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:23Z",
            "md5": "G3LYJWcOtIDFfuvFgbdxFw"
        },
        "2015-06-19": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:23Z",
            "md5": "zsaopJsVlKz1xBFsAtu5eQ"
        },
        "2015-06-20": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:23Z",
            "md5": "VaIGGEN/1M6kOFgtrd/fJQ"
        },
        "2015-06-21": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "YXxA/hcnpo4fhQmxZvHosw"
        },
        "2015-06-22": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "Qk+/FJ6f8C/pSGmIZFFUdw"
        },
        "2015-06-23": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "CRTvWWVcIo979Om2GFwHuA"
        },
        "2015-06-24": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "nFl00jz7XIzHMk0FtktbIQ"
        },
        "2015-06-25": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "oUE8ng04cgxKQzddKfUa6Q"
        },
        "2015-06-26": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "zpfoC2MF9BBsVS/j3SnL+A"
        },
        "2015-06-27": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:24Z",
            "md5": "n0vvdx1cAeWqlymj/RcFTQ"
        },
        "2015-06-28": {
            "code": 0,
            "message": "OK",
            "lastModified": "2015-06-16T14:31:25Z",
            "md5": "iZGZ5wlR8kzePYH8ke9gXw"
        }
    }
}
So you can see that for this particular stationID we have data through 2015-06-28.

Here's an updated response code:

Code 7010 is hopefully one that you'll never see and would happen if something bad is going wrong on the server. Code 7020 is something that your client will need to handle:

Code: Select all

[{"stationID":"92371","code":7020,"message":"Date requested (2015-07-04) not within 2015-06-16 -> 2015-06-28 for stationID 92371."}]

Re: Schedule queue stuck?

Posted: Tue Jun 16, 2015 8:11 am
by rkulagow
I can make the response a little easier to parse programatically if that will help, like tagging "minDate" and "maxDate" instead of using the arrow.

Re: Schedule queue stuck?

Posted: Tue Jun 16, 2015 8:38 am
by GameGod
No, I don't use the MD5 for the station itself. I only cache the program info's themselves. This did not use to happen before, did something change recently?
Also, if the client requests 15 days of data, but the server has only 5, then I think it should return what it has, instead of erroring out. The client can determine that it has less data than requested, since each schedule has the time stamp.If a client wants to determine how many days of data is available for a station, it can always use the MD5 endpoint you mentioned.