Roku Search Feature Broken - Potential Fix #105827
Comments
|
Hey there @ctalkington, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) roku documentation |
|
It does seem others observed such behavior. I don't have any devices without OS 12. Maybe an extra param would support this without back-compat issues. I'll try to look into it this week. |
|
Thank you so much @ctalkington! |
|
this is still on my radar |
|
@ctalkington ~ Great! Obviously this is all up to you, but reading the link you posted makes me wonder if the search endpoint should actually be removed from rokuecp. The solutions I suggested might not be doing what they used to do. I don't know any different since this is the only way I've seen it behave. As I dig back into it, I also want to point out how this API endpoint seems to differ greatly from the experience that a user has when using the built-in search menu. What I can do is provide you with some real-world examples of what I'm seeing on my end: My Device:
More system details:HTTP/1.1 200 OK
Server: Roku/12.5.5 UPnP/1.0 Roku/12.5.5
Content-Length: 1301
Cache-Control: no-cache
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:roku-com:device:player:1-0</deviceType>
<friendlyName>Roku Ultra</friendlyName>
<manufacturer>Roku</manufacturer>
<manufacturerURL>http://www.roku.com/</manufacturerURL>
<modelDescription>Roku Streaming Player Network Media</modelDescription>
<modelName>4802RW</modelName>
<modelNumber>4802RW</modelNumber>
<modelURL>http://www.roku.com/</modelURL>
<serialNumber>X01000GNMXJH</serialNumber>
<UDN>uuid:28001000-0000-1000-8000-84eaedaf9cb1</UDN>
<iconList>
<icon>
<mimetype>image/png</mimetype>
<width>360</width>
<height>219</height>
<depth>8</depth>
<url>device-image.png</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:roku-com:service:ecp:1</serviceType>
<serviceId>urn:roku-com:serviceId:ecp1-0</serviceId>
<controlURL></controlURL>
<eventSubURL></eventSubURL>
<SCPDURL>ecp_SCPD.xml</SCPDURL>
</service>
<service>
<serviceType>urn:dial-multiscreen-org:service:dial:1</serviceType>
<serviceId>urn:dial-multiscreen-org:serviceId:dial1-0</serviceId>
<controlURL></controlURL>
<eventSubURL></eventSubURL>
<SCPDURL>dial_SCPD.xml</SCPDURL>
</service>
</serviceList>
</device>
</root>Example 1: |
|
@PRProd I am wondering the value of the search functionality as well since Roku has replied in the link above saying they basically nerfed firmware builtin search and can't be bothered to make it integrate with the new search experience. If someone wanted they could combine key press (search + Lit_keyword) to get similar behavior to the ecp search which BTW Search keypress still triggers the legacy search... |
|
The keypress search command On my Roku model, it just brings up the voice menu. Perhaps the behavior is different if you don't have a voice remote? If you'd like to close this issue, that's OK. I don't think there is anything that can be done here. |
The problem
As mentioned in #102024, the Roku Search feature does not work against the latest API change.
I have found a way to make this work through curl, but I'm unsure if my method breaks any backwards compatibility for older Roku models, hence the lack of a PR.
What version of Home Assistant Core has the issue?
core-2023.12.3
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Roku
Link to integration documentation on our website
https://www.home-assistant.io/integrations/roku
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
What used to work, and what works now
Found here in rokuecp it appears that the integration is sending a POST request like this:
http://{ IP-ADDRESS }:8060/search/browse?keyword={ USER SUPPLIED KEYWORD }Using this method now, a search window is opened and the literal keyword "keyword" is automatically searched, and the user input is unused. However, It looks like this version of the search feature will actually respond as expected to a request like this instead:
http://{ IP-ADDRESS }:8060/search/browse?{ USER SUPPLIED KEYWORD }=The POSTed data seems to use the key and discard the value, so the trailing = is actually required.
Proposed Change for Roku Integration / rokuecp
Assuming that backwards compatibility is not an issue, I propose changing these lines:
Now:
Proposed:
I will love you forever
If this issue can have resolution as well as #105776, my HACS card HA-Firemote will be extremely useful as I launch the new Roku Integration in the near future. I'd love to have @ctalkington join us as a beta tester too, if time permits. 😄
The text was updated successfully, but these errors were encountered: