Roku Developer Program

[mitchstein]

I'm starting this out with a bit of criticism. However, it's intent is to either learn why, make people aware for positive change, and or help a few others out with what I percieve as issues.

Direct publisher seems to have a limitation of 40 videos per category, with a category limitation of 15. meaning a limitation of 600 unique videos can be published on a direct publisher channel.

Is this correct? If it is, will this remain a limitation or is development underway to fix this "issue/limitation". If not, why won't more then 40 videos per category display?

Currently I am trying to add a few ITV series we have filmed/produced over the last ten years, Friday Night Madness for instace has over 40 episodes per season and 10 seasons. Top Rope TV is in it's 6th season with over 50 episodes per season. seems each will need it's own channel and maybe 2 channels for each going forward. Vintage TV shows we have and will be adding in the next six months will require about ten or more channels for the enitre library and then the vintage movies will require about 5 channels..

Anyway, other things developers of direct publisher might wanna know:

1) 15 categories, 40 shows per category 600 unique videos maximum per channel.
2) Direct player can not handle quotations in the video name or descriptions.
3) most ascii control characters have to be eliminated from the video names and descriptions
4) HTML codes are treated as TEXT, meaning if you want to bold a word in your description your end users will see <B>text</B> and will not see the text in bold.
5) updates via the direct publisher website, such as category changes and/or uploading new xml files do not seem to appear on the endusers device until it gets updated.
6) Saving your login credentials to the developers dashboard in firefox, microsoft edge and google chrome does not work on windows 10 or server 2008. But works great on good ole IE.

If any of my information is wrong, please let me know, and maybe contribute on how to fix it on my end, I'm a pretty adept developer on many platforms if I'm missing something chances are so are others and it should help many out. If you find other things, feel free to post it in this thread (unless it violates roku guidelines) If I can help you out I will.

Also if anyone happens to be using classic asp I wrote some routines that will pull from an SQL/Access database and form the json files correctly (or at the very leats functionally). I'm willing to share them. YES, CLASSIC ASP 2.0 what can I say, I'm old and like old things.. I used to be young, when noone else knew asp and I did.. seems I've come full circle lol!!

[belltown]

"mitchstein" wrote:
1) 15 categories, 40 shows per category 600 unique videos maximum per channel.

It seems unnecessary for Roku to have such a limitation unless their software is not optimized to handle more data. Hopefully, in a future release they'll increase the limits to align with what users such as yourself need for your real-world channels.

2) Direct player can not handle quotations in the video name or descriptions.

It can. In JSON you can input a quote character in a string by preceding it with a backslash character.

3) most ascii control characters have to be eliminated from the video names and descriptions

Why would you have "control characters", which by definition are not human-readable characters, in a name or description?

4) HTML codes are treated as TEXT, meaning if you want to bold a word in your description your end users will see <B>text</B> and will not see the text in bold.

That's to be expected. You're not displaying the feed in a web browser, so I wouldn't expect HTML tags to be parsed. There are some cases in the legacy SDK where you can enter a limited set of HTML tags, which get handled appropriately. However, in general the Roku SDKs do not do much in the way of HTML parsing.

5) updates via the direct publisher website, such as category changes and/or uploading new xml files do not seem to appear on the endusers device until it gets updated.

Possibly, the way the DP channel code is implemented, the feed url changes with each update the developer makes through the developer dashboard. That would explain why the users' channels have to be updated to get the new feed. I'm not sure why they wouldn't want to use a fixed url for the channel so that the channel has access to the new data as soon as the developer updates are made.

6) Saving your login credentials to the developers dashboard in firefox, microsoft edge and google chrome does not work on windows 10 or server 2008. But works great on good ole IE.

The Roku developer web portal sucks. There have been many threads discussing its inadequacies.

[37mediagroup]

"belltown" wrote:

5) updates via the direct publisher website, such as category changes and/or uploading new xml files do not seem to appear on the endusers device until it gets updated.

Possibly, the way the DP channel code is implemented, the feed url changes with each update the developer makes through the developer dashboard. That would explain why the users' channels have to be updated to get the new feed. I'm not sure why they wouldn't want to use a fixed url for the channel so that the channel has access to the new data as soon as the developer updates are made.

