On Monday I submitted updates to IP Camera Viewer Basic and Pro. Today they were published but now both Basic and Pro channel install the Pro channel. I downloaded the packages from the developer console to make sure I didn’t submit same one by mistake, and I did not. The package submitted to update the Basic channel contains the Basic channel and the Pro … the Pro. I wonder how did this happen… Who should I contact to fix the problem?
Thanks.
ghostbust… my bad, call developer@roku.com
Most unusual. The channel# is 143924.
Per web store, vanity code=IPCAMVIEWBASIC, name=“IP Camera Viewer - Basic”, version=2.1
When installed though, it identifies itself as “IP Camera Viewer Pro”, version=“1.112.0”
In the latter case i think it takes these from the manifest, the former is from the dev.portal.
There seem to be some buglets around “easy add”. What’s the “highest” Roku you tested that on - Roku2, Roku3?
Also, it doesn’t say there to which URL to go (i presume the Roku one but port 7000 aint it)
“EnTerr” wrote:
There seem to be some buglets around “easy add”. What’s the “highest” Roku you tested that on - Roku2, Roku3?
Also, it doesn’t say there to which URL to go (i presume the Roku one but port 7000 aint it)
The “easy add” bug is fixed in my code and will be pushed with next update. The problem was that I was getting the Roku IP from eth0, so it won’t show the IP:port if the Roku is connected over Wifi. I do the tests on a Roku 3 and a Roku Ultra. The port is 12345.
“ioan” wrote:
The “easy add” bug is fixed in my code and will be pushed with next update. The problem was that I was getting the Roku IP from eth0, so it won’t show the IP:port if the Roku is connected over Wifi.
This should do it (arguably) right:
IPs = createObject("roDeviceInfo").getIpAddrs()
if IPs.count() > 0 then ip = IPs.items()[0].value else ip = invalid
I do the tests on a Roku 3 and a Roku Ultra. The port is 12345.
Try “easy add” on the Ultra in 1080p mode, i think the image will overlap the text. Let me guess, you have manifested something like “ui_resolutions=hd,fhd”? The quickest fix would be to un-manifest ui_resolutions or changing that to “ui_resolutions=hd”.
On a stylistic note, seems to me better would be if in the edit screen there are no separate “* Edit blah” buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.
On a personal note, i tried the app with a D-link DCS-5010L and it didn’t work, even as access on that is as easy as http://:80/image.jpg (i left the MJPEG and PTZ links empty). Could Dlink’s use of http basic authentication be the issue here?
PS. oh, and one more thing - the notification "Apologogies… | We found a bug in the previous version fo the application… " is annoying. Why does it keep showing up over and over again? I’d expect this to be a one-time thing (how - e.g. make a note in the registry it’s not the first launch)
“ioan” wrote:
The problem was that I was getting the Roku IP from eth0, so it won’t show the IP:port if the Roku is connected over Wifi.
To get the Roku’s IP address used by the connection (whether wireless or wired), do this:
ipAddress = CreateObject("roDeviceInfo").GetConnectionInfo().ip
“ioan” wrote:
On Monday I submitted updates to IP Camera Viewer Basic and Pro. Today they were published but now both Basic and Pro channel install the Pro channel. I downloaded the packages from the developer console to make sure I didn’t submit same one by mistake, and I did not. The package submitted to update the Basic channel contains the Basic channel and the Pro … the Pro. I wonder how did this happen… Who should I contact to fix the problem?Thanks.
Make sure that in your manifest file, the title for the pro channel includes “Pro”, and for the basic channel includes “Basic”.
Make sure that each time you submit a new package to the channel store (pro or basic), you increase the *_version fields in the manifest file appropriately.
Make sure that when you submit a new package build with the Developer Dashboard, the Channel Version on the Package Upload page matches the manifest file’s major_version and minor_version.
Make sure that you always sign your submitted packages with the same developer key.
Make sure you keep the developer key, especially the password, somewhere safe where you’ll never lose or forget it, as you can’t recover a lost password.
“EnTerr” wrote:
Try “easy add” on the Ultra in 1080p mode, i think the image will overlap the text. Let me guess, you have manifested something like “ui_resolutions=hd,fhd”? The quickest fix would be to un-manifest ui_resolutions or changing that to “ui_resolutions=hd”.
I tried “ui_resolutions=hd,fhd”, “ui_resolutions=hd” and “ui_resolutions=fhd”. All look fine. I’m recalculating the position and size for all elements to look good on any resolution. I know that the image for “easy add” in HD doesn’t fit on the screen… I was too lazy to fix it 
Let me know if you saw a problem where the text overlaps, because I can’t reproduce it.
“EnTerr” wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate “* Edit blah” buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.
Can I focus on a Text field? I didn’t know I could do that…
“EnTerr” wrote:
On a personal note, i tried the app with a D-link DCS-5010L and it didn’t work, even as access on that is as easy as http://
Yes, the problem probably is with the basic authentication. Probably D-Link cameras sends back a “realm” attribute that my application doesn’t handle yet. I have the algorithm to handle the “realm” attribute working on the PC, I just have to port it to BS.
“EnTerr” wrote:
PS. oh, and one more thing - the notification "Apologogies… | We found a bug in the previous version fo the application… " is annoying. Why does it keep showing up over and over again? I’d expect this to be a one-time thing (how - e.g. make a note in the registry it’s not the first launch)
Yeah, I agree, it should have been a flag in the registry that the message was showed once.
Anyway, it shows in the beginning only if you don’t have any cameras added. As soon as you add a camera (aka really use the application) the message goes away. I’ll get rid of the message in the next update.
By the way, is there a limit on how often I can submit updates to my channels?
“belltown” wrote:
ipAddress = CreateObject("roDeviceInfo").GetConnectionInfo().ip
I was using something along the lines of what EnTerr posted but this is the more elegant. Thank you.
“belltown” wrote:
Make sure that when you submit a new package build with the Developer Dashboard, the Channel Version on the Package Upload page matches the manifest file’s major_version and minor_version.
I didn’t know they have to match. I’ll make sure from now on to match the package version with the Package Upload page version.
“belltown” wrote:
Make sure that you always sign your submitted packages with the same developer key.
Make sure you keep the developer key, especially the password, somewhere safe where you’ll never lose or forget it, as you can’t recover a lost password.
Yeap, I learned this one the hard way.
“ioan” wrote:
“belltown” wrote:
Make sure that when you submit a new package build with the Developer Dashboard, the Channel Version on the Package Upload page matches the manifest file’s major_version and minor_version.
I didn’t know they have to match. I’ll make sure from now on to match the package version with the Package Upload page version.
That is stated here: https://github.com/rokudev/docs/blob/master/publish/channel-store/publishing.md#update-an-existing-channel:
Be sure to increment the channel’s major, minor, and build versions in the manifest as well as the Channel Version on this page for each new package submitted.
“ioan” wrote:
I tried “ui_resolutions=hd,fhd”, “ui_resolutions=hd” and “ui_resolutions=fhd”. All look fine. I’m recalculating the position and size for all elements to look good on any resolution. I know that the image for “easy add” in HD doesn’t fit on the screen… I was too lazy to fix it
The value you should use for ui_resolutions should represent the canvas size that your code is drawing to. It has nothing whatsoever to do with what resolution it will run on. So, if your code assumes a canvas size of 1280x720, then use: ui_resolutions=hd. However, if your code computes sizes and coordinates automatically based on the values of ifDeviceInfo.GetUIResolution() then it may not matter what value you use.
If you have a specific image that is a particular size, assuming it was made to fit within a specific screen canvas size, then you may find it helpful to specify the associated ui_resolutions value (otherwise you’d have to specify multiple image sizes).
When your code runs on any device that is NOT listed in your ui_resolutions list, then the UI will scale AUTOMATICALLY for that device. This automatic scaling ONLY happens for a resolution you do NOT specify. If you specify fhd,hd for example, and you draw a 640x360 image that was designed to take up half the width and height on an HD canvas, the image will render correctly on the hd device (because it was sized for a resolution you specified), will also render somewhat okay on an SD device (because it will be automatically scaled, since you didn’t specify sd), but will NOT render correctly on the FHD device (because it won’t automatically scale if you specified fhd and it’s running on an FHD device – so you’d either need a separate image sized for FHD dimensions, or only specify ui_resolutions=hd).
“ioan” wrote:
I tried “ui_resolutions=hd,fhd”, “ui_resolutions=hd” and “ui_resolutions=fhd”. All look fine. I’m recalculating the position and size for all elements to look good on any resolution. I know that the image for “easy add” in HD doesn’t fit on the screen… I was too lazy to fix it
indeed, i did [spoiler=screenshot:3ojanfqk]
[upload|wJXp7GgWd3ACsHQfq27+yA==]
[/spoiler:3ojanfqk]
“EnTerr” wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate “* Edit blah” buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.
Can I focus on a Text field? I didn’t know I could do that…
You can focus on Buttons. Is that not enough?
Yes, the problem probably is with the basic authentication. Probably D-Link cameras sends back a “realm” attribute that my application doesn’t handle yet. I have the algorithm to handle the “realm” attribute working on the PC, I just have to port it to BS.
Yes, it does. roUrlTransfer has disability on this but see https://forums.roku.com/viewtopic.php?f … 15#p159384
< HTTP/1.0 401 Authorization Required
< Server: alphapd
< Date: Sun Mar 26 16:30:20 2017
< Pragma: no-cache
< Cache-Control: no-cache
< Content-type: text/html
< WWW-Authenticate: Basic realm="DCS-934L"
Anyway, it shows in the beginning only if you don’t have any cameras added. As soon as you add a camera (aka really use the application) the message goes away. I’ll get rid of the message in the next update.
Oh, i see what you did there - not having cameras from registry makes it show the popup. It also does it after i delete the (last) camera.
By the way, is there a limit on how often I can submit updates to my channels?
Not that i know of.
“belltown” wrote:
The value you should use for ui_resolutions should represent the canvas size that your code is drawing to. It has nothing whatsoever to do with what resolution it will run on. So, if your code assumes a canvas size of 1280x720, then use: ui_resolutions=hd. However, if your code computes sizes and coordinates automatically based on the values of ifDeviceInfo.GetUIResolution() then it may not matter what value you use.
If you have a specific image that is a particular size, assuming it was made to fit within a specific screen canvas size, then you may find it helpful to specify the associated ui_resolutions value (otherwise you’d have to specify multiple image sizes).
When your code runs on any device that is NOT listed in your ui_resolutions list, then the UI will scale AUTOMATICALLY for that device. This automatic scaling ONLY happens for a resolution you do NOT specify. If you specify fhd,hd for example, and you draw a 640x360 image that was designed to take up half the width and height on an HD canvas, the image will render correctly on the hd device (because it was sized for a resolution you specified), will also render somewhat okay on an SD device (because it will be automatically scaled, since you didn’t specify sd), but will NOT render correctly on the FHD device (because it won’t automatically scale if you specified fhd and it’s running on an FHD device – so you’d either need a separate image sized for FHD dimensions, or only specify ui_resolutions=hd).
Man, this makes it SO MUCH easier… Few times I wanted to start a thread how bad is that Roku doesn’t auto scale for whatever resolution. I don’t know how I ended up with ui_resolutions=hd, fhd in the manifest so I had to take care of scaling all elements by hand. Here is some code I wrote to make sure everything looks good in hd and fhd and I call those functions on all UI elements:
function getScaleWH()
di = CreateObject("roDeviceInfo")
ds = di.GetDisplaySize()
return {dw: ds.w, dh: ds.h, w: 1280, h: 720}
end function
function screenWH()
ds = getScaleWH()
return {w: ds.dw, h: ds.dh}
end function
function calculateWH(w as float, h as float)
ds = getScaleWH()
return {w: ((ds.dw * w)/ds.w), h: ((ds.dh * h)/ds.h)}
end function
sub calculateTranslation(obj as object)
ds = getScaleWH()
obj.translation = [((ds.dw * obj.translation[0])/ds.w), ((ds.dh * obj.translation[1])/ds.h)]
end sub
sub calculateObjWH(obj as object)
ds = getScaleWH()
if obj.width <> invalid then
obj.width = ((ds.dw * obj.width)/ds.w)
if obj.height <> invalid then
obj.height = ((ds.dh * obj.height)/ds.h)
end if
else if obj.minWidth <> invalid then
obj.minWidth = ((ds.dw * obj.minWidth)/ds.w)
obj.height = ((ds.dh * obj.height)/ds.h)
else if obj.itemSize <> invalid then
obj.itemSize = [((ds.dw * obj.itemSize[0])/ds.w), ((ds.dh * obj.itemSize[1])/ds.h)]
else
' nothing yet
print "nothing to size"
end if
end sub
I was designing the UI in HD but then it didn’t look well when FHD was in the manifest (which I thought it was necessary to support FHD)… Well, I guess I’ll have to delete some of my code and make everything simpler. BTW, which screen size should I make the UI for (aka "what value should I have in ui_resolutions)? Majority of TVs now are FHD, right?
“EnTerr” wrote:
Yes, it does. roUrlTransfer has disability on this but see https://forums.roku.com/viewtopic.php?f … 15#p159384
< HTTP/1.0 401 Authorization Required < Server: alphapd < Date: Sun Mar 26 16:30:20 2017 < Pragma: no-cache < Cache-Control: no-cache < Content-type: text/html < WWW-Authenticate: Basic realm="DCS-934L"
I don’t use roUrlTransfer at all im my code because of this problem. I use “roStreamSocket” and I handles the basic authentication similar with what is in the post you quoted. The basic authentication with realm is a little different though. The server provides a challenge using the realm and you have to create the response accordingly. Quote from RFC 1945:
The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL of the
server being accessed, defines the protection space. These realms
allow the protected resources on a server to be partitioned into a
set of protection spaces, each with its own authentication scheme
and/or authorization database. The realm value is a string, generally
assigned by the origin server, which may have additional semantics
specific to the authentication scheme.
I’ll have to implement this soon because I expect many cameras uses this authentication scheme.
“ioan” wrote:
which screen size should I make the UI for (aka "what value should I have in ui_resolutions)? Majority of TVs now are FHD, right?
Roku’s official position, according to https://sdkdocs.roku.com/display/sdkdoc/Specifying+Display+Resolution is:
Recommended Intended Resolution
For Scene Graph applications, Roku recommends you design and develop for an intended 1080 screen resolution. But for performance reasons, for Roku players and display screens that do not support full high-definition resolution, you should supply both 1080 and 720 graphical images for your application. The Scene Graph application will scale the design elements and the graphical images for the actual supported resolution, but you can achieve the best appearance for all supported resolutions if you provide both resolutions of graphical images. If you can only provide one resolution of graphical images, provide 720 graphical images.
There may be reasons why you wouldn’t want to develop in FHD, like not having an FHD-capable TV or Roku player to test on, or being concerned that your package will be too large to store lots of hi-def images. In the end, it comes down to a personal choice.
If you do rely on autoscaling, then be sure to read the “Autoscaling Guidelines” on that same page.
“EnTerr” wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate “* Edit blah” buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.
Can I focus on a Text field? I didn’t know I could do that…
You can focus on Buttons. Is that not enough?
You got me confused
“ioan” wrote:
I don’t use roUrlTransfer at all im my code because of this problem. I use “roStreamSocket” and I handles the basic authentication similar with what is in the post you quoted. The basic authentication with realm is a little different though. The server provides a challenge using the realm and you have to create the response accordingly. …
Yeah… but no. You are doing it wrong!
You are talking here about http digest authentication and this is something that roUrlTranfer already does well via .setUserAndPassword(). So there is no point of reinventing a socket wheel there, esp. given you can do async transfers with roUrlTransfer already.
Now, the issue is with http basic authentication - since some IP cameras (Dlink i saw, Sony i read about etc) only support basic auth and nothing else. Funny story, the cURL library that Roku uses supports basic-auth just fine but seems in the early days of Roku Inc (before there was even a Roku streaming player but only BrightSign signage), somebody decided to make a “principled stand” and intentionally disable that in roUrlTransfer. But forgot to notify the internet appliance makers and so now, almost 10 years later we still suffer that somebody’s principles. But, as i pointed out, there is fairly easy workaround by adding the right header.
“ioan” wrote:
“EnTerr” wrote:
On a stylistic note, seems to me better would be if in the edit screen there are no separate “* Edit blah” buttons next to the fields but instead the cursor walks the fields directly and pressing OK atop one goes into entry edit screen.
… You got me confused
I said ‘’‘no separate “* Edit blah” buttons next to the fields’‘’. You can use the buttons as text fields. There is no need to have 2 different entities side to side. Buttons already have a label inside.
“EnTerr” wrote:
“ioan” wrote:
I don’t use roUrlTransfer at all im my code because of this problem. I use “roStreamSocket” and I handles the basic authentication similar with what is in the post you quoted. The basic authentication with realm is a little different though. The server provides a challenge using the realm and you have to create the response accordingly. …
Yeah… but no. You are doing it wrong!
You are talking here about http digest authentication and this is something that roUrlTranfer already does well via .setUserAndPassword(). So there is no point of reinventing a socket wheel there, esp. given you can do async transfers with roUrlTransfer already.Now, the issue is with http basic authentication - since some IP cameras (Dlink i saw, Sony i read about etc) only support basic auth and nothing else. Funny story, the cURL library that Roku uses supports basic-auth just fine but seems in the early days of Roku Inc (before there was even a Roku streaming player but only BrightSign signage), somebody decided to make a “principled stand” and intentionally disable that in roUrlTransfer. But forgot to notify the internet appliance makers
I’m sure you are right and everything could be done with roUrlTransfer, but for me it was easier to use roStreamSocket. I’m not sure how would m-jpeg or rtsp be implemented with roUrlTransfer, but I know how to do it with roStreamSocket. How do you continuously read packets into a roByteArray from the socket using roUrlTransfer?
“ioan” wrote:
Man, this makes it SO MUCH easier… Few times I wanted to start a thread how bad is that Roku doesn’t auto scale for whatever resolution. I don’t know how I ended up with ui_resolutions=hd, fhd in the manifest so I had to take care of scaling all elements by hand.
You are not the only one - i was in the same boat until very recently. I don’t think even inside RokuCo there exist an understanding about the auto-scaling ability which was added last year. There was never an announcement, it was never drummed up or explained in a blog post - rather it was quietly tucked under a RSG topic (wrongly so because it applies to SDK1 too)
I was designing the UI in HD but then it didn’t look well when FHD was in the manifest (which I thought it was necessary to support FHD)… Well, I guess I’ll have to delete some of my code and make everything simpler. BTW, which screen size should I make the UI for (aka "what value should I have in ui_resolutions)? Majority of TVs now are FHD, right?
For my money, 720 (HD) is the way to go over the next few years. Which flies against the official party line but hear me out: the only Roku players that can display 1080 (FHD) images/UI are the 4k ones (that’s Roku 4, the Premieres and 4k RokuTVs). All other players display your assets in 720, even when the HDMI output signal is 1080p and video plays in 1080p. Because Roku works in mysterious ways :). And how many 4k players are there as %? Not particularly high. Hopefully the Co will publish some model breakdown numbers - but i am ready to bet that a year from now, when speaking about Roku UI, the native-HD players would still be beating the native-FHD ones 10:1 or more. It will take additional 2 years for the 4k-capable players to overtake the pre-4k ones - at which point it would make sense to convert to 1080 (FHD) assets by pushing a new version.
In addition, FHD UI and assets would burden both the memory and performance of the low-end and older boxes (24xx, 25xx, 27xx, 3xxx), leading to “kaboom!” experiences.
Supporting both resolutions in parallel is a royal PITA and feels to me like the “worst of both worlds” for a small shop. But if one is a big TV network with the money and labor to blow - go ahead, knock yourself out.
