Notice: JSON service migration from PHP to Python

[rkulagow]

Schedules Direct will be migrating our API20141201 backend service from PHP to Python starting on 2022-05-20. This is not a migration to API20191021, which is still under development.

----------------------------

Status:
2022-05-21T03:00Z - migration started.
2022-05-21T04:55Z - migration ended.
2022-05-21T22:00Z - caching logic updated to reduce number of database requests; the database server is running out of connections, so some invocations are failing and returning "Internal Server Error".
2022-05-22T02:00Z - migration to larger database servers started. Under load, the database server which had been working in the test environment is not able to maintain throughput, so the process to move the data to a new server has begun. Until the new server is online, users may continue to experience issues in retrieving a token; if possible, increase the timeout for token retrieval to 29 seconds. The logs are indicating that the token response is taking in excess of 4 seconds due to the code not being able to obtain a database handle on first attempt.
2022-05-22T02:45Z - to complete the migration of data to new servers, the service will be placed into Offline mode.
2022-05-22T05:40Z - migration of data is continuing. Indexes are being rebuilt.
2022-05-22T14:39Z - indexes rebuilt. Data ingest started to catch up to data which was refreshed upstream but which was not processed due to database overload.
2022-05-22T15:10Z - precaching of user lineups and stationsIDs into Redis. This is normally performed just-in-time from the database, but the influx of users when the service is put back online will cause database load.
2022-05-22T16:07Z - AWS Database Migration Service mis-identified primary and unique keys and did not transfer all data from source database to destination. Analyzing which tables are affected.
2022-05-22T19:02Z - Tables which were improperly migrated and the relevant data has been rebuilt.
2022-05-22T21:00Z - Service was re-enabled.
2022-05-22T21:35Z - Lambda concurrency limit reached; request made to increase concurrent execution limits.
2022-05-22T22:54Z - Increased max_allowed_packet.
2022-05-22T23:30Z - Reduced concurrency limit for a particular endpoint to make invocations available to issue_token and mainline endpoints.
2022-05-23T04:00Z - Service is being migrated back to existing PHP API until root cause of failure to obtain read handle against database can be determined. Python backend placed into offline mode.
2022-05-23T04:20Z - PHP API updating per normal daily update; when PHP service has 'caught up' to 3 days of non-updates, it will be placed back into service.
2022-05-23T06:53Z - Existing servers placed back into service.

----------------------------

What should you expect?

• The Python provided API has been created to be protocol compatible, so it's likely that you won't need to do anything if your grabber has implemented the published API.
• The new service is provided by AWS API Gateway, so the issues you may have experienced if you were updating your schedule at your local midnight time should now be addressed.
• The methods used to generate data on our backend servers have been updated, and there are a number of fields in the new JSON which will cause the MD5 values to change, so your application will refresh its local data. This is known as a cache invalidation - expect that there will be a large amount of data downloaded.

What changes will you see?

• The schedules on the backend will be refreshed more often; we have migrated to a new data delivery mechanism from our upstream provider.
• You should see 14 to 18 days of schedule data.
• Images will be updated more often.
• Lineup updates will be occur more often.
• Schedules Direct will send lineup deletion notifications to your registered email address 30 days before a lineup is deleted, in order to give you time to migrate. Lineups are deleted by upstream providers if they're consolidating headends, or ending an offering - this typically occurs if a provider is migrating from analog (usually, the -DEFAULT lineup) to digital-only (-X)

What should you do if you have issues after the migration?

• Check to see if you're running the latest version of your application / grabber. Developers were provided early access to the new delivery mechanism, and a number of issues were resolved.
• Check the support forum for your application and engage the developer; they'll be the ones that can help you troubleshoot the application and the migration.
• If you're still stuck, your developer will tell you to open a ticket with Schedules Direct. Please open a lineup support ticket on the SchedulesDirect webpage https://www.schedulesdirect.org/lineupsupport and indicate that you're having an issue, and that the developer of your application has directed you to open a ticket.

[skst]

This sounds like a great upgrade. Is there anything developers will need to change in our applications as a result of this change? Can we assume this has nothing to do with the 20191022 version of the API?

