Detects but does not connect to any of my chromecast devices

[flintstones-fred]

Today I decided to migrate from SponsorBlockCast to CastSponsorSkip and I can't get anything to work. Help please. Here is the docker-compose file I am using (stack in portainer)

version: "3.9"

services:
  app:
    image: ghcr.io/gabe565/castsponsorskip
    environment:
      # Set the container timezone
      # See identifier list at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
      TZ: America/Chicago
      # CSS_PAUSED_INTERVAL:
      # CSS_PLAYING_INTERVAL:
      # CSS_CATEGORIES:
      # CSS_YOUTUBE_API_KEY:
      # CSS_MUTE_ADS:
    network_mode: host
    restart: always

But, when I deploy the container, I get the following errors:

2023/10/10 17:30:56 INFO CastSponsorSkip v0.5.1 (73f3950)
2023/10/10 17:30:57 INFO Searching for devices...
2023/10/10 17:31:47 ERROR Failed to connect to device. device="Media Room TV" error="unable to connect to chromecast at '192.168.36.11:8009': dial tcp 192.168.36.11:8009: i/o timeout"
2023/10/10 17:31:47 ERROR Failed to connect to device. device="Entrance Display" error="unable to connect to chromecast at '192.168.36.105:8009': dial tcp 192.168.36.105:8009: i/o timeout"
2023/10/10 17:31:54 ERROR Failed to connect to device. device="Kitchen Display" error="device not found: "
2023/10/10 17:36:50 ERROR Failed to connect to device. device="Media Room TV" error="unable to connect to chromecast at '192.168.36.11:8009': dial tcp 192.168.36.11:8009: i/o timeout"
2023/10/10 17:36:55 ERROR Failed to connect to device. device="Entrance Display" error="device not found: "
2023/10/10 17:41:55 ERROR Failed to connect to device. device="Media Room TV" error="device not found: "

What is happening here? I do have all my chromecasts on a different VLAN (192.168.36....). But I am running a avahi on my pfsense box which is supposed to enable the discovery. Also as I mentioned, this is working just fine if I deploy SponsorBlock Cast. Are there any fundamental differences in how the networks are handled?

[gabe565]

Hi! After discovering a device, CastSponsorSkip will connect to its API to control the device. My devices all use port 8009 for this (and from the log, it looks like yours do too). Can you make sure communication from CastSponsorSkip to each device at 8009/tcp is allowed?

[flintstones-fred]

Hi! After discovering a device, CastSponsorSkip will connect to its API to control the device. My devices all use port 8009 for this (and from the log, it looks like yours do too). Can you make sure communication from CastSponsorSkip to each device at 8009/tcp is allowed?

I believe the communication is already allowed. The CastSponsorSkip is hosted on my main network which has unrestricted access to all other VLANs (including the IOT VLAN that the Chromecasts are part of. Is there a way to generate more debug information about what may be causing this failure?

[gabe565]

There's an env that lets you increase the log level (CSS_LOG_LEVEL=debug), but I don't think it will help here. CastSponsorSkip is trying to connect to the devices and is getting an i/o timeout, which just means CastSponsorSkip tried to access the device and didn't get a response, causing the request to eventually timeout.

[gabe565]

Are the IPs listed in the logs (192.168.36.105 and 192.168.36.11) the correct IPs for your devices?

Do you have multiple network interfaces? If so, you could try to set the proper interface with the CSS_NETWORK_INTERFACE env

[flintstones-fred]

Are the IPs listed in the logs (192.168.36.105 and 192.168.36.11) the correct IPs for your devices?

Do you have multiple network interfaces? If so, you could try to set the proper interface with the CSS_NETWORK_INTERFACE env

I confirmed that those are indeed the IPs of the Chromecast devices. I also attempted to specify the network interface (ens18 in my case), and that didn't help either

[flintstones-fred]

There's an env that lets you increase the log level (CSS_LOG_LEVEL=debug), but I don't think it will help here. CastSponsorSkip is trying to connect to the devices and is getting an i/o timeout, which just means CastSponsorSkip tried to access the device and didn't get a response, causing the request to eventually timeout.

Correct. I enabled this. And I get to see that it discovered my nest minis and ignored them as they don't support video. Then kept failing to make connection to the three video enabled devices. Specifically after a bunch of time out errors, I get this (just pasting an example for one device, all three show the same thing):

time=2023-10-12T21:28:01.600-05:00 level=DEBUG msg="Panic during close" device="Media Room TV" error="runtime error: invalid memory address or nil pointer dereference" stack="goroutine 9 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:24 +0x5e\ngithub.com/gabe565/castsponsorskip/internal/device.(*Device).Close.func2()\n\tgithub.com/gabe565/castsponsorskip/internal/device/watch.go:115 +0x48\npanic({0xb7cbe0?, 0x127c480?})\n\truntime/panic.go:914 +0x21f\ncrypto/tls.(*Conn).Close(0xc000334970?)\n\tcrypto/tls/conn.go:1403 +0x17\ngithub.com/vishen/go-chromecast/cast.(*Connection).Close(0x0?)\n\tgithub.com/vishen/go-chromecast@v0.3.2-0.20230828160317-e92af477dd65/cast/connection.go:80 +0x70\ngithub.com/vishen/go-chromecast/application.(*Application).Close(0x0?, 0x0?)\n\tgithub.com/vishen/go-chromecast@v0.3.2-0.20230828160317-e92af477dd65/application/application.go:430 +0xef\ngithub.com/gabe565/castsponsorskip/internal/device.(*Device).Close(0xc00033a8c0)\n\tgithub.com/gabe565/castsponsorskip/internal/device/watch.go:119 +0xc8\ngithub.com/gabe565/castsponsorskip/cmd.run.func1.1()\n\tgithub.com/gabe565/castsponsorskip/cmd/cmd.go:104 +0xd3\ncreated by github.com/gabe565/castsponsorskip/cmd.run.func1 in goroutine 19\n\tgithub.com/gabe565/castsponsorskip/cmd/cmd.go:101 +0x50\n"

[flintstones-fred]

@gabe565 I wanted to provide an update. So far, I was trying to do this on portainer (on a dedicated VM, where I am hosting most of my self hosted services). I decided to give this a go on my linux laptop by simply writing up the same docker-compose in a file and spinning up the container (I did have to use 3.3 instead of the 3.9 you have in the example compose file). Guess what, at least its making the connection. So, clearly something to do with how the handling is being done inside portainer or the VM. I am not a docker expert to figure this out. But my attempt is going to be spinning up a LXC on my proxmox server and trying to run castsponsorskip from there. I will report back on if ads are actually being blocked or not.

[gabe565]

@flintstones-fred That panic is fine. It could occasionally happen if the initial connection to a device failed, but I had a recover function set up so it couldn't have caused any issues. It has been fixed in v0.5.2

I'm glad it's finally able to connect! I wonder why it couldn't from within the container... One more troubleshooting step you could try would be to try to connect to one of the device API endpoints directly. You could exec into the container and run wget -O- 192.168.36.105:8009. This will return an error, but it should be wget: error getting response instead of something else like connection refused or connection timeout.

[gabe565]

I haven't been able to replicate this, so I will close this for now. If you still see this behavior or need troubleshooting assistance, feel free to reopen!