Hmmmm, just curious, do the DP channels ever auto update, or only when the customer manually update their settings & device?  Honestly I was just using a changing url thru myjson  I have a wordpress website and I couldn't add on a 'json only' page to it, but I should be able to using a subdomain I suppose.

[belltown]

"Pasnow" wrote:

"belltown" wrote:

5) updates via the direct publisher website, such as category changes and/or uploading new xml files do not seem to appear on the endusers device until it gets updated.

Possibly, the way the DP channel code is implemented, the feed url changes with each update the developer makes through the developer dashboard. That would explain why the users' channels have to be updated to get the new feed. I'm not sure why they wouldn't want to use a fixed url for the channel so that the channel has access to the new data as soon as the developer updates are made.

Hmmmm, just curious, do the DP channels ever auto update, or only when the customer manually update their settings & device?  Honestly I was just using a changing url thru myjson  I have a wordpress website and I couldn't add on a 'json only' page to it, but I should be able to using a subdomain I suppose.

My guess is that whenever the Roku is updated (EITHER by the user doing a manual update from the Roku Settings>System>System update menu OR automatically, which usually seems to happen daily), then the DP channel will be updated to the latest feed url, if necessary. Channels can't update by themselves; they're only updated when the Roku device is updated. And then they are all checked for any Channel Store updates.

I don't see how that has anything to do with you using a changing myjson url or a Wordpress file, however. If what mitchstein said is accurate, it should make no difference when/how your JSON feed is hosted and how or how often you update it, since the update won't appear on the user's Roku until their Roku undergoes a system update.

[mitchstein]

"belltown" wrote:

2) Direct player can not handle quotations in the video name or descriptions.

It can. In JSON you can input a quote character in a string by preceding it with a backslash character.
Thats good to know so I can code my script instead of replaing " with nothing to replace it with /" and that will work well.

3) most ascii control characters have to be eliminated from the video names and descriptions

Why would you have "control characters", which by definition are not human-readable characters, in a name or description?
Chr$(13) and chr$(10) are in alot of my older videos left over relics from when we streamed video on the old school BBS and very early web server. We converted most of them to <br> and <p></p> back in 1998, when we closed the BBS and went soley as a website. But now with multi platforms pulling from the same old d-base we found all of them. There also where chr$(7) which not many would understand today, but it made a nice ringing sound (ding) when it was viewed.. There is no html equivalent that I know of and it was just ignored by the webserver/browsers and the xml didn't crash in the sample roku player on the private channel, but it does crash the json checker. Not a biggy, just something that would be nice to know going in instead of having to figure out on your own, especially since we are supposed to read the manuals and instructions before playing.

4) HTML codes are treated as TEXT, meaning if you want to bold a word in your description your end users will see <B>text</B> and will not see the text in bold.

That's to be expected. You're not displaying the feed in a web browser, so I wouldn't expect HTML tags to be parsed. There are some cases in the legacy SDK where you can enter a limited set of HTML tags, which get handled appropriately. However, in general the Roku SDKs do not do much in the way of HTML parsing.
Again that is something that should be TOLD during the setup instructions. A simple sentence, such as "Plain text is only acceptable in the descriptions and file names". BUT it would be nice if some control codes were recognized, like bold, or even font color changes and then instructions on how to implement them. Anyway, it's not a big issue and an easy filter takes them out. Just need to know..

5) updates via the direct publisher website, such as category changes and/or uploading new xml files do not seem to appear on the endusers device until it gets updated.

Possibly, the way the DP channel code is implemented, the feed url changes with each update the developer makes through the developer dashboard. That would explain why the users' channels have to be updated to get the new feed. I'm not sure why they wouldn't want to use a fixed url for the channel so that the channel has access to the new data as soon as the developer updates are made.

That is the way it was with the sample player, when a user loaded your channel they loaded the xml files directly from your own server, it seems now the json file is either loaded from the roku server and/or added to the code in the player. I really like the way the sample player did things, we have used that way to develop alot of programs for other people/businesses.

6) Saving your login credentials to the developers dashboard in firefox, microsoft edge and google chrome does not work on windows 10 or server 2008. But works great on good ole IE.

The Roku developer web portal sucks. There have been many threads discussing its inadequacies.
Well I wouldn't say sucks, but definitely could be better,, For instance a direct link to the direct publisher area instead of haing to go through the sdk developer link and then select direct publishing. Maybe I'm wrong, but I think this direct publisher can be HUGE for Roku, no other box has this way of doing it, and it really is easy. And the fact that Roku has maintained backwards compatibility all the way back to the Roku 1 is amazing. It means we can develop today and still use 5 maybe 10 years from now. "Set it and forget it" a developers dream, lol..

[mitchstein]

I have not master the quote and reply method used here yet, so that may be a bit hard to follow.. I'll work on that next time lol..

[belltown]

"mitchstein" wrote:

2) Direct player can not handle quotations in the video name or descriptions.

"belltown" wrote:
It can. In JSON you can input a quote character in a string by preceding it with a backslash character.

"mitchstein" wrote:
Thats good to know so I can code my script instead of replaing " with nothing to replace it with /" and that will work well.

Not quite. That's a forward slash, you need to escape the quote with a backslash: \"

Re control characters, html, etc: A lot of BrightScript code I've seen in other channels and examples contains code to strip out the html tags, etc., so that's probably why your xml feed-based BrightScript channel didn't care about such tags; it just ignored them. Obviously, Direct Publisher takes a more stringent approach. I wouldn't think it would be too hard to write some kind of script (Python?) to go through all your feed files stripping out html tags and control characters -- although, of course, it would be easier if DP provided that capability on their side (along with line numbers on error messages, etc.)

Direct Publisher seems to be designed for non-technical, non-developer people to get a Roku channel up and running quickly without having to learn programming or any of the other skills typically required of a developer (debugging, etc.) As such, it provides a simple set of features suitable to get a simple channel working with many inherent limitations. If you find yourself stretching the capabilities of what DP can handle and you need more (unlimited categories, unlimited content items, real-time feed updates from your own server, custom text formatting, ingestion of existing XML feeds, etc, etc), then that is what the Scene Graph API is for.

There is a much steeper learning curve for the Scene Graph API than with Direct Publisher. However, with your previous programming experience, experience developing other Roku channels, along with the many tutorials and examples provided by Roku, it shouldn't be insurmountable. It might be something you'd want to take a look at for the long-term after you've got your DP stuff figured out. You could get started with something like this example: https://github.com/rokudev/videoplayer-channel

[belltown]

"mitchstein" wrote:
I have not master the quote and reply method used here yet, so that may be a bit hard to follow.. I'll work on that next time lol..

When you're entering a reply, on the toolbar, just above where you enter the message text, the leftmost icon (left of the bold/italic/underline, etc) that looks like 3 horizontal white lines on a black background, allows you to enter markup directly. I find that a lot easier to use for quoting, entering links, etc. than trying to use the graphical interface, which often seems to make stuff into quotes when you think you're done quoting, or make the text after a link part of the link.

[mitchstein]

"belltown" wrote:


Not quite. That's a forward slash, you need to escape the quote with a backslash: \"

Re control characters, html, etc: A lot of BrightScript code I've seen in other channels and examples contains code to strip out the html tags, etc., so that's probably why your xml feed-based BrightScript channel didn't care about such tags; it just ignored them. Obviously, Direct Publisher takes a more stringent approach. I wouldn't think it would be too hard to write some kind of script (Python?) to go through all your feed files stripping out html tags and control characters -- although, of course, it would be easier if DP provided that capability on their side (along with line numbers on error messages, etc.)

Direct Publisher seems to be designed for non-technical, non-developer people to get a Roku channel up and running quickly without having to learn programming or any of the other skills typically required of a developer (debugging, etc.) As such, it provides a simple set of features suitable to get a simple channel working with many inherent limitations. If you find yourself stretching the capabilities of what DP can handle and you need more (unlimited categories, unlimited content items, real-time feed updates from your own server, custom text formatting, ingestion of existing XML feeds, etc, etc), then that is what the Scene Graph API is for.

There is a much steeper learning curve for the Scene Graph API than with Direct Publisher. However, with your previous programming experience, experience developing other Roku channels, along with the many tutorials and examples provided by Roku, it shouldn't be insurmountable. It might be something you'd want to take a look at for the long-term after you've got your DP stuff figured out. You could get started with something like this example: https://github.com/rokudev/videoplayer-channel