Developers were provided early access to the new API

May I ask when and how were developers notified? I can't find anything in the forum about it, and I never received an email. Is there something I need to do to sign up for such notifications?

[rkulagow]

I have updated the initial post to clarify that this is API20141201 PHP -> API20141201 Python migration

The developers of the applications with the highest number of daily downloads/registered user count were contacted directly. If you would like access to the beta API which will be going live shortly, then please send me a message and I will send you the URL endpoint.

[gtb]

The developers of the applications with the highest number of daily downloads/registered user count were contacted directly.

As one of those developers contacted, let me say that Robert was extremely helpful and expeditiously resolved issues I encountered. In the end, as is the stated intent, I needed to make no changes to my application(*). I have no doubt that there will be point specific issues as some applications and users do the most interesting things, but I have seen nothing in my application that suggests most are going to even notice if this announcement post had not been made.



(*) Although I did identify certain improvements I could make in the application in future updates, none of them are directly related to the SD JSON backend service changes, just general things when you look at old code and realize it can be improved.

[Mimir]

Please can you tell me if there has been a change to the protocols/ciphers accepted, since the move to AWS.

My access to the endpoint has now started failing with:

Code: Select all

Can't connect to json.schedulesdirect.org:443
LWP::Protocol::https::Socket: SSL connect attempt failed with unknown errorerror:00000000:lib(0):func(0):reason(0) at /usr/local/share/perl/5.10.1/LWP/Protocol/http.pm line 47.

(Which suggests to me that a cipher which was accepted yesterday is no longer accepted today.)

[bHDTV]

I've tried downloading about 15 times in the past two hours 2022-05-21 00:10 - 02:34 and none have been successful via EPG123 (older version 1.7.0.10) on Windows 7. Error in every case has been:

[ INFO] SD API WebException Thrown, Message: The underlying connection was closed: An unexpected error occurred on a send. , Status: SendFailure
[ INFO] Failed to completed request. Exiting
[ ERROR] Did not receive a response from Schedules Direct. message: Did not receive a response from Schedules Direct for a token request.

[gtb]

My access to the endpoint has now started failing with: .....

If you were accessing the service endpoint during the period of the migration (the time-frames are noted in the announcement text) one may have encountered a number of different errors (mostly you should have gotten service unavailable errors, but I did see something a bit unusual at a couple of points in the middle of the migration).

You did not mention the application you are using. If you are still experiencing issues now that the migration is complete you should probably first contact the application developer. I will note that perl 5.10 has been EOL for around ten years at this point, although some OS distributors may have been backporting fixes for a longer period of time, and it is possible you may need to upgrade your OS or application to something more recent.

[emveepee]

Please can you tell me if there has been a change to the protocols/ciphers accepted, since the move to AWS.

I am wondering about a similar issue, since I have a test Vista install and it fails today with

2022-05-21 06:48:22.913 [ERROR][11] Unexpected error doing Schedules Direct login: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

Is there a minimum TLS version now? I think Vista was just to 1.0

Martin

[GameGod]

I'm seeing failures for all channels in my lineup on the schedules/md5 endpoint.

For Example - KRON [Channel 4]:
JSON object sent

Code: Select all

[
  {
    "stationID": 10672
  }
]

Returns:

Code: Select all

{}

This was working yesterday.

[skst]

Oddly, Typecast is working this morning, but I can't get a token with Postman.

Code: Select all

"code": 4003,
"response": "INVALID_USER",
"message": "Invalid username or token has expired.",

The available services request works though: https://json.schedulesdirect.org/20141201/available

Code: Select all

[
    {
        "type": "COUNTRIES",
        "description": "List of countries which are available.",
        "uri": "/20141201/available/countries"
    },
    {
        "type": "LANGUAGES",
        "description": "List of language digraphs and their language names.",
        "uri": "/20141201/available/languages"
    },
    {
        "type": "DVB-T",
        "description": "List of Freeview transmitters in a country. Country options: GBR",
        "uri": "/20141201/available/transmitters/{ISO 3166-1 alpha-3}"
    }
]