hass-aarlo icon indicating copy to clipboard operation
hass-aarlo copied to clipboard

Streaming starting then stopping immediately

Open wbx13 opened this issue 2 years ago • 2 comments

Hi there,

I am a new user of hass-aarlo and I wasn't able to get the streaming working properly when not using direct streaming. The setup is as follow:

  • home assistant: 2022.5.2 docker image
  • hass-aarlo: main branch (I also tried with older releases with no luck.)
  • lovelace-hass-aarlo

I am not used to post on Github, please be indulgent if this doesn't meet formatting, details, etc.

At first, I also couldn't find a way to get the direct streaming work properly so I tried to work around it. Now direct streaming works for me (see end of this post) but I still wanted to share what I found during my investigations with those who that might help.

On HA side, I had to set the backend as "sse" before getting the alarm state right but this is off-topic.

The issue I had first was that when trying to stream from the Lovelace UI, the UI was not able to access the master_playlist.m3u8 file (10s timeout => 499 error), unable to open it with VLC either.

I had a look to the logs and found that the stream was being destroyed before I could even access it. Here is the log section:

2022-05-13 09:01:16 DEBUG (SyncWorker_1) [pyaarlo] _start_stream2::reqs='set()',local='{'streaming'}',remote='set()' 2022-05-13 09:01:16 DEBUG (SyncWorker_1) [pyaarlo] looking for user_agent arlo 2022-05-13 09:01:16 DEBUG (SyncWorker_1) [pyaarlo] url=rtsps://arlostreaming423-z1-prod.wowza.arlo.com:443/vzmodulelive/A5DA197JA1646_1652425276821?egressToken=xxx&userAgent=iOS&cameraId=A5DA197JA1646_1652425276821&txnId=be!ff609b3c-e55f-4d26-a6c3-xxxxxxxxx 2022-05-13 09:01:16 INFO (MainThread) [homeassistant.components.stream.stream.camera.aarlo_cam01] Started stream: rtsps://arlostreaming423-z1-prod.wowza.arlo.com:443/vzmodulelive/A5DA197JA1646_1652425276821?egressToken=xxx&userAgent=iOS&cameraId=A5DA197JA1646_1652425276821&txnId=be!ff609b3c-e55f-4d26-a6c3-xxxxxxxxx2022-05-13 09:01:16 DEBUG (ArloEventStream) [pyaarlo] sending cameras/A5DA197JA1646 to A5DA197JA1646 2022-05-13 09:01:16 DEBUG (ArloBackgroundWorker) [pyaarlo] Cam01 CAMERA got one cameras/A5DA197JA1646 2022-05-13 09:01:16 DEBUG (ArloBackgroundWorker) [pyaarlo] set:ArloCamera/A5DA197JA1646/activityState=startUserStream 2022-05-13 09:01:16 DEBUG (ArloBackgroundWorker) [custom_components.aarlo.camera] callback:Cam01:activityState:startUserStream 2022-05-13 09:01:16 DEBUG (ArloBackgroundWorker) [custom_components.aarlo.camera] clearing out stream variable 2022-05-13 09:01:17 DEBUG (ArloEventStream) [pyaarlo] sending cameras/A5DA197JA1646 to A5DA197JA1646 2022-05-13 09:01:17 DEBUG (ArloEventStream) [pyaarlo] sending cameras/A5DA197JA1646 to A5DA197JA1646 2022-05-13 09:01:18 DEBUG (ArloEventStream) [pyaarlo] sending cameras/A5DA197JA1646 to A5DA197JA1646 2022-05-13 09:01:18 DEBUG (ArloEventStream) [pyaarlo] sending cameras/A5DA197JA1646 to A5DA197JA1646 2022-05-13 09:01:20 INFO (ArloBackgroundWorker) [homeassistant.components.stream.stream.camera.aarlo_cam01] Stopped stream: rtsps://arlostreaming423-z1-prod.wowza.arlo.com:443/vzmodulelive/A5DA197JA1646_1652425276821?egressToken=xxx&userAgent=iOS&cameraId=A5DA197JA1646_1652425276821&txnId=be!ff609b3c-e55f-4d26-a6c3-xxxxxxxxx 2022-05-13 09:01:20 DEBUG (ArloBackgroundWorker) [pyaarlo] activityState: NEW startUserStream 2022-05-13 09:01:20 DEBUG (ArloBackgroundWorker) [pyaarlo] activityState: OLD startUserStream

My interpretation was that hass-arlo asks pyaarlo to start the stream, pyaarlo starts it, but then hass-aarlo clears it out before it could event reach an active state. After digging a bit, I found that the update_state callback (camera.py line 326) was not checking if the value was in a temporary "startUserStream" state, so was clearing the stream in the else block. Not that pretty but I replaced the line 334: elif value == "userStreamActive": With: elif value == "userStreamActive" or value == "startUserStream":

It was better, the stream wasn't get cleared out and the master_playlist.m3u8 was accessible after a few seconds (readable with VLC).

BUT, this doesn't quite worked yet. When the UI tries to start streaming, the master_playlist.m3u8 is not yet ready to be served and results in a 404 error or 499 timeout when calling it too early. Introducing a delay before returning the url to the websocket might help. I have added a 2 seconds delay on the frontend side by modifying the lovelace-hass-aarlo card and it worked fine !

I know this is not the right place to write this might help some people facing the same issue. While writing this, I found that the lovelace-hass-aarlo card documentation was wrong. It says that the "direct" option should be put in the "image_view" settings but the code says it should be added to "image_click" (see hass-aarlo.js line 1215): cc.directPlay = image_click.includes("direct") || _value( config.play_direct, false )

The "play_direct" option is not documented, but adding it at the root level of the card declaration just makes direct streaming work perfectly.

So at the end of the day, I'll just go with direct streaming without modifying any code.

wbx13 avatar May 13 '22 08:05 wbx13

Thanks for the report. I'll revisit all this stuff, I think there is a lot of things going on:

  • some general code rot and bad documentation
  • Arlo playing around, I think they made some changes recently that have blown up a lot of things

I'll try it on my set up here.

twrecked avatar May 13 '22 14:05 twrecked

Hey @twrecked, thanks for all of your work on this, it's amazing! Are there any updates on Arlo functionality for Home Assistant?

kylepyke avatar Aug 26 '22 20:08 kylepyke