No Results When Searching for Devices (Roku) about ytcast HOT 12 CLOSED

glad to hear the -pair workaround works!

from ytcast.

I'll keep messing with the discovery options and investigating my network setup.

from ytcast.

Update:

Discoverability appears to be working. I built the project on 72c271afa89a7b9a081a878d91b055053306095b. I wonder if my router (Asus RT-AC86U) was the issue as it has received a firmware upgrade. Now all devices on my network (2 Roku & 1 Chromecast) are discoverable.

I still run pi-hole + DHCP.

from ytcast.

thank you for the update!

Now all devices on my network (2 Roku & 1 Chromecast) are discoverable.

that's really nice to hear, does casting works on all devices too? if yes i think we can close this issue!

from ytcast.

thank you for reporting this!

unfortunately I don't see anything strange in the log, I was expecting to see some
parse error from M-SEARCH responses but they are not there, so it seems that
ytcast and your roku devices don't "talk" at all to each other.

are you able to find (and connect to) your devices with the "play on tv" button
on youtube.com using chrome or with the youtube smartphone app? this would
confirm a problem in my DIAL implementation.

from ytcast.

are you able to find (and connect to) your devices with the "play on tv" button on youtube.com using chrome or with the youtube smartphone app? this would confirm a problem in my DIAL implementation.

Yes, via my smartphone app (youtube vanced and youtube) I can cast videos to both Roku devices. Using Chromium, I can only see Chromecast devices.

from ytcast.

Using Chromium, I can only see Chromecast devices.

that's interesting because Chromium works fine with my devices...

anyway, I was playing around with "RokuDIALSDK", they provide some sample code to get you up and running with DIAL integration between your app and Roku devices.

I didn't see any big difference in their example implementation compared to mine, there is only this USER-AGENT: RokuCastClient header they add in the SSDP M-SEARCH request that ytcast doesn't send (the spec says it's optional).

(and they forget to send a final \r\n\r\n in the request eheh I think that's a bug in their code).

I've adapted their Android app example removing all the Android stuff and making it a self-contained Java program to test device discovery. you can find it here.

can you run it and see if it can find your devices?

for example I get the following output:

$ wget https://gist.githubusercontent.com/MarcoLucidi01/5b50686637bf09b0a9fa48e55f587c56/raw/b976249ee8365b198d054e4ea19d69bb79513d5e/RokuDialDiscoverySample.java
$ javac RokuDialDiscoverySample.java
$ java RokuDialDiscoverySample
*** sending ROKU m-search req
*** m-search resp HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
LOCATION: http://192.168.1.89:12345/upnp/dev/foo-bar-baz/desc
EXT: 
ST: urn:dial-multiscreen-org:service:dial:1
USN: uuid:foo-bar-baz::urn:dial-multiscreen-org:service:dial:1
WAKEUP: MAC=ab:cd:ef:gh:ij:kl;Timeout=25
SERVER: UPnP/1.0
*** upnp location http://192.168.1.89:12345/upnp/dev/foo-bar-baz/desc
<?xml version="1.0" encoding="UTF-8"?><root xmlns="urn:schemas-upnp-org:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <device>
    <deviceType>urn:dial-multiscreen-org:device:dial:1</deviceType>
    <friendlyName>FireTVStick di Marco</friendlyName>
    <manufacturer>Amazon</manufacturer>
    <modelName>ABCD</modelName>
    <UDN>uuid:foo-bar-baz</UDN>
    <serviceList>
      <service>
      </service>
    </serviceList>
  </device>
</root>

*** app url http://192.168.1.89:8888/apps/
*** sending FIXED m-search req
*** m-search resp HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
LOCATION: http://192.168.1.89:12345/upnp/dev/foo-bar-baz/desc
EXT: 
ST: urn:dial-multiscreen-org:service:dial:1
USN: uuid:foo-bar-baz::urn:dial-multiscreen-org:service:dial:1
WAKEUP: MAC=ab:cd:ef:gh:ij:kl;Timeout=25
SERVER: UPnP/1.0
*** upnp location http://192.168.1.89:12345/upnp/dev/foo-bar-baz/desc
<?xml version="1.0" encoding="UTF-8"?><root xmlns="urn:schemas-upnp-org:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <device>
    <deviceType>urn:dial-multiscreen-org:device:dial:1</deviceType>
    <friendlyName>FireTVStick di Marco</friendlyName>
    <manufacturer>Amazon</manufacturer>
    <modelName>ABCD</modelName>
    <UDN>uuid:foo-bar-baz</UDN>
    <serviceList>
      <service>
      </service>
    </serviceList>
  </device>
</root>

*** app url http://192.168.1.89:8888/apps/
*** app info http://192.168.1.89:8888/apps/YouTube
<?xml version="1.0" encoding="UTF-8"?><service xmlns="urn:dial-multiscreen-org:schemas:dial" dialVer="2.2.1">
  <name>YouTube</name>
  <options allowStop="true"/>
  <state>stopped</state>
</service>

from ytcast.

I ran that sample and get no results, unfortunately.

$ java RokuDialDiscoverySample
*** sending ROKU m-search req
*** sending FIXED m-search req
*** no device found!

Some more info about my setup:

Rokus Tested with:
Roku 3810X (Streaming stick+)
Roku 4800X (Ultra)

Systems tested with:
Nothing crazy, a desktop (wired) and laptop (both wired and wireless) running Fedora 35 with no unusual configuration.

Network:
router: Asus RT-AC86U (no DHCP)
pi-hole running DHCP. The desktop and laptop both have assigned IPs, while the Rokus are dynamic.

from ytcast.

that's really unfortunate!

could it be the pi-hole interfering with SSDP/UPnP someway? or maybe some firewall rule?

can you check the pi-hole or router logs looking for SSDP traffic? (i.e. udp 239.255.255.250 port 1900)

from ytcast.

I was reading on the roku subreddit about youtube app casting problems, I'm
sure you'll already tried this, but I found these 2 guys who solved a similar
issue 4 months ago by simply updating their roku!

as workaround for devices that don't support the DIAL protocol, I added a
-pair option to ytcast which allows to manually pair with the app using a
code and skipping the discovery process altogether.

you can find the YouTube on TV app's pairing code in Settings > Link with TV code
e.g.:

$ ytcast -pair 123456789101
8a59f138 unknown         "YouTube on TV"
$ ytcast -d 8a59 https://www.youtube.com/watch?v=dQw4w9WgXcQ

the bad part is that this method adds more manual steps i.e. ytcast won't be
able to automatically wake-on-lan the TV and start the YouTube app, and it won't
automatically "re-pair" every time the screenId changes (I don't know how
often that happen), but you know, it's better than nothing.

the feature is already available on master so you can try it out, I'll do
a proper release soon, once I finish updating the readme.

from ytcast.

Apologies for the late response, life was calling but I'm back!

could it be the pi-hole interfering with SSDP/UPnP someway? or maybe some firewall rule?

I didn't think so but checked and didn't find anything in pihole or router logs

sure you'll already tried this, but I found these 2 guys who solved a similar

Yep, I keep my devices up-to-date.

as workaround for devices that don't support the DIAL protocol, I added a
-pair option to ytcast which allows to manually pair with the app using a
code and skipping the discovery process altogether.

I got the latest from master, 72c271afa89a7b9a081a878d91b055053306095b, and this actually worked on one of my devices (roku stick). I'll try with the Ultra when the TV is free.

from ytcast.

sounds great, happy hacking!

from ytcast.