Well absolutely the ideal situation would be to learn the brightscript from top to bottom and become an expert brightscript code programmer, BUT, seeing that Roku is one platform, the only one I know of using brightscript, it would not be an efficient use of time. And I already have several private channels running on the sample player from github. The thing that attracted me to the direct player is that with little effort we get a built in adserver directly from Roku. I've already spent a few hours trying to learn enough brightscript to add that to the sample player, basically, not happening and extremely frustrating. You see the nicest thing about Python, asp, asp.net, java, etc etc is that there are MILLIONS of developers worldwide, with tons of support, Brightscript has like 2 developers outside of the roku platform (ok maybe a bit of sarcasm there it really more like 5), and there is so little support for it. The instructions and nothing more then guides with poor examples. I like to jump into a language, search google for what I want it to do, find a few peoples examples of what works and doesn't work, edit it to my needs and backwards engineer it. Alot easier in reverse then forwards. For me anyway. Besides with the new direct publisher, if Roku wants to make a platform obsolete it's no skin off my back, they say in the documentation that they will update the player leaving one less thing for me to worry about. Like when they depreciate the current brightscript code in 2020 and all my private channels go down. It's easier for me to have 25 public channels that Roku does the maintanance on then 5 private ones. lol.

Actually in the private channels it recognized <br> <b> <font> and <p> and used them appropriately if I remember correctly. I almost positive thats how we changed the color of the fonts on some of the descriptions.. Anyway, I wasn't complaining that it should use them, I was informing people that it doesn't if they have a similar situation.
I sincerely doubt a non-technical non-developer type person would be able to figure out how to construct a json file, after all, all a json file is - is a standardized formatting of a text file that gives instruction to a program or in technical terms a "script". I could not see my lawyer or doctor writing a json file anymore then they would be writing a  javascript file. However, they would not have to write a brightscript file so it's a few big steps less. Really though I see no reason why the videos couldn't be submitted via a form on the roku webpage or in a simpler format. As a matter of fact I showed this to my financial adviser today {"providerName":"TVByDemand Productions","lastUpdated":"2017-03-10T12:22:36+00:00","language":"en","movies":[{"id":"1","title":"24/7 Full Streaming","content":{"dateAdded":"2015-11-11T22:21:37+00:00","videos":[{"url":"http://www.tvbydemand.com/live/hls/ulive1/mixedmedia1.m3u8","quality": "SD","videoType":"HLS"}],"duration":2408},"genres":["sports","special","news"],"tags":["24/7 streaming","misc","comedy","pro wrestling","music","documentaries","DIY","live tv"],"thumbnail":"http://www.tvbydemand.com/images/streaming-tv-logo1%20copy.jpg","releaseDate":"2015-03-06","shortDescription":"Channel 1 Streaming TV MISC.","longDescription":"A little bit of everything from Documentaries, how tos/DIY, Pro Wrestling, Hockey Live Music and much much more always fresh and new"},
He said, um yeah looks like geek speak to me....... lol

The biggest problem with brightscript is, lack of developers using it, lack of opportunities to use it elsewhere. json at least has the potential to be used in other places, as does xml and languages like python etc etc.. Brightscript simply doesn't have a large enough install base to make me go out and learn it. I sought to have a roku channel because Roku was young several years ago and showed market dominance (which it still holds) and has a reputation of backwards compatibility. And then it had the sample player api. which functioned right out of the box, since I had an understanding xml already and adobephotoshop to make all the ridiculous required versions of the same image file, it took two days to get a channel running. That was 4 years ago, between all of my private channels on 3 different platforms (roku, web and kodi) we have in excess of 30,000 cumulative subscribers and over 3,000 minutes viewed a day. I am hoping to more then double those numbers with the private channels and maybe get some dollars from the advertising to upgrade/expand the content network and pay some of my content providers. If that happens and money starts coming in then yeah I'd see it worthwhile to expand my knowledge and learn brightscript to the degree of writing a custom channel that meets all the requirements to be published publically.

[destruk]

Maybe this thread should be moved to the Direct Publisher forum?
https://forums.roku.com/viewforum.php?f=100