Roku Direct Publisher

[belltown]

JSON is nothing more than a notation to describe some structured data.

Just about every high-level programming language since time began, or at least since the FORTRAN days of the 50's, has some way of defining a data structure. Depending on the language, it may be called a struct, structure, dictionary, hash, associative array, etc., often using a collection of key/value pairs to describe the data. JSON provides a unified way of representing that data in a machine-independent, language-independent way. A JSON "object" is nothing more than a dictionary/struct, etc., a collection of key/value pairs, where the key is a string, and the value can be another object, or an array of values or a simple value (e.g. number, string).

Fundamentally, JSON is no different from XML. They both describe a data structure in a unified way, just using a different syntax. XML is more complicated than JSON. The official XML spec, https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf, is only 14 pages long. Many programming language specs run into the hundreds of pages in length.

JSON is much less verbose and complex than XML, yet for many applications has similar capabilities. It's become increasingly used over the past few years in computing. Many, many APIs are now specified in JSON.

Because most high-level languages support some form of struct/dictionary, etc., and because JSON is becoming so common, many languages provide some means to format a data structure into a JSON string, either natively or via third-party extensions. This relieves the developer of the need to construct a JSON string manually, so they don't need to be concerned about the placement of brackets, braces, and commas, etc.

Even outdated technology such as Classic ASP, using an outdated scripting language such as VBScript, provides a Dictionary type (key/value pairs), whose values can be other Dictionaries, or Arrays, or simple values (numbers/strings). Once you read your data from your database, you can construct such a Dictionary, then use a third-party function, such as http://www.webdevbros.net/2007/04/26/generate-json-from-asp-datatypes/ to convert this Dictionary into a JSON string without worrying about lining up brackets and braces, and getting all the commas in the right place.

[belltown]

"mitchstein" wrote:
Regarding the transport error:
I put the url directly in firefox and it "transports" properly showing up as plain text from start to finish.
I am wondering if the actual error is not being caused by a limitation of memory allocation on the server running DP?
This is my largest series of video with 422 episodes.
I will post this error to Roku support directly and see what they say. although so far all they do is quote paths to the docs, which I have gone through already and did not see this limitation defined in it (if that is the problem). They have stated to me that "this format theoretically can support an unlimited number of videos". But I never bank on theories or hypotenuses, I like tried and true facts, lol.
 

The first step in troubleshooting something like this would be to try it with fewer episodes. Does it work with 1, 2, 10, 100?

[mitchstein]

it takes it in with half the json file. But fails in a transport error when I send the full file. As I said, when I browse to the json file it comes down from my server in full without error. and when I request it with one of my other servers it parses in php with zero errors. My javascript guy says he is parsing it with no problems at all as well. Also the file was 128K before the last edit, now it is 146K so I am figuring, since it is being reported as a "transport error" there must be a 128K limit on the DP to parse a json file. If this is true, which I surely hope is not the case and it's some other simple thing, but if it is the case, then DP will not work for me, this is 420 videos, what will happen when I try to put in th 2500+ I currently have in my database and the 10,000+ just of vintage TV episodes that are rendering on my render server right now in que! I'm going to have to resolve this before continuing down this path.... I will be sending Roku tech support my error with all the details tonite. They will look at it on monday, tell me to read the docs, then I will respond that I already did and repeat the details, then they will tell me they will escalate it, I will wait at least two days (since I am waiting two business days and a weekend for the last escalation). So since I hit this roadblock, I have to get 1 more server on-line tonite, and upload the last 5 seasons of alfred hitchcock to my render server.. And move over whatever it has finished rendering and get them added to my database and website, as well as update my scripts to include series and episode numbers for the tv series stuff to make easier use of everything. I have added more fields to my database since playing with DP then I have in the last ten years combined, lol.. But it's all good, needed to be updated and keeps me on my toes..

[mitchstein]

And I thought I posted that it worked with one video, cause the example you made did work with the one video. then either you told me or I figured out where to add the second video and through trial and error I got it work with the other missing data after the episodes closing bracket series thumbnail and short description I believe is what I was missing..

[belltown]

"mitchstein" wrote:
So, it passes jsonlint...
But when I add it to the channel I get

"The feed URL(s) could not be validated.
There was a transport-level error - (Unknown ERROR)."

I've found the reason for the "transport-level error".

I gave you some bad code. I thought it adhered to the spec, but after taking another look, it turns out that "series" should be an array of objects, not a single object. I'm surprised it even worked with one video with that code.

I was thrown off initially by DP's crappy naming conventions. They just put an "s" on the end of any field name that should be an array, e.g. episode => episodes; season => seasons. Problem is that doesn't work if the word already ends in "s", unless they were to use "seriess". They really should have named them episodeList, seasonList, seriesList, etc. And of course - what a stupid error message!

Here's the updated code:

{
  "providerName": "Acme Productions",
  "lastUpdated": "2015-11-11T22:21:37+00:00",
  "language": "en",
  "series": [
    {
      "id": "1509428502952",
      "title": "The Amazing Series with Seasons!",
      "seasons": [
        {
          "seasonNumber": 1,
          "episodes": [
            {
              "id": "1509428502952",
              "title": "The Amazing First Episode Title",
              "content": {
                "dateAdded": "2015-11-11T22:21:37+00:00",
                "videos": [
                  {
                    "url": "https://example.org/cdn/videos/1509428502952",
                    "quality": "UHD",
                    "videoType": "HLS"
                  }
                ],
                "duration": 1290
              },
              "thumbnail": "https://example.org/cdn/thumbnails/1509428502952/1",
              "episodeNumber": 1,
              "releaseDate": "2015-11-11",
              "shortDescription": "Episode 1"
            },
            {
              "id": "1509428502953",
              "title": "The Amazing Second Episode Title",
              "content": {
                "dateAdded": "2015-11-11T22:21:37+00:00",
                "videos": [
                  {
                    "url": "https://example.org/cdn/videos/1509428502952",
                    "quality": "UHD",
                    "videoType": "HLS"
                  }
                ],
                "duration": 1290
              },
              "thumbnail": "https://example.org/cdn/thumbnails/1509428502952/1",
              "episodeNumber": 2,
              "releaseDate": "2015-11-11",
              "shortDescription": "Episode 2"
            },
            {
              "id": "1509428502954",
              "title": "The Amazing Third Episode Title",
              "content": {
                "dateAdded": "2015-11-11T22:21:37+00:00",
                "videos": [
                  {
                    "url": "https://example.org/cdn/videos/1509428502952",
                    "quality": "UHD",
                    "videoType": "HLS"
                  }
                ],
                "duration": 1290
              },
              "thumbnail": "https://example.org/cdn/thumbnails/1509428502952/1",
              "episodeNumber": 3,
              "releaseDate": "2015-11-11",
              "shortDescription": "Episode 3"
            }
          ]
        }
      ],
      "genres": [
        "educational",
        "science fiction",
        "thriller"
      ],
      "thumbnail": "https://example.org/cdn/thumbnails/1509428502952/1",
      "releaseDate": "2015-11-11",
      "shortDescription": "Wondrous series seasons."
    }
  ]
}

Good luck. Hope it gets you over the next hurdle.

[mitchstein]

"belltown" wrote:
JSON is nothing more than a notation to describe some structured data.

Just about every high-level programming language since time began, or at least since the FORTRAN days of the 50's, has some way of defining a data structure. Depending on the language, it may be called a struct, structure, dictionary, hash, associative array, etc., often using a collection of key/value pairs to describe the data. JSON provides a unified way of representing that data in a machine-independent, language-independent way. A JSON "object" is nothing more than a dictionary/struct, etc., a collection of key/value pairs, where the key is a string, and the value can be another object, or an array of values or a simple value (e.g. number, string).

Fundamentally, JSON is no different from XML. They both describe a data structure in a unified way, just using a different syntax. XML is more complicated than JSON. The official XML spec, https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf, is only 14 pages long. Many programming language specs run into the hundreds of pages in length.

JSON is much less verbose and complex than XML, yet for many applications has similar capabilities. It's become increasingly used over the past few years in computing. Many, many APIs are now specified in JSON.

Because most high-level languages support some form of struct/dictionary, etc., and because JSON is becoming so common, many languages provide some means to format a data structure into a JSON string, either natively or via third-party extensions. This relieves the developer of the need to construct a JSON string manually, so they don't need to be concerned about the placement of brackets, braces, and commas, etc.

Even outdated technology such as Classic ASP, using an outdated scripting language such as VBScript, provides a Dictionary type (key/value pairs), whose values can be other Dictionaries, or Arrays, or simple values (numbers/strings). Once you read your data from your database, you can construct such a Dictionary, then use a third-party function, such as http://www.webdevbros.net/2007/04/26/generate-json-from-asp-datatypes/ to convert this Dictionary into a JSON string without worrying about lining up brackets and braces, and getting all the commas in the right place.

actually, I've found that json and xml aren othing more then text files. The only benefit of xml and json over the good ole comma delimited text file is the ability to define variables instead of places(colums). In addition... you can use the get and put feature of forms processing from any language since Vbasic 1.0 to do exactly the samething that json and xml do, with much more simplicity, since you structure the variables with a value directly with nothing more then an = sign to seperate the two and a questionmark to serperate the pairs..
Basically all these brackets and curleys really are not neccessary, thier purpose is nothing more then to make a standard seperate from what was already accepted. Matter of fact the only thing that makes json to programmers today more preferrable the any other is the built in parsing.. If you were to program it using a language like vbasic in classic asp (not .net cause that has parsing roiutines built in) you would actually open the json file as a text file and split it then manually parse it. I've done that for the last 35+ years.. It took a simple procedure and added a little value and whole lot of uneccessary complexity. it would be easier to say seriesepisode = 1  then it is to say {"series"[ "episode" : 1]} they both do exactly the samething but the oldway required alot less format and kept it simple. In engineering we have a strict rule K.I.S.S. (Keep It Simple Stupid). That was set as a standard long before my time and for good reason... Shamefully this generation is ignoring it..