Theme: blue neon night

[speechles 2055]

Is the fix in Emby, or BNN? Since I can't use BNN theme at this time, think I'm gonna try the Beta, seems I'm getting lots of practice in bug hunting right now anyway

This needs 2 answers:

 

1) the fix for the authentication failure was rename the device on roku.com. Once you did that and system updated, then reboot the roku it fixes that issue.

 

2) music crash bug is due to a roku firmware bug in 7.50. The 7.51 firmwares fixes it. This bug only affects the official client and blue neon app. The beta does not have code that exposes this firmware bug.

[ebr 16178]

Third answer is that, subject to confirmation, the beta app should also now not fail on login even with the default Roku TV device name.

[speechles 2055]

Third answer is that, subject to confirmation, the beta app should also now not fail on login even with the default Roku TV device name.

 

 

Are you regexp out that damn bullet and replace it with "" ? Encoding to ascii and letting it naturally strip out the crazy chars? Curious as ya know, I want to to do the same thing in the blue neon app.

[ebr 16178]

I just Escaped it with the http method.  I don't have a good way to test it so we'll have to see if that worked.

[mikeraburn 71]

The next TV will be one with Roku in it.

 

Next being if this one ever dies...

[doonze 30]

It does work now erb. I did change the name once I was logged in inside the beta app. I'm guessing it's that dot that caused the issues? So I would say the fix worked!

[doonze 30]

The next TV will be one with Roku in it.

 

Next being if this one ever dies...

I will say I really love the TV. I mean I like it function wise much better than my 55" Visio 4k! A lot of that has to do with no Emby app for Visio... Lol I hate Plex, but run both servers just for my Visio. (So who's gonna port this Roku app to Visio? Lol)

 

Couple things about the TV. Seems it's in essence a Roku 3, but it's quite a bit behind the 3 in updates. It's my only Roku, so this may be platform wide, but only allcast can see it to cast to. I've tried several Android devices and they can't see it as castable. Emby also doesn't see it. 2 out of 4 play store casting apps could see it. Of those two only allcast could cast to it. The other see saw it but could never connect.

 

I'm sure it's a firmware bug. Screen mirror is still beta on the TVs last I heard.

 

But other than those things, I love my Roku TV!

[doonze 30]

This needs 2 answers:

 

1) the fix for the authentication failure was rename the device on roku.com. Once you did that and system updated, then reboot the roku it fixes that issue.

 

2) music crash bug is due to a roku firmware bug in 7.50. The 7.51 firmwares fixes it. This bug only affects the official client and blue neon app. The beta does not have code that exposes this firmware bug.

 

I tried this, however only the Roku app sees the new name. Both allcast and allconnect and BNN see the default name. Weird. But I'm sure you get the escape in for BNN soon. So all good!

[mikeraburn 71]

@@doonze

 

What are you casting to it?

[speechles 2055]

I just Escaped it with the http method.  I don't have a good way to test it so we'll have to see if that worked.

 

Escaped it? Huh... That doesn't make any sense. You can't escape since the escapes will then become percent encoded...

 

Do you mean you percent encoded it with HttpEncode?

 

authString = authString + ", Device=" + Quote() + HttpEncode(dname) + Quote()

[doonze 30]

@@doonze

 

What are you casting to it?

 

Nothing yet, was going to cast music to it, but nothing can see it besides allcast. Emby, Android itself, my laptop, nothing can see it besides allcast. Weird, but there it is. And allcast can't see my Emby server right now (I'm guessing because DLNA is broken right now) and I hate Plex so much I didn't want to cast from it. 

 

Since I got the Beta app to work, my reasons to cast are no longer valid. So it's moot aside from a point of interest. 

 

/end thread hijack (sorry speechles)

[ebr 16178]

Escaped it? Huh... That doesn't make any sense. You can't escape since the escapes will then become percent encoded...

 

Do you mean you percent encoded it with HttpEncode?

 

authString = authString + ", Device=" + Quote() + HttpEncode(dname) + Quote()

 

HttpEncode is marked as deprecated.  The method is now called Escape() but I think they are the same thing so yes, that's correct.  You just need to get the string in a format that will pass over http.

[speechles 2055]

I just Escaped it with the http method. I don't have a good way to test it so we'll have to see if that worked.

