WebRTC Live View - Settings work in stand alone card, but nothing works in Frigate's embedded card.

[bblicke1]

Checklist:

• [X] I updated to the latest version available
• [X] I cleared the cache of my browser

Release with the issue: 4.0.0

Last working release (if known):

Browser and Operating System: Brave Browser / Win11

Description of problem: Embedded Live View Provider (WebRTC) not working. I have a Frigate card right next to a WebRTC Camera Card... I input the exact same information into both cards and yet the Frigate card just will not work. I've spent hours trying to figure it out 🤦🏼‍♂️

Javascript errors shown in the web inspector (if applicable):

Additional information:

Card diagnostics. Please review for confidential information prior to sharing { "ha_version": "2023.1.3", "card_version": "4.0.0", "browser": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36", "date": "2023-01-13T00:43:40.082Z", "frigate_version": { "41600e7e9ca1a4441becedc171717ecd": "4.0.0-beta2/0.10.1-83481af" }, "lang": "en", "git": { "build_version": "4.0.0-HEAD+ge5a0bf4", "build_date": "Fri, 23 Sep 2022 00:27:16 GMT", "commit_date": "Thu, 22 Sep 2022 16:53:03 -0700" }, "config": { "type": "custom:frigate-card", "cameras": [ { "camera_entity": "camera.living_room_frigate", "live_provider": "webrtc-card", "webrtc_card": { "url": "Living-Room" } } ] } }

NOTE -- According to WebRTC Card documentation, you can use the name of the camera used in the config and it does work in the WebRTC Camera Card. I've tried using the URL that frigate itself is pointing at for the feed which is itself coming from go2rtc.

[bblicke1]

I should note "used in the config" is referring to the streams configured in the go2rtc config file.

[dermotduffy]

Can you paste the config of the WebRTC card that does work?

[trooster]

I believe I have the same issues since yesterday. I have no idea if something was updated, but it worked before, and the frigate card now says "Failed to connect WebRTC stream: Invalid non-TCP candidate" The Frigate web interface itself shows all the streams without issues. Also in the go2rtc web interface I can stream the cameras without issues. go2rtc: 0.1-rc.8 frigate: blakeblackshear/frigate:stable-amd64 frigate-card: v4.0.0

[dermotduffy]

@trooster That is an error message from the underlying WebRTC card -- the frigate card itself does not have such a message. Try creating a "pure" WebRTC card (separate from the frigate card) with a matching configuration and you should (?) see the same message -- i.e. this is an issue on the WebRTC card side (or your configuration of it).

[felipecrs]

This is a known issue from go2rtc rc8, check the go2rtc issues... Pretty sure it's fixed already but not released yet.

[trooster]

@dermotduffy @felipecrs Thank you both for your response and sending me in the right direction. With all the components involved it is sometimes difficult to figure out who to blame :)

update: yes it is indeed with webrtc, when you use 'candidates' in the config it defaults to UDP, where before this was TCP. I removed the candidates line with the external IP for now and everything works fine!

[bblicke1]

Can you paste the config of the WebRTC card that does work?

Are you looking for the couple lines from the YAML?

cards:

• type: custom:webrtc-camera url: Nursery

Can't get the YAML to paste properly, so syntax etc is obviously inaccurate.

[felipecrs]

@bblicke1 you should upgrade go2rtc, or wait for the release of Frigate/WebRTC that contains the new go2rtc version. Or downgrade.

[bblicke1]

@felipecrs I just updated go2rtc and WebRTC Camera and the issue persists.

cards:
  - type: custom:webrtc-camera
    url: Nursery
  - type: custom:frigate-card
    cameras:
      - webrtc_card:
          url: Nursery

Between these 2 cards, the first one works and the 2nd one does not.

[felipecrs]

Got it. Interesting, there may be some incompatibility between the Frigate Card and the WebRTC card v3.

[dermotduffy]

Thank you. Yes, this should work seamlessly. I have not tested the new WebRTC card, so perhaps there is some new incompatibility. I'm in the middle of major card rework right now that I have to finish. Leaving this bug open to investigate once I have time. If someone else wanted to have a shot, PRs most welcome :-)

[bblicke1]

Thanks! Appreciate the effort.

[felipecrs]

I think I found the culprit of this one: Show still image while the live stream is loading

It's never stopping showing the still images. See:

https://user-images.githubusercontent.com/29582865/214051633-3b4a8fff-a1f7-4ba7-9d01-2be611a63442.mp4

For now, disabling it works around the issue.

[bblicke1]

@felipecrs Unfortunately, this doesn't address the issue that I was having. The issue is that entering anything in the "WebRTC Card Camera URL" field in the "WebRTC Card Options" returns an error and never produces any feed.

[Morphy99]

I'm having possibly the same issue but with slighlty different beahviour. I'm entering the URL and although it takes a few seconds the stream does start but with the image cropped horizontally to 3/4 size. After about 5 seconds it stops and the stream goes blank but it still displays RTC in the top right. It also tries to play MSE first despite it being set to mode: webrtc

I noticed this log in the console in chrome, not sure if relevant: Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "action-handler-frigate-card" has already been used with this registry

I'm using Frigate 0.12-beta5 and Card v4.0.0-beta3

Card config as follows:

type: custom:frigate-card
cameras:
  - camera_entity: camera.front
    live_provider: webrtc-card
    webrtc_card:
      url: rtsp://192.168.xxx.xxx:8554/front_low
      mode: webrtc
  - camera_entity: camera.front_door
  - camera_entity: camera.back_garden
  - camera_entity: camera.back_patio
live:
  auto_play: all
  show_image_during_load: false
  controls:
    next_previous:
      style: none
    thumbnails:
      mode: none
  layout:
    fit: cover
view:
  default: live
  camera_select: live
  scan:
    enabled: true

[felipecrs]

Your WebRTC integration needs to be connected with the go2rtc. It should automatically find the URL on setting up the WebRTC integration, even if your go2rtc is the one from Frigate 0.12.

In the WebRTC card URL option, you only need to set the camera name. Don't put any RTSP link, just the camera name that match the one set in the go2rtc stream config.

[felipecrs]

Also, options other than entity and url needs to be set under live, something like:

live:
  webrtc_card:
    mode: webrtc

[Morphy99]

Your WebRTC integration needs to be connected with the go2rtc. It should automatically find the URL on setting up the WebRTC integration, even if your go2rtc is the one from Frigate 0.12.

I did this already, I removed and reinstalled the integration after updating to the beta5 Frigate. The WebRTC Camera card plays fine.

In the WebRTC card URL option, you only need to set the camera name. Don't put any RTSP link, just the camera name that match the one set in the go2rtc stream config.

Ok thanks I've done that but still getting the same behaviour.

[felipecrs]

This works for me:

type: custom:frigate-card
cameras:
  - camera_entity: camera.rua
    live_provider: webrtc-card
    webrtc_card:
      url: rua
live:
  show_image_during_load: false
  webrtc_card:
    muted: true
    ui: true
    mode: webrtc
performance:
  profile: low

https://user-images.githubusercontent.com/29582865/214420373-e72b95a0-dafe-48ec-a0e9-c4957ce876a4.mp4

[Morphy99]

Nope, still does the same on mine.

[felipecrs]

Hm... I'm running the card from the release-4.1.0 branch. Maybe that's the only difference between you and me.

[Morphy99]

Where'd you get that? I can only see 4.0.0. beta3 in HACS?

[felipecrs]

I'd have to build and install it manually.

[NickM-27]

This works for me:

type: custom:frigate-card
cameras:
  - camera_entity: camera.rua
    live_provider: webrtc-card
    webrtc_card:
      url: rua
live:
  show_image_during_load: false
  webrtc_card:
    muted: true
    ui: true
    mode: webrtc
performance:
  profile: low

Same here

[bblicke1]

Using

This works for me:

type: custom:frigate-card
cameras:
  - camera_entity: camera.rua
    live_provider: webrtc-card
    webrtc_card:
      url: rua
live:
  show_image_during_load: false
  webrtc_card:
    muted: true
    ui: true
    mode: webrtc
performance:
  profile: low

Same here

Using this worked for me as well. I started stripping out settings to see if one of them was perhaps breaking things and as it turns out "show_image_during_load" being "true" or removed entirely will cause the card not to work. Using the UI, I was able to get everything to work by simply toggling it off.

[felipecrs]

• There we go: https://github.com/dermotduffy/frigate-hass-card/issues/923

[bblicke1]

I will add, however, that this behavior is different than I originally experienced. Where first the card would be unable to find the WebRTC feed and throw an error, it now just won't show due to that "image during load" being enabled. So it does seem like the first problem has been resolved and now #923 is all that remains in my case.

[bagobones]

Managed to get the Webrtc Card integration working due to the examples in this thread.

With frigate containing go2rtc moving forward it would be nice if this config could be less redundant (defending the entity and the url) for the "frigate hass card" going forward maybe triggered off the mode?

[NickM-27]

Managed to get the Webrtc Card integration working due to the examples in this thread.

With frigate containing go2rtc moving forward it would be nice if this config could be less redundant (defending the entity and the url) for the "frigate hass card" going forward maybe triggered off the mode?

In the future it may not be necessary to use the embedded WebRTC card if the frigate card supports MSE / WebRTC directly as the frigate frontend does.

[dermotduffy]

In the future it may not be necessary to use the embedded WebRTC card if the frigate card supports MSE / WebRTC directly as the frigate frontend does.

This is now implemented & merged and will be in the next build.

I don't think there's anything unique in this bug that wasn't fixed elsewhere, so closing this out.