Roku Developer Program

[ludwig_benitez]

"malloys" wrote:

Sounds like either your machine is not pointing to the new java installation as the default, or your eclipse.ini file has a -vm argument in it that points to java 1.6.

If you open up a terminal window and type: java -version, What do you see?
if you open up your eclipse instance's eclipse.ini file, do you see a -vm argument value? If so, what is it?

My Friend, when open a terminal window, the version is "1.7.0_45". And when I see eclipse.ini:

"-startup
../../../plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.2.R36x_v20101019_1345
-product
org.eclipse.epp.package.php.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=256m
-Xms40m
-Xmx384m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts"

I installed JDK and JRE 7u45, and within eclipse I installed JRE in Preferences--->Java--->Installed JRE's--->Add
and i add the path of JDK1.7.
Thanks my friend.

[malloys]

OK, the only remaining possibilities I'm aware of are either:

a) You are launching eclipse with a -vm command line argument that points to a java 1.6 installation
..or...
b) At sometime in the past, someone has installed a 1.6 jre or jdk in a sub-dir under eclipse's root directory named "jre".

You may want to take a look at this for reference: http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F#Find_the_JVM

Cheers

[EnTerr]

"malloys" wrote:
Not trying to hijack the thread but I can't resist responding...

"NewManLiving" wrote:

No problem except from time to time I have to re-enter the ip address in the deployment wizard (don't know if this is intentional or just a bug).

That's probably not a bug, but I'd need to know more details to be 100% sure (add to the semi-permanent eclipse plugin thread if the explanation below doesn't jibe what you're seeing).
The IP address combo (in both the deployment wizard and the debug console) gets it's list from a SSDP listener background thread.
Addresses that haven't been heard from since their SSDP timeout expired are periodically purged from the list.
Any IP address that you manually enter has a timeout of 20 minutes - If that Roku box does an SSDP broadcast before the initial 20 minute timeout is up, the thread updates the timeout as specified by the SSDP broadcast (and the cleanup process is delayed on subsequent eclipse sessions to give the boxes enough time to do their SSDP broadcasts again).

To me the behavior you described - expiring the IP after timeout - is a bug. It will cause problems when IP multicast does not work in the network and there are routers that do that (i know that from experience). The solution is to stop over-doing it, i.e. do not expire IP, ever.

What's the worst that can happen if plugin keeps outdated IP - deployment will fail (and developer gets a chance to update IP). If receiving multicast, do update the IP - so getting best of both (network) worlds. I presume you are matching IP to serial number? - that part takes care of "removing" old IP when new IP for specific player is heard of.

[malloys]

"EnTerr" wrote:

"malloys" wrote:
Not trying to hijack the thread but I can't resist responding...

"NewManLiving" wrote:

No problem except from time to time I have to re-enter the ip address in the deployment wizard (don't know if this is intentional or just a bug).

That's probably not a bug, but I'd need to know more details to be 100% sure (add to the semi-permanent eclipse plugin thread if the explanation below doesn't jibe what you're seeing).
The IP address combo (in both the deployment wizard and the debug console) gets it's list from a SSDP listener background thread.
Addresses that haven't been heard from since their SSDP timeout expired are periodically purged from the list.
Any IP address that you manually enter has a timeout of 20 minutes - If that Roku box does an SSDP broadcast before the initial 20 minute timeout is up, the thread updates the timeout as specified by the SSDP broadcast (and the cleanup process is delayed on subsequent eclipse sessions to give the boxes enough time to do their SSDP broadcasts again).

To me the behavior you described - expiring the IP after timeout - is a bug.

It will cause problems when IP multicast does not work in the network and there are routers that do that (i know that from experience).

OK, that surprises me - can you list any of those routers?
While I have no doubt a router admin can configure a router to block UDP multicast traffic, I'm unaware of any routers commonly in use that don't correctly support UDP multicast traffic.
As an extension, I'm also unaware of any common and logical reason to configure a router to block all SSDP specifically (and plenty of reasons why you shouldn't). If you can think of any, can you cite specific real-world examples?

"EnTerr" wrote:

The solution is to stop over-doing it, i.e. do not expire IP, ever.

What's the worst that can happen if plugin keeps outdated IP - deployment will fail (and developer gets a chance to update IP).

The reason for removing expired entries is to prevent increasingly polluting the list over time with outdated addresses.
Unless you've setup your environment so that your Roku Box(es) always have static or DHCP reserved IP addresses - which AFIK is not particularly common, the list is likely to have more than a few incorrect entries over time if there is no way of removing them.

The only other option for entry removal other than timeouts and automatic culling, is to add a mechanism for explicit manual removal of items from the list.
I'd be more than happy to file the latter as an enhancement request on behalf of anyone using the plugin that believes they need it (although a previous post in this forum strongly implies that you do not use the plugin and instead prefer to use an array of other more simple tools).

"EnTerr" wrote:

If receiving multicast, do update the IP - so getting best of both (network) worlds. I presume you are matching IP to serial number? - that part takes care of "removing" old IP when new IP for specific player is heard of.

My apologies for any confusion caused by my previous over-simplified explanation... The plugin has always used the serial numbers as the primary identifier when determining entry updates when the info is coming from SSDP broadcasts or explicit query responses. Manually entered IP addresses, if an SSDP broadcast is received from a box at that IP address before the timeout , are replaced with the expanded info from the SSDP broadcast (including the new timeout).

cheers

[EnTerr]

"malloys" wrote:
OK, that surprises me - can you list any of those routers?
While I have no doubt a router admin can configure a router to block UDP multicast traffic, I'm unaware of any routers commonly in use that don't correctly support UDP multicast traffic.
As an extension, I'm also unaware of any common and logical reason to configure a router to block all SSDP specifically (and plenty of reasons why you shouldn't). If you can think of any, can you cite specific real-world examples?
...
The reason for removing expired entries is to prevent increasingly polluting the list over time with outdated addresses.
Unless you've setup your environment so that your Roku Box(es) always have static or DHCP reserved IP addresses - which AFIK is not particularly common, the list is likely to have more than a few incorrect entries over time if there is no way of removing them.
...
My apologies for any confusion caused by my previous over-simplified explanation... The plugin has always used the serial numbers as the primary identifier when determining entry updates when the info is coming from SSDP broadcasts or explicit query responses. Manually entered IP addresses, if an SSDP broadcast is received from a box at that IP address before the timeout , are replaced with the expanded info from the SSDP broadcast (including the new timeout).

Intuitively i also did not expect problems but experience taught me otherwise. I have a Roku remote app with multiple tens of thousands of users and i have received multiple complaints for different home gateways. I investigated the issue over 2 years ago, so have no detailed recollection of all routers screwing the multicast pooch. Some examples i can easily copy&paste from the app description though:

"Remote for Roku" wrote:
There is no configuration needed, as long as your iOS device is WiFi-connected to the same network your Roku player is on. Notable exception are some Qwest/Actiontec routers (e.g. PK5000, M1000, MI424WR, GT701WG, GT724WG), which do not support auto-discovery protocol - ...

It is not about intentional blocking - rather i think multicast had issues with wireless (i think that was the case in a Netgear one, where multicast worked on Roku wired but not wifi). If you think about it, there could be no datagram broadcast nor multicast as a single packet over the radio because of WAP security; since each client encrypts differently, so router has to send separate packets to each client individually. If you have contacts with whomever writes the remote apps in RokuCo, you can ask them for their experience; they have gone to such lengths in distrusting autodiscovery as to store the list of player IPs for the account on central server.

You said S/N is used as primary key => therefore when particular Roku changes its IP, the new IP will knock the old IP off the list. There will be no case of "increasingly polluting the list over time with outdated addresses" if no expiration.

[malloys]

"EnTerr" wrote:

Intuitively i also did not expect problems but experience taught me otherwise. I have a Roku remote app with multiple tens of thousands of users and i have received multiple complaints for different home gateways. I investigated the issue over 2 years ago, so have no detailed recollection of all routers screwing the multicast pooch. Some examples i can easily copy&paste from the app description though:

"Remote for Roku" wrote:
There is no configuration needed, as long as your iOS device is WiFi-connected to the same network your Roku player is on. Notable exception are some Qwest/Actiontec routers (e.g. PK5000, M1000, MI424WR, GT701WG, GT724WG), which do not support auto-discovery protocol - ...

You might want to think about re-wording that part of the app description.
I can't say for certain for all of those listed - but at the very least, the MI424WR does support SSDP.
The issue with that particular router was (and may still be) that the default config for certain firmware releases foolishly had IGMP filtering set to deny all by default (at least for Verizon Fios users that much is provable - the poor default config may have come from Verizon, or it may have been Qwest/Actiontec - I'm not sure anyone ever tracked down whose default config it was - AFIK, it was never publicly stated either way).
The workaround was/is to change the config to either entirely disable IGMP filtering (which that router UI questionably refers to as "IGMP proxy"), or to disable IGMP blocking on a per-end-host basis.
I suspect the other Actiontec routers in your list may have had the same issue.

"EnTerr" wrote:

It is not about intentional blocking - rather i think multicast had issues with wireless (i think that was the case in a Netgear one, where multicast worked on Roku wired but not wifi). If you think about it, there could be no datagram broadcast nor multicast as a single packet over the radio because of WAP security; since each client encrypts differently, so router has to send separate packets to each client individually.

True, multicast over wireless is inefficient for that reason (and a few others) and therefore can slow down a wireless subnet that has alot of end-hosts, but I know of no routers that remove support for SSDP or multicast in general. BTW - typically the inefficiency/inherent slowness can be mitigated by proper configuration - good routers have separate config values for wireless vs wired interfaces that can partially compensate for this difference when it comes to multicast packet handling.
Again, I suspect misconfiguration is the real culprit in the Netgear example. If you remember the model, I'll bet I can track down the issue to a bad config, not lack of support.

"EnTerr" wrote:

If you have contacts with whomever writes the remote apps in RokuCo, you can ask them for their experience; they have gone to such lengths in distrusting autodiscovery as to store the list of player IPs for the account on central server.

Interesting...
I had assumed that mechanism was created to avoid having non-technical customers deal with IP addresses any more than was necessary - i.e. for remote app usability and possibly for common ease of support reasons (e.g. "which of your 3 boxes is having trouble?" .... "It's the one in the 'living room'"... "Oh, OK, I see you've haven't gotten the new firmware and that channel pushed to that box yet", etc).

"EnTerr" wrote:

You said S/N is used as primary key => therefore when particular Roku changes its IP, the new IP will knock the old IP off the list. There will be no case of "increasingly polluting the list over time with outdated addresses" if no expiration.

Now you're playing both sides 🙂

Two problems with the "no expiration (or manual removal) needed" theory that result in orphans...

1) It assumes the dev never gets rid of any Roku boxes (sells, gifts, box gets fried, gets smashed against the wall in a fit of rage 😉 etc.).

2) It also assumes SSDP never temporarily fails/gets dropped on the floor (BTW - in which case, manual IP address entry would never be needed).
There is at least 1 situation where this is not true (other than router temp mis-config), and has been observed: When a subnet has too much traffic...
Since SSDP relies on UDP multicast for announcements, ACKs or retrans on collision aren't required... so a busy/congested subnet means SSDP announcements sometimes don't find their way to the dev box. When this occurs, the dev may choose to manually enter an IP address (which is now an entry without an S/N) of any Roku box not previously known to the plugin (newly powered up, newly connected to the network, etc. and so never previously in the list with an associated S/N).
If the SSDP issue is not resolved, and the Roku box receives a new IP address for any reason (reboot, DHCP lease is up, etc.), dev must manually enter a new IP address... so, the old address is orphaned (no S/N for either to match up to, but old one will not match up anything - IP addy or S/N when SSDP is restored).

Of course, both situations resolve at some indeterminate time in the future if another Roku box eventually gets the orphaned IP address assigned to it... but that could be a long wait depending on the DHCP pool size and lease length.

Cheers

[EnTerr]

We live in imperfect (networking) world. I object to this:

"malloys" wrote:
... I know of no routers that remove support for SSDP or multicast in general.

How about google-ing a little, here is Sonos listing routers with multicast issues, here is Chromecast and HDHomeRun - both give work-arounds for most routers - yet both list SMCD3GNV as hopeless ("broken and will block this traffic regardless of what configuration options are set").

If you want to dig the Actiontec case, i seem to recollect now that to have that configurable setting in UI, one had to have the right firmware - and that had to be pushed by Qwest, since PK5000 being DSL combo is provisioned by the ISP. Which Qwest would not do at the time. Chromecast Help puts it vaguely: "ActionTec Routers may not support the multicast protocol, which your network must have to detect your Chromecast. If multicast is available, you need to..."

"malloys" wrote:
Two problems with the "no expiration (or manual removal) needed" theory that result in orphans...
1) It assumes the dev never gets rid of any Roku boxes (sells, gifts, box gets fried, gets smashed against the wall in a fit of rage 😉 etc.).
2) It also assumes SSDP never temporarily fails/gets dropped on the floor
[...] so a busy/congested subnet means SSDP announcements sometimes don't find their way to the dev box. When this occurs, the dev may choose to manually enter an IP address (which is now an entry without an S/N)

Case #1 is real. Case #2 is a straw-man: SSDP with new IP will have to get lost 3 times in a row (assuming current TTL of 60 mins and renewal every 20) and even then it will "magically" fix itself on the 4th (or N+1) time. But if network conditions are really so bad that multiple datagrams get dropped - that would mean you cannot trust "radio silence" to expire IPs. P.S. Oh i see S/N worried you, that's real... but one can collect that from UPnP descriptor at http://IP:8060/ 8-)


It seems clear - you really, really, really like the way you expire the IPs in your plugin and will rather people putz with router configurations or replace the router than change plugin behavior. "You can lead a horse to water, but you can't make it drink" :?
That's fine, i have no horse in the eclipse derby. And there are probably what - about hundred people? (3-digit number anyway) - using said plugin. The chance of encountering the issue is low and those are people you can ask to play with router config or replace it. It's manageable. However, if you have tens of thousands of users to your app, that's not the right approach - and if you have over a MILLION users (which is the case with RokuCo mobile apps), that'd be absurd. Oh, and the level of sophistication of those users is far removed from a developer's, i can share as much.

[malloys]

"EnTerr" wrote:
How about google-ing a little, here is Sonos listing routers with multicast issues, here is Chromecast and HDHomeRun - both give work-arounds for most routers -

Yep, saw those long ago... and don't 100% trust the content due to entries that are outdated or were provably incorrect from the outset.
And note, I've been drawing a distinction between routers that have SSDP support turned off in the config vs those that have removed support (or have a broken implementation).
That's something those lists seem to be a bit loose on in their language.

"EnTerr" wrote:

yet both list SMCD3GNV as hopeless ("broken and will block this traffic regardless of what configuration options are set").

Yeah, saw that one a while ago as well.
Can't prove it since I've never had access to that specific model, but I suspect the issue with the SMCD3GNV is that it's admin interface is not publicly documented, and has some hard to find or miss-labeled setting (I've dealt with other SMC routers many times, and that has been the case on more than one occasion). I do know other SMC router models support multicast as long as the config settings are correct.

"EnTerr" wrote:

If you want to dig the Actiontec case, i seem to recollect now that to have that configurable setting in UI, one had to have the right firmware - and that had to be pushed by Qwest, since PK5000 being DSL combo is provisioned by the ISP. Which Qwest would not do at the time. Chromecast Help puts it vaguely: "ActionTec Routers may not support the multicast protocol, which your network must have to detect your Chromecast. If multicast is available, you need to..."

If I recall correctly, that was both a poor config and a "hidden" config UI issue combined, which eventually got resolved - the firmware versions that had the problem did have the config UI for the settings, but there was no link into the screen from any other screen (and so not obvious that the setting UI did exist), so the URL to the needed screen had to be entered manually. Someone managed to find and publish that URL last year or the year before.

"EnTerr" wrote:

Case #1 is real.

OK, so at the very least, you agree this case means that automatic timed expiration or manual removal (or both) has to exist to prevent the polluted list issue, right?

"EnTerr" wrote:

Case #2 is a straw-man: SSDP with new IP will have to get lost 3 times in a row (assuming current TTL of 60 mins and renewal every 20) and even then it will "magically" fix itself on the 4th (or N+1) time.

Not quite - all it takes is to miss the SSDP broadcast twice (once per introduction to the network with a new manually entered IP in eclipse) to orphan the first IP.
Once the first IP addy is orphaned, without a default expiration for manual entry, it's toast - no "magical fix" except for DHCP re-use (or manual static assignment) of that address.

"EnTerr" wrote:

But if network conditions are really so bad that multiple datagrams get dropped - that would mean you cannot trust "radio silence" to expire IPs.

Right, hence the ability to manually enter IP addresses (that get a default timeout value) as a workaround for the rare network (or temporary situation) where that's an issue.
For those boxes that were discovered when SSDP was being received, the SSDP spec is clear that a client impl is supposed to remove the cache entry after the expiration, unless a new broadcast or M-Search query response is received (the fact that they may not be received is implicit in the selection of both UDP and multicast as part of the protocol definition).

"EnTerr" wrote:

P.S. Oh i see S/N worried you, that's real... but one can collect that from UPnP descriptor at http://IP:8060/ 8-)

Excellent point - completely forgot that that info is available from the ECP/REST endpoint on the box.
BTW, is that documented somewhere? I remember accidentally discovering this a while back, but I don't see it documented in the current ECP guide.

"EnTerr" wrote:

It seems clear - you really, really, really like the way you expire the IPs in your plugin...

No - but since the plugin is using SSDP to simplify discovery, it's following the IETF spec (which says a client implementation should remove devices from it's cache when the expiration time is reached).
As I've said, the ability to explicitly remove IP addresses that were manually entered is an enhancement request I'd gladly file for anyone using the plugin that thinks they need it. So far, no one has.
And BTW, the decision of what to add or change in the plugin is not mine - my contact at Roku makes those decisions, and he tends to err on the side of not allowing changes, however minor, unless there's a clear and notable benefit for the majority of plugin users.

"EnTerr" wrote:

And there are probably what - about hundred people? (3-digit number anyway) - using said plugin. The chance of encountering the issue is low and those are people you can ask to play with router config or replace it. It's manageable. However, if you have tens of thousands of users to your app, that's not the right approach - and if you have over a MILLION users (which is the case with RokuCo mobile apps), that'd be absurd. Oh, and the level of sophistication of those users is far removed from a developer's, i can share as much.

Yep, agreed - they are a notably different set of constraints given the size and technical expertise of the audience.
Although I'd argue that an end-user environment where UPnp isn't working is a problem that needs to be solved, not punted (by the end-user or by their equipment provider), and not just for the sake of Roku - there are plenty of other consumer devices and software that rely on that protocol combo, and it's not going away anytime soon. A multicast/SSDP/UPnp problem will likely rear it's ugly head for those users, in other contexts, until fixed.

So far, this aspect of the plugin implementation has only been a minor irritant for a very small number of devs that have a latent networking problem.

Nevertheless, if it were solely up to me and I felt free to ignore the cost/benefit ratio...
I'd tighten up this aspect of the implementation a bit by adding: the aforementioned manual removal capability, user pref for the timeout for manually entered items (including infinite timeout), and the ECP query you mentioned above, just to cover all the bases.

Cheers

[gonzotek]

"malloys" wrote:

Excellent point - completely forgot that that info is available from the ECP/REST endpoint on the box.
BTW, is that documented somewhere? I remember accidentally discovering this a while back, but I don't see it documented in the current ECP guide.

http://sdkdocs.roku.com/display/sdkdoc/ ... ryProtocol
The serial is in the USN header(documented above, I know you're aware of this, just including for future readers), as well as the returned XML. The UPnP docs describe the XML, see section 2.3 here: http://upnp.org/specs/arch/UPnP-arch-De ... e-v1.1.pdf

[malloys]

"gonzotek" wrote:

"malloys" wrote:

Excellent point - completely forgot that that info is available from the ECP/REST endpoint on the box.
BTW, is that documented somewhere? I remember accidentally discovering this a while back, but I don't see it documented in the current ECP guide.

http://sdkdocs.roku.com/display/sdkdoc/ ... ryProtocol
The serial is in the USN header(documented above, I know you're aware of this, just including for future readers), as well as the returned XML. The UPnP docs describe the XML, see section 2.3 here: http://upnp.org/specs/arch/UPnP-arch-De ... e-v1.1.pdf

Thanks for the links gonzotek.
To round it out for the reader:
What's implied is that the UPnP device description endpoint is at the URL pattern: "http:<ip_address>:8060/"
So with a known IP address (however you get it - SSDP based discovery or not), you should be able to get the UPnP device description (XML in the body of the response) of any Roku box.
That port or URL pattern in general is not required by the UPnP spec, so it's subject to change by Roku.

Within the returned UPnP device description is the device S/N value.
It should be noted that the UPnP spec states that S/N is recommended but not required, so Roku could in theory remove
the S/N value from the device description XML in the future and still be UPnP compliant.

And finally, with all the talk of device S/N and UPnP/SSDP, I just realized that I've been sloppy in talking about a key implementation detail -
Strictly speaking, as per SSDP spec - the plugin is using the device's advertised USN value, not the S/N, to do unique identification of a device and any cache expiration.
However, according the the ECP guide... for Roku boxes, the S/N is embedded in the USN (again, this was a Roku impl choice and not required by the SSDP spec, so in theory this could change in the future)

Cheers