On trying this method, it appears this alone is not viable. Spaces are %20 and all other random % encoded things in the device name looks horrible. Realize the server is not http-decode your percent encoded strings in the device name. These show with those goofy % all over in them. On the server this looks REE-dick-you-LUSS!!!. So not doing that...

 

 

Instead, renamed my roku:

TestTV•speechles ultra

 

It's bullet time (max payne reference ). Now encoding this returns a very ridiculous device name on the server riddled with % all over the place. Realize there was no issue with spaces, punctuation, other ascii chars in the devicename before. It was only when this oddball utf-8 bullet came into play that we even went down this rabbit hole. So the answer isn't to encode everything. All that does is create more problems than there were before. I have to wait until roku now updates my device name from the standard one above to test this. But run the code below through your head, it will work. ^__~

 

My solution:

    chars = devicename.split("")
    name = ""
    for each char in chars
        if asc(char) > 127
            char = chr(95)
        else if asc(char) = 34
            char = chr(39)
        else if asc(char) < 32
            map = ["@","A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","W","X","Y","Z","[","]","^","_"]
            char = "^"+map[asc(char)]
        end if
        name = name + char
    end for

The roku doesn't understand utf-8 in strings anyways, it's all ascii. So this leaves everything alone that resides in the 32-127 ascii range. Anything over ascii 127 becomes underscore. Anything under ascii 32 space becomes the control char ^ along with its mapped char to represent control characters. Probably doesn't need that part to render control characters, but ya know, when in Rome, why not? HAW

 

This even fixes the name when people customize it with the roku keyboard and use the weird characters and try to get those in the device name. This will standardize those too.

 

Questions? This is a better way, right?

 

EDIT: Added chr(34) " convert to chr(39) ' to prevent a quote in the devicename from breaking the quoting around it needed to encapsulate the name in the http query.

Edited January 21, 2017 by speechles

[ebr 16178]

The right thing to do would probably be for the server to properly decode the device name before displaying it so the apps don't have to jump through these kinds of hoops.

[speechles 2055]

The right thing to do would probably be for the server to properly decode the device name before displaying it so the apps don't have to jump through these kinds of hoops.

 

What encoding is the device name on the server? I assume it is multi-byte utf-8. The roku is strictly iso8859-1. You would still have the problem, except in reverse, when the server decodes your percents it no longer matches the original characters you expected. This will still authenticate on the server, but the bullet has now become something no longer a bullet char in the servers device name for your device. Since its already mangle these (>chr(127) chars) anyways, why not standardize the name right before its sent to the server? Thats all I am doing.

Edited January 21, 2017 by speechles

[ebr 16178]

Okay, I switched to your method to avoid the bad display on the dash.  Although, I did move the definition of your character map up out of the iteration - you might consider doing that .

[speechles 2055]

Okay, I switched to your method to avoid the bad display on the dash.  Although, I did move the definition of your character map up out of the iteration - you might consider doing that .

 

Oh snap, I didn't even realize that, good eyes. Yeah, its best not to repeat setting the map over and over inside the loop and do it once outside. That was just my test to see if indeed it worked. In the other thread I just made, I mention the devicename issue.. We can move our discussion over there to clear this topic up again.

[speechles 2055]

New Version: 4.02
* add standardized device name in url queries
* add publisherId as device id
* add CanPlay4k function to generalutils.brs
* fix capabilities to downscale 4k based on CanPlay4k
* add maximum bitrates up to 70Mbps
* add new roku icon to represent blue neon
* add "I feel lucky!" button to homescreen options row
* add "I feel lucky!" screen

The standardized device name helps eliminate the chance oddball characters can cause the app to be unable to authenticate. Using the PublisherId (Instead of DeviceUniqueId) as the device id  will keep multiple roku apps from thinking they are all active on the server. Properly added full support for 4k/HDCP2.2 detection on any device. Fix capabilities to adjust resolution based on value returned from CanPlay4k and raised maximum bitrates. In the active devices tab, you can see the new roku icon for blue neon, the roku icon in "active devices" has a blue neon feel to it. This means no longer does it place "(Blue Neon)" on the end of your device name if you don't customize the name. There is no need, you can tell them apart by icon now. Dude! Sweet!

The new "I feel lucky!" screen is the same view as favorites, continue watching, and latest. It will select random items of each item type that are unwatched and display them in each row. You would use this when bored, and want to discover new things to watch you haven't seen yet. You can always sort by random in each view, but having one spot where everything is random is better for discovery. More Awesomeness!

Updated all links in first post (yes, even the zips!!) .. Enjoy, and if any problems, bugs, shit doesn't work, then please shout out and yell loudly!!

[mikeraburn 71]

What should adding the max rate to 70 do?

Type slowly so I can understand, please

 

 

TapTalk

[speechles 2055]

What should adding the max rate to 70 do?

Type slowly so I can understand, please

 

 

TapTalk

If you have some full bitrate UHD/4k HDR bluray items, these can have insanely high bitrates. This helps get above those bitrates without using "force directstream" and auto-detection will still directstream.

 

Did you notice the "I Feel Lucky!" button? Its a 3D dice.. haw. What else screams "lucky" better than dice? Nothing does...lol.. that view is really just random unwatched, but maybe you'll get lucky and it suggests something good.

Edited January 25, 2017 by speechles

[ebr 16178]

* add CanPlay4k function to generalutils.brs

* fix capabilities to downscale 4k based on CanPlay4k

 

FYI - I don't think this is necessary.  Did you find some situation where it was?

 

The Roku device itself won't allow you to set it to 4K resolution unless those other checks you are doing here also pass so at the very least I think those checks are redundant.

[speechles 2055]

FYI - I don't think this is necessary.  Did you find some situation where it was?

 

The Roku device itself won't allow you to set it to 4K resolution unless those other checks you are doing here also pass so at the very least I think those checks are redundant.

 

How you figure? You tell the server the maximum 4k output dont you?

 

 

    if Fourkready
            max4kWidth = "3840"
            max4kHeight = "2160"
    else
        max4kWidth = "1920"
        max4kHeight = "1080"
    end if

 

Fourkready = CanPlay4k()

 

You see now why its needed? This tells the server for the hevc and vp9 codecs what the maximum supported resolution is. This is required. The server will attempt to send at 3840x2160 without this.

[ebr 16178]

No.  I don't think that's a problem at all.  I think you are causing unnecessary transcoding there - at least in my experience so I was asking if you had discovered a specific situation that made it necessary.

[speechles 2055]

No.  I don't think that's a problem at all.  I think you are causing unnecessary transcoding there - at least in my experience so I was asking if you had discovered a specific situation that made it necessary.

 

Okay, lets say you have a roku ultra. It is connected to a 1080p TV.

 

You've downloaded some 4k/UHD (3840x2160) stuff to have. It is for when you get a 4k/UHD TV, but you haven't gotten one yet.

 

Now the original way, would check for hevc or vp9 and know it is a 4k device. It would immediately enable 3840x2160.

 

Problem is, the roku ultra is only connected to a 1080p TV. Now you choose that 4k video and attempt to play. The max resolution the app told the server is 3840x2160. The server being diligent and doing what the app tells it serves up a 3840x2160 stream. It doesn't play, falls back to transcoding (which fails it will attempt to copy the video stream), and just falls back to the detail screen with a playback error dialog. You think.. WTF..

 

Now to solve this, you need to tell the server, what the maximum supported resolution for hevc and vp9 is. This is what CanPlay4k() is doing. It is either true or false. True means I can use 3840x2160 for hevc/vp9. False means I use 1080p.

 

How is this causing extra transcoding than necessary? When actually, It is making it so transcoding can make the UHD video playable on 1080p. The server will see the hevc codec, and notice its 1920x1080 yet the stream is 3840x2160. Now the server will transcode to the correct resolution and the video plays. YAY!!

Edited January 25, 2017 by speechles

[ebr 16178]

Problem is, the roku ultra is only connected to a 1080p TV. Now you choose that 4k video and attempt to play. The max resolution the app told the server is 3840x2160. The server being diligent and doing what the app tells it serves up a 3840x2160 stream. It doesn't play, falls back to transcoding (which fails it will attempt to copy the video stream), and just falls back to the detail screen with a playback error dialog. You think.. WTF..

 

What I'm asking is, have you actually seen this happen?  Because I can direct play that item just fine on my Roku Premiere hooked to a 1080p TV.

 

This makes sense to me as the Roku itself should be managing final display scaling - just like it would if you fed it a 720p stream or a 1080 one on a 720 set.