Core: Live camera view in Picture Glance eventually timeout/freezes, with a 404 loading playlist.m3u8

[timdonovanuk]

The problem

Camera live view in Picture Glance card eventually stops working and either freezes the image or displays a broken link.

When checking chrome dev tools, the card is trying to load a resource that no longer exists, e.g.

http://hassio.home:8123/api/hls/32ed95d8af4b58633ba73d95c20ca18b05e0886ba5d2b4d95f91963421c8a490/playlist.m3u8

On refresh, a new /api/hls/..... URL is generated and the card works again for a while, until 404 again on the new playlist.m3u8.

To recreate:

1. Configure a camera platform. I've had this happen with mjpeg, generic and rtsp streams.
2. Enable stream.
3. Add a picture glance card, and set the camera entity up
4. Load the front end and wait.

I'm unsure if it's an issue with the card itself, or Core, as it seems like it would be Core thats removing access to the playlist.m3u8 and causing the card to fail.

Environment

• Home Assistant Core release with the issue: 0.108.9
• Last working Home Assistant Core release (if known): Been an issue for many main versions
• Operating environment (Home Assistant/Supervised/Docker/venv): Home Assistant
• Integration causing this issue: Camera
• Link to integration documentation on our website:

Additional information

[probot-home-assistant[bot]]

camera documentation
camera source
_{^{(message by IssueLinks)}}

[timdonovanuk]

I have tried removing the stream: integration (although the option to preload stream still exists?) but this issue still persists. I notice these in the ha log, unsure if related but they happen around the same time the stream stops working:

2020-05-01 10:05:53 ERROR (stream_worker) [homeassistant.components.stream.worker] Error demuxing stream: No dts in packet

2020-05-01 10:09:26 ERROR (stream_worker) [homeassistant.components.stream.worker] Error demuxing stream: No dts in packet

I also found several other people with the same issue, so can confirm its not unique to my environment or setup.

[timdonovanuk]

Issue persists on Home Assistant 0.109.1.

[hunterjm]

Are your cameras WiFi or PoE? This is generally related to a stability problem with the video feed.

[Meelobee]

I keep seeing the same Demuxing error in my logs;

2020-04-28 00:31:18 ERROR (stream_worker) [homeassistant.components.stream.worker] Error demuxing stream: No dts in packet

Using 2 Wyze cams with the RTSP firmware. But other than the errors in the logs I dont see anything broken. Both cams always work fine.

Currently running version 0.108.9

[timdonovanuk]

@hunterjm Perhaps, but video feeds are always likely to have errors, due to the high bandwidth requirement of trying to throw a ton of traffic over lines. Any errors should be handled gracefully. The RTSP stream works fine in VLC, Android VLC, through the camera web UI, and various other apps both on PC and Android, so if there are errors, every other platform handles them. It's only HA that does not gracefully handle whatever errors may be in the stream.

FWIW HA is also the only platform where the stream consistently shows a ~30 second delay.

[timdonovanuk]

The problem is with this line:

           packet = next(container.demux(video_stream))
            if packet.dts is None:
                if first_packet:
                    continue
                # If we get a "flushing" packet, the stream is done
                **raise StopIteration("No dts in packet")**

Clearly many of our cams are sending a "flushing packet" but not actually done with the stream. The same issue is present in https://github.com/home-assistant/core/issues/22840. I suspect commenting out that line would resolve things (even if it needs a better solution).

[hunterjm]

I agree that dropped or late packets can be handled better, but commenting out that line won't solve your issue. In fact, it will put the stream in a perpetual error state, because we are not re-connecting to the feed, which is what needs to happen in this case.

The delay is related to a mixture of your camera's settings and how HLS works to enable broad browser support without requiring a plugin (like your camera's web UI likely does). If you are curious, you can find more info about that at https://github.com/home-assistant/core/issues/34605#issuecomment-619200448

Home Assistant is doing things very differently than your standard RTSP viewing app all in the name of simplicity and performance so users running on a Raspberry Pi don't burn out their SD cards or over tax their CPU transcoding video.

[geiseri]

I am not sure if this is similar, but when I try to view live streams with my camera's h.265 rtsp feed then I see the below 502 Error:

If I look in the logs I see only:

2020-05-16 18:57:16 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140657785030096] Received {'type': 'camera/stream', 'entity_id': 'camera.backyard', 'id': 23}
2020-05-16 18:57:16 INFO (MainThread) [homeassistant.components.stream] Started stream: rtsp://xxxx:[email protected]:554/11
2020-05-16 18:57:16 DEBUG (MainThread) [homeassistant.components.websocket_api.http.connection.140657785030096] Sending {'id': 23, 'type': 'result', 'success': True, 'result': {'url': '/api/hls/f4beee7d25f2bc3f82d82ca50ce7443bf0c2d5e9bcbefd60facd54afed22b0e0/playlist.m3u8'}}
2020-05-16 18:57:16 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/hls/f4beee7d25f2bc3f82d82ca50ce7443bf0c2d5e9bcbefd60facd54afed22b0e0/playlist.m3u8 to 10.0.5.15 (auth: False)

At that point though there is no further action from the system until I reload the page

Now if I tell the camera to send h.264 main profile, I can view the stream, but there is ~15-20 second delay. The system is an Intel Atom CPU, and from what I can see the CPU load, and network activity is minimal.

Is this more of the same as this issue?

[hunterjm]

@geiseri - H265 is not supported in Home Assistant at this time. Unrelated to this issue.

[geiseri]

@hunterjm ah, okay. Well, that explains my issue. Thanks!

[turbo4door]

I'm also having this issue with a Wyze V2 cam running RTSP firmware. I don't recall seeing this prior to .111
I'm on .112.3 now and it's still occuring.

[ztripez]

Having the same issue with DLink DCS-825L

[timdonovanuk]

This is still a problem, many versions later, even using a totally different camera and stream. I'm now using the stream provided by motion-eye, i.e. my camera is defined as:

  - platform: mjpeg
    mjpeg_url: http://localhost:8081/
    name: babycam

and yet, if HA is left open the browser too long:

I do not think it is stream related, it is an issue with the picture glance card. If it is stream related, then the card is extremely sensitive to any stream issues, because viewing the stream in VLC or on my phone does not show any stream issues whatsoever.

Once again, I think it is more an issue with the generated token timing out, because I see the card is trying to load the following resource:

https://<my_ha_url>/api/camera_proxy_stream/camera.babycam?token=f76667ca2d92c1ccf04367a122a85f675e45c048405a8f2a27cc04293be2d59c

but this returns a 401: Unauthorized

[roblandry]

Seeing same error wyze cam v2

[Meelobee]

Same here, using 2 Wyze V2's and 1x Wyze PanCam, all with RTSP firmware.
I still keep getting these 2 errors in my logs non stop:

Even though these errors don't seem to affect functionality much (Stream is a bit choppy at times, but I'm not sure if that is related.) it still would be nice to get rid of the messages in the logs. Is there any progress on a possible fix for this? Thanks :)

[kbouh320]

Hello, same issue with an Amcrest camera. I use both the Camera and Amcrest platforms to control the camera PTZ and take snapshots every 5 seconds when my alarm triggers.

Everything seems to be working fine but I get these errors at least 2 or 3 times a day.

Error demuxing stream: No dts in consecutive packets
9:49:07 AM – Stream (ERROR)
Stream packet without dts detected, skipping...
9:49:07 AM – Stream (ERROR) - message first occurred at 9:49:07 AM and shows up 2 times

Cheers