Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roku Search Feature Broken - Potential Fix #105827

Closed
PRProd opened this issue Dec 15, 2023 · 8 comments
Closed

Roku Search Feature Broken - Potential Fix #105827

PRProd opened this issue Dec 15, 2023 · 8 comments

Comments

@PRProd
Copy link

PRProd commented Dec 15, 2023

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:

        request_params = {
            "keyword": keyword,
        }

Proposed:

        request_params = {
            keyword: keyword,
        }

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. 😄

@home-assistant
Copy link

Hey there @ctalkington, mind taking a look at this issue as it has been labeled with an integration (roku) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of roku can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign roku Removes the current integration label and assignees on the issue, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


roku documentation
roku source
(message by IssueLinks)

@ctalkington
Copy link
Contributor

ctalkington commented Jan 30, 2024

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.

@PRProd
Copy link
Author

PRProd commented Jan 30, 2024

Thank you so much @ctalkington!

@ctalkington
Copy link
Contributor

this is still on my radar

@PRProd
Copy link
Author

PRProd commented Mar 13, 2024

@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:

image

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:

curl -d '' http://192.168.107.214:8060/search/browse?keyword=pandora

image


Example 2:

curl -d '' http://192.168.107.214:8060/search/browse?pandora=

image
image


Example 3:

curl -d '' http://192.168.107.214:8060/search/browse?the+office=

image

versus

image

@ctalkington
Copy link
Contributor

@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...

@PRProd
Copy link
Author

PRProd commented Mar 20, 2024

The keypress search command

curl -d '' http://192.168.107.214:8060/keypress/search

On my Roku model, it just brings up the voice menu. Perhaps the behavior is different if you don't have a voice remote?
image

If you'd like to close this issue, that's OK. I don't think there is anything that can be done here.

@issue-triage-workflows
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@issue-triage-workflows issue-triage-workflows bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 26, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Jul 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants