[BUG] PIP not working when port not specified in server configuration

[splitsec2]

Describe the bug
When I tried to configure camera PIP, I was getting a broken url.

I had manually entered my server configuration (as the QR code was not responding), and had left off the :8123 port number as the docs implied that was ok. But the broken URL was saying that :80 wasn't available, so I added :8123 onto my server configuration and that solved the issue.

All other controls work fine. It is only the video PIP that doesn’t work.
A clear and concise description of what the bug is.

To Reproduce
Manually configure a server without the port number. Add a camera to a quickbar, try to view. Note broken link.

The cameras are a mjpeg from the Kuna HACS integration. It is proxying the stream from the cloud as the cameras don’t have a local RSTP stream.

Fix: change server configuration to include port :8123

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots/Video
Note the url for the server without port

Note the url for the server with port

Environment (please complete the following information):

• Android TV Device: Nvidia Shield
• Android Version: Latest update
• QuickBars Version: 1.3.3
• Home Assistant Version: 2026.3.1

[JiwaniZakir]

I think I see what's going on here. Going to put together a fix.

[Trooped]

I think I see what's going on here. Going to put together a fix.

Hey man, I'm not sure what you think is going on here, I'm asking OP to elaborate further, but I'd love if you could also elaborate on what you think before trying to implement a fix.

@splitsec2 please edit the original post, and add more information:

1. After you connected to HA (and not specified a port), did the other entities work (you could add and control them)? If yes - that is VERY strange. HA should only provide WS control over a specific port, afaik.
2. What kind of camera viewing method are we talking about? An MJPEG entity? An RTSP script?

In general - the docs says it's fine to not include a port if your port is a standard one, since it tries all the common ports and tries to ping to the HA server through WS, and if it gets a response - it sets it as the correct port (it's usually :8123). What seems to be unusual here is just what you described - your HA instance somehow serves WS over 2 different ports (80 and 8123), which is highly unusual.

[splitsec2]

I don’t know how to tell what port it is using for the light controls, but it works with/without specifying the port. But the cameras only work if I specify the port. And I agree it is very odd, but I feel like the entities are hitting :8123 but the cameras are somehow defaulting to :80 which clearly isn’t responding.

Hope the photos help, let me know if you need me to do any other diagnostics.

[Trooped]

I don’t know how to tell what port it is using for the light controls, but it works with/without specifying the port. But the cameras only work if I specify the port. And I agree it is very odd, but I feel like the entities are hitting :8123 but the cameras are somehow defaulting to :80 which clearly isn’t responding.

Hope the photos help, let me know if you need me to do any other diagnostics.

Okay then, in this function in app/src/main/java/dev/trooped/tvquickbars/ha/HomeAssistantClient.kt:

private fun expandWithPortFallbacks(baseCandidates: List<String>): List<String> {
      val out = LinkedHashSet<String>() // preserves insertion order, dedupes
      for (c in baseCandidates) {
          out += c
          val httpUrl = c.toHttpUrlOrNull() ?: continue
          when (httpUrl.scheme) {
              "https" -> {
                  // Try explicit :443 as well (covers reverse proxies)
                  out += httpUrl.newBuilder().port(443).build().toString()
              }
              "http" -> {
                  // Typical HA port + plain HTTP default
                  out += httpUrl.newBuilder().port(8123).build().toString()
                  out += httpUrl.newBuilder().port(80).build().toString()
              }
          }
      }
      return out.toList()
  }

It seems that I configured port 80 as one of the default http (local) ports, even though I'm now not sure it's actually one of them. It's probably due to some user feedback I received a long time ago.
Now, the weird thing is, your HA is served on port 8123 (the default port), and with how the flow works - it should first try this port (8123), and only if it times out it'll try port 80. So either it's a bug where for some reason it tries out 80 first, or - for some reason, your HA rejects this connection there.

Either way, I suspect the fix is fairly simple -

1. Remove this line: out += httpUrl.newBuilder().port(80).build().toString().
2. Update the docs, such that it recommends to always specify a port, maybe with a short explanation on how to find the correct port.

@JiwaniZakir I see you forked the repo, what do you think?