Fix issue with remote stream activation

[kaffetorsk]

Added watching state to camera. This is set when something else than arlo-streamer activates a stream.

Fixes Issue #26

[kaffetorsk]

@YpNo so, I added your PR to pyaarlo for get_stream_url. I can verify that the problem is due to arlo api not giving any information that one of the users stopped using the url if there are multiple connected (typically arlo-streamer + app)..

Implemented workaround that periodically takes down the stream if it's an external one (app), and checks if anyone is still watching.

Will do some testing before merge

[YpNo]

Thanks but I forgot to mention something : if you try replacing the rstp input by a long video file, it works as expected.

[kaffetorsk]

Thanks but I forgot to mention something : if you try replacing the rstp input by a long video file, it works as expected.

I'm struggling with your logic here. What does a long video file have to do with it? the problem is that as long as at least one client is reading the streaming url from arlo, it will not trigger any state change.

1. client 1 connects (i.e. arlo app)
2. client 2 connects (i.e. arlo-streamer through pyaarlo)
3. client 1 disconnects (nothing is triggered)
4. client 2 disconnects
5. arlo sees noone is reading the stream, takes it down and notifies pyaarlo it's idle

[YpNo]

Yes sorry: during my debug, I tested lot of use cases to understand where the problem is. So I tested with the same workflow (idle -> active stream -> idle) to put a long video file instead of rtsp url during the active strream. And, weird, the idle event is correctly received. Try it out and let me know your feedback. I tried with the get_url_stream (I've asked to pyaarlo) as well but same result I had.

[kaffetorsk]

Yes sorry: during my debug, I tested lot of use cases to understand where the problem is. So I tested with the same workflow (idle -> active stream -> idle) to put a long video file instead of rtsp url during the active strream. And, weird, the idle event is correctly received. Try it out and let me know your feedback. I tried with the get_url_stream (I've asked to pyaarlo) as well but same result I had.

I think your conclusions are wrong. the reasons why the stream is kept up is that arlo-api (the reverse engineered one, which pyaarlo uses) does not give any indication that the number of clients changed. both the app and pyaarlo (through get_stream_url) are reading the same stream. The activityState=idle is only triggered when no one is reading the stream anymore.

The point being that when you stop the stream in the arlo app, that does not trigger anything, since another client is still reading the stream, arlo thinks it's still beeing viewed in the app.

ffmpeg has nothing to do with this, it only reads the stream until the end as it is supposed to

[YpNo]

I’ve understood, and I know it is weird, but please do the test. Just replace the « -i stream » by long video file in the start_stream function.

[kaffetorsk]

So, your first test does this:

1. Start ffmpeg with an rtsp input
2. waits 10 seconds
3. stops the ffmpeg command

Your second test does this:

1. Connects to pyaarlo
2. Adds callbacks for all cameras -> event_handler
3. Registers a stop_event
4. Starts a status_thread

When event is recieved: if idle -> stops the ffmpeg process for the camera which sent the event if active -> start an ffmpeg process reading the current stream

Then you say the event is recieved after the key interrupt. Well of course it's recieved at the keyboard interrupt, since the trigger for arlo to send the idle event is that noone is reading the stream.

From your post: The conclusion is that the event loop is hanged by the ffmpeg command Well, yes it is that way by design (not hanged, but not idle), and it has nothing to do with ffmpeg. The only thing that matters is that someone is still reading the stream...

What you need to grasp is that the idle event from arlo is NOT generated when you hit "stop" in your app. It is triggered when noone is reading the stream, no clients are connected. Arlo are not able to detect if the clients are ffmpeg or their own app...

When you are using a long video file as input, of course the event is triggered, since when you hit stop in the app noone is reading the stream anymore.

I've repeated myself more times than i care for, and I'm done explaining this.

[YpNo]

I finally understand with you last explaination ! Sorry, I'm just trying to help AND understand. Some time we have to take anothers way to avoid bad thoughts ;)

I can verify that the problem is due to arlo api not giving any information that one of the users stopped using the url if there are multiple connected (typically arlo-streamer + app)

Do you think we should open a issue on pyaarlo about this behavior ?

Thanks a lot.