search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
70.53k stars 29.46k forks source link

Stream task exception was never retrieved #103403

Closed robloh closed 5 months ago

robloh commented 9 months ago

The problem

Adding generic rtsp camera generates a broken preview (before completion of the add integration) and these errors are logged:

Logger: homeassistant Source: helpers/entity.py:739 First occurred: 12:21:29 PM (18 occurrences) Last logged: 12:46:53 PM

Error doing job: Exception in callback Stream._async_update_state(True) Error doing job: Exception in callback Stream._async_update_state(False) Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run self._context.run(self._callback, *self._args) File "/usr/src/homeassistant/homeassistant/components/stream/init.py", line 368, in _async_update_state self._update_callback() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 739, in async_write_ha_state raise NoEntitySpecifiedError( homeassistant.exceptions.NoEntitySpecifiedError: No entity id specified for entity preview

What version of Home Assistant Core has the issue?

core-2023.11.1

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

Stream

Link to integration documentation on our website

No response

Diagnostics information

See the problem. Trying to add a generic rtsp camera (TCP) with this url: rtsp://user:pwd@172.30.1.111:8554/360p?mp4 for a Wyze v3 camera that's running https://github.com/gtxaspec/wz_mini_hacks

The stream works fine in ffplay:

C:\Users\rob\Downloads\ffmpeg-6.0-essentials_build\bin>ffplay -loglevel verbose rtsp://user:pwd@172.30.1.111:8554/360p?mp4 ffplay version 6.0-essentials_build-www.gyan.dev Copyright (c) 2003-2023 the FFmpeg developers Initialized direct3d renderer. [tcp @ 0000017e39ecb840] Starting connection attempt to 172.30.1.111 port 8554 [tcp @ 0000017e39ecb840] Successfully connected to 172.30.1.111 port 8554 [rtsp @ 0000017e39ecb380] SDP:= 0KB vq= 0KB sq= 0B f=0/0 v=0 o=- 1 1 IN IP4 0.0.0.0 s=go2rtc/ c=IN IP4 0.0.0.0 t=0 0 m=video 0 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1 a=control:trackID=0

[rtsp @ 0000017e39ecb380] method SETUP failed: 461 Unsupported transport [rtsp @ 0000017e39ecb380] setting jitter buffer size to 00B f=0/0 [h264 @ 0000017e39ed03c0] Reinit context to 640x368, pix_fmt: yuv420p Input #0, rtsp, from 'rtsp://admin:rtsp@172.30.1.111:8554/360p?mp4': Metadata: title : go2rtc/ Duration: N/A, start: 0.049444, bitrate: N/A Stream #0:0: Video: h264 (Main), 1 reference frame, yuv420p(tv, bt709, progressive, left), 640x360 (640x368), 20 fps, 20 tbr, 90k tbn [h264 @ 0000017e447cb680] Reinit context to 640x368, pix_fmt: yuv420p [ffplay_buffer @ 0000017e4545e540] w:640 h:360 pixfmt:yuv420p tb:1/90000 fr:20/1 sar:0/1 Created 640x360 texture with SDL_PIXELFORMAT_IYUV.

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

mib1185 commented 9 months ago
davet2001 commented 9 months ago

@robloh thank you for supplying information about this problem.

You say that ffplay works, but even in your log output for ffplay I see the error message [rtsp @ 0000017e39ecb380] method SETUP failed: 461 Unsupported transport.

Could it be that ffplay is self recovering but HA is not?

I also understand that you are using custom firmware on your device.

It would be great to have a failing test case that can be more easily reproduced. Can you get this problem to occur connecting to any other streams?

Please also note that the preview during setup is currently only generated for the still image associated with a camera, I.e from a separate still url or from a still image extracted from the camera.

robloh commented 9 months ago

it looks like a separate issue to me

robloh commented 9 months ago

You say that ffplay works, but even in your log output for ffplay I see the error message [rtsp @ 0000017e39ecb380] method SETUP failed: 461 Unsupported transport.

Could it be that ffplay is self recovering but HA is not?

I did a wireshark session and it seems the camera does not like the UDP stream (hence the unsupported transport error), but ffplay then switches to TCP and that works (camera is .111 and test system is .222):

Frame 1277: 206 bytes on wire (1648 bits), 206 bytes captured (1648 bits) on interface \Device\NPF_{BD1CFAE0-F045-48E5-95A0-7F9B2DBCB16C}, id 0 Ethernet II, Src: 9a:d7:61:61:9a:55 (9a:d7:61:61:9a:55), Dst: WyzeLabs_88:07:ea (7c:78:b2:88:07:ea) Internet Protocol Version 4, Src: 172.30.1.222, Dst: 172.30.1.111 Transmission Control Protocol, Src Port: 49824, Dst Port: 8554, Seq: 207, Ack: 348, Len: 152 Real Time Streaming Protocol Request: SETUP rtsp://172.30.1.111:8554/360p?mp4/trackID=0 RTSP/1.0\r\n Transport: RTP/AVP/UDP;unicast;client_port=7552-7553 CSeq: 3\r\n User-Agent: Lavf60.16.100\r\n \r\n

Frame 1280: 101 bytes on wire (808 bits), 101 bytes captured (808 bits) on interface \Device\NPF_{BD1CFAE0-F045-48E5-95A0-7F9B2DBCB16C}, id 0 Ethernet II, Src: WyzeLabs_88:07:ea (7c:78:b2:88:07:ea), Dst: 9a:d7:61:61:9a:55 (9a:d7:61:61:9a:55) Internet Protocol Version 4, Src: 172.30.1.111, Dst: 172.30.1.222 Transmission Control Protocol, Src Port: 8554, Dst Port: 49824, Seq: 348, Ack: 359, Len: 47 Real Time Streaming Protocol Response: RTSP/1.0 461 Unsupported transport\r\n Cseq: 3\r\n \r\n

Frame 1286: 200 bytes on wire (1600 bits), 200 bytes captured (1600 bits) on interface \Device\NPF_{BD1CFAE0-F045-48E5-95A0-7F9B2DBCB16C}, id 0 Ethernet II, Src: 9a:d7:61:61:9a:55 (9a:d7:61:61:9a:55), Dst: WyzeLabs_88:07:ea (7c:78:b2:88:07:ea) Internet Protocol Version 4, Src: 172.30.1.222, Dst: 172.30.1.111 Transmission Control Protocol, Src Port: 49824, Dst Port: 8554, Seq: 359, Ack: 395, Len: 146 Real Time Streaming Protocol Request: SETUP rtsp://172.30.1.111:8554/360p?mp4/trackID=0 RTSP/1.0\r\n Transport: RTP/AVP/TCP;unicast;interleaved=0-1 CSeq: 4\r\n User-Agent: Lavf60.16.100\r\n \r\n

Frame 1287: 160 bytes on wire (1280 bits), 160 bytes captured (1280 bits) on interface \Device\NPF_{BD1CFAE0-F045-48E5-95A0-7F9B2DBCB16C}, id 0 Ethernet II, Src: WyzeLabs_88:07:ea (7c:78:b2:88:07:ea), Dst: 9a:d7:61:61:9a:55 (9a:d7:61:61:9a:55) Internet Protocol Version 4, Src: 172.30.1.111, Dst: 172.30.1.222 Transmission Control Protocol, Src Port: 8554, Dst Port: 49824, Seq: 395, Ack: 505, Len: 106 Real Time Streaming Protocol Response: RTSP/1.0 200 OK\r\n Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Cseq: 4\r\n Session: 64501734;timeout=60 \r\n

I also understand that you are using custom firmware on your device.

It would be great to have a failing test case that can be more easily reproduced. Can you get this problem to occur connecting to any other streams?

I will see if I can reproduce it with anything else now that I have some spare time coming up.

Please also note that the preview during setup is currently only generated for the still image associated with a camera, I.e from a separate still url or from a still image extracted from the camera.

From my understanding having stream enabled on HASS (which I do) it should generate a still image on demand from the stream: https://www.home-assistant.io/integrations/generic/

"If a camera only has a live stream URL and no snapshot URL, the stream integration can also generate still images from the live stream URL."

Perhaps I am misunderstanding that part? I re-tested and while the preview does not work when adding (it shows a broken icon), it does actually work when I click on the entity and then hit the play button.

I will re-confirm the log messages are still happening

davet2001 commented 8 months ago

@robloh thanks for providing more information. During the integration setup, the preview image is only generated from the still image setting. It doesn't generate anything from the stream, including a still image. My intention was to get a preview of both stream and still image, but so far that has not been possible.

You are correct that once set up, still images should be generated from the stream.

If your device doesn't like UDP, and ffmpeg swaps automatically to TCP, could you try configuring the camera as a TCP connection directly?

It could be that automatic handover from UDP to TCP could be added as a new feature.

issue-triage-workflows[bot] commented 5 months ago

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.