Android: Camera traffic, when app in background.

Created on 25 Sep 2020  ·  45Comments  ·  Source: home-assistant/android

Home Assistant Android version:
2.4.1-full

Android version:
10
Phone model:
Xiaomi mi 9
Home Assistant version:
0.115.3
Last working Home Assistant release (if known):
no
Description of problem:

When app in background, video streams from cameras does not stop stream. Almost all apps stops video stream at onPause() Android lifecycle, but HA does not. Now the problem is even more serious, because from the activities of the sensors, the system almost never kills the application. I have a lot of cameras and I wasted 70 gigabytes in a month because of this bug. Plus the battery runs out quickly.
Traceback (if applicable):

Screenshot of problem:
Screenshot_2020-09-25-18-25-18-432_com miui securitycenter

Additional information:
Solution: You should stop stream, when device goes onStop(), maybe communicate with HA server, and show video placeholder.

bug webview

Most helpful comment

1) I checked "automatically close connections" - "Should we close the connection to the server after being hidden for 5 minutes?" - was on, but it seems 5 minutes too much for mobile.
2) I use card on lovelace which plays video on the homescreen directly - as it is nice feature.
3) Yes, HA is Webview, but HA is not website, here you can control server or frontend, and forward iOS /Android lifecycle to frontend, maybe even to backend, to lower the number of frames in the video, or use still image when APP is onStop() or onPause()

All 45 comments

You need to check that "automatically close connections" in your HA user profile is enabled. The frontend actually handles this part as we are just a webview so they look to see if you have gone idle.

You should also check that you are not going to the home screen when you have the more info panel open, another offender in this case is if you use the live view card on lovelace which plays video on the homescreen directly.

1) I checked "automatically close connections" - "Should we close the connection to the server after being hidden for 5 minutes?" - was on, but it seems 5 minutes too much for mobile.
2) I use card on lovelace which plays video on the homescreen directly - as it is nice feature.
3) Yes, HA is Webview, but HA is not website, here you can control server or frontend, and forward iOS /Android lifecycle to frontend, maybe even to backend, to lower the number of frames in the video, or use still image when APP is onStop() or onPause()

This started for me too after (one of the) latest update(s). Just spend 2,5 GB in 10 minutes. Never experienced this before.

@nick2525 and @barrymossel can you please include your yaml camera config and frontend config so we can attempt to recreate. I have tried with my personal setup and I am unable to get the app to stream in the background.

camera:

  • platform: mjpeg
    name: children_camera
    username:
    password:

    mjpeg_url: http://.../live/0/mjpeg.jpg

camera 3:

  • platform: mjpeg
    name: kitchen_camera
    mjpeg_url: http://...:56000/mjpeg

camera 4:

  • platform: mjpeg
    name: slipping_camera
    username: admin
    password: admin
    mjpeg_url: http://.../live/0/mjpeg.jpg

camera 5:

  • platform: generic
    name: slipping_room_camera
    framerate: 2
    still_image_url: http://.../webcapture.jpg?command=snap&channel=1

camera 6:

  • platform: generic
    name: child_room_camera
    framerate: 2
    still_image_url: http://.../webcapture.jpg?command=snap&channel=1

{ "background": "radial-gradient(crimson, skyblue)", "cards": [ { "camera_view": "live", "entity": "camera.children_camera", "title": "\u041a\u043e\u0440\u0438\u0434\u043e\u0440", "type": "picture-entity" }, { "camera_view": "live", "entity": "camera.child_room_camera", "title": "\u0441\u043f\u0430\u043b\u044c\u043d\u044f", "type": "picture-entity" }, { "camera_view": "live", "entity": "camera.kitchen_camera", "title": "\u043a\u0443\u0445\u043d\u044f", "type": "picture-entity" }, { "camera_view": "live", "entity": "camera.slipping_camera", "title": "\u043b\u0435\u0441\u0442\u043d\u0438\u0446\u0430", "type": "picture-entity" }, { "camera_view": "live", "entity": "camera.slipping_room_camera", "title": "\u0441\u043f\u0430\u043b\u044c\u043d\u044f", "type": "picture-entity" } ], "id": "cameras", "theme": "dark-mode", "title": "\u043a\u0430\u043c\u0435\u0440\u044b" }

camera:
  # - platform: foscam
    # ip: !secret ip_camera_kleren
    # name: Klerenkamer
    # username: !secret camera_kleren_username
    # password: !secret camera_kleren_password
  # - platform: ffmpeg
    # name: Lise
    # input: !secret url_camera_lise
  - platform: mjpeg
    name: Sophie
    mjpeg_url: http://192.168.1.43:8081/
  - platform: mjpeg
    name: Lise
    mjpeg_url: http://192.168.1.43:8082/
  - platform: mjpeg
    name: Hal
    mjpeg_url: http://192.168.1.43:8083/

The ones that were commented out are my old camera's which didn't have this problem. When I "updated" those the traffic started getting out of hand. Did some more investigation: I use MotionEye as when I load the rtsp feeds directly into HA I get a lag ranging from 4 to 60 sec. When I load the rtsp feed into MotionEye and let that process and stream it, there is virtually no lag (max 1 sec). But apparently the feeds use way too much bandwidth. When I load the stream url into a browser it uses lot's of data as well. So that's one of the issues for me. But now I turned the quality of the feeds to 25% and it still uses 100's of MB's per couple of minutes. Way more than the original feed passing through the Ewelink app (camera's are Sonoffs).
But still, I believe the old camera's didn't do any of this anyway. Never noticed something weird on the data usage side of the HA app... So, could be two things I guess: very small feeds with low data usage, or no streaming in background.

And btw, if I force the app to close it doesn't stream and use data. If I just go back to Android home screen it does use bandwidth.

Lovelace:

          - type: picture-glance
            title: Sophie
            camera_image: camera.sophie
            camera_view: live
            aspect_ratio: 16:9
            entities:
              - binary_sensor.deursensor_sophie_contact      
              - light.sophie       
          - type: picture-glance
            title: Lise  
            camera_image: camera.lise
            camera_view: live
            aspect_ratio: 16:9
            entities: 
              - binary_sensor.deursensor_lise_contact
              - light.lise

I got the same issue (#1017)
I also happen to have a Xiaomi mi 9(T pro)

HA config:

- platform: generic
  name: Hallway
  still_image_url: !secret camera_hallway_snap_url
  verify_ssl: false

- platform: generic
  name: Street
  still_image_url: !secret camera_street_snap_url
  verify_ssl: false

- platform: generic
  name: Livingroom
  still_image_url: !secret camera_livingroom_snap_url
  verify_ssl: false

Lovelace:

    cards:
      - aspect_ratio: 0%
        camera_image: camera.hallway
        camera_view: live
        entity: camera.hallway
        show_name: false
        show_state: false
        type: picture-entity
      - aspect_ratio: 0%
        camera_image: camera.livingroom
        camera_view: live
        entity: camera.livingroom
        show_name: false
        show_state: false
        type: picture-entity
      - aspect_ratio: 0%
        camera_image: camera.street
        camera_view: live
        entity: camera.street
        show_name: false
        show_state: false
        type: picture-entity

My wife has Xiaomi mi 9T, the bug is also reproduced.

I just got burned by this, wasted almost 1GB of my data plan. Using the Zoneminder integration, and Picture Glance Cards.

zoneminder:
  - host: zoneminder.mydomain.com
    ssl: true
    username: x
    password: x

sensor:
  - platform: zoneminder
    include_archived: false

camera:
  - platform: zoneminder

Was it fixed in 0.117.0b1? Because the bug is still being reproduced(

@nick2525 can you verify the frontend version you are on please?

Frontend version: 20201021.1 - latest

Screenshot_2020-10-22-20-13-52-062_com miui securitycenter

@nick2525 thanks, and you waited 5 minutes for the connection to close right?

BTW it looks like the linked issue was actually not the fix for this. That was the reasoning for the bug closing and being re-opened.

Some cameras disconnected after 5 minutes, but live view is not restored on those cameras. But if I pres on camera, stream works. But live view is not restored on app onResume()

live view being restored is unrelated to this issue....this issue is purely about making sure the data flow stops when the app is in the background after 5 minutes.

Screenshot_2020-10-22-20-44-29-006_com miui securitycenter
It seems, that some camera didn't stop after ten minutes, because It too much data for sensors, but it 8 times less traffic when after one minute in background

what are the results if you disable all your picture entity cards? does it 0 out then after 5 minutes?

Screenshot_2020-10-22-21-06-34-703_com miui securitycenter

It almost no traffic when I disabled camera view live, and 0.00kb after 7 minutes with disabled camera view live

@dshokouhi @bramkragten @JBassett https://github.com/home-assistant/frontend/pull/7362 fixed all cameras, except one which has no stream, and only still_image_url, so 2 frame per second is about 240 KB/s, I disabled/enabled camera view live for each cameras, and only camera with only still_image_url and no stream produced traffic after 8 minutes

"platform: generic
name: child_room_camera
framerate: 2
still_image_url: http://.../webcapture.jpg?command=snap&channel=1"

It still reproduced, but on still_image_url only cameras,
version | 0.117.2
frontend 20201021.4

I can confirm this issue, which exists on both mine and my partners phones - since 0.117 ish up until now (0.118.0b2).
The weird thing is that we're seeing data being counted as "foreground", although the app certainly hasn't been open/in use for the duration it would take to transfer this much data.

Most notably today, when it ran away using 1.9GB from 00:00 till about 07:30;
Screenshot_20201115-131712_Settings_200

@bendikrb Do you have still_image_url camera? Or you have steam?

Do you have still_image_url camera? Or you have steam?

One of them is defined using the mjpeg platform, with both still_image_url and mjpeg_url defined;

- platform: mjpeg
  name: front_door_lowres
  username: !secret vivotek_username
  password: !secret vivotek_password
  verify_ssl: false
  still_image_url: !secret vivotek_still_image_url
  mjpeg_url: !secret vivotek_mjpeg_lowres_url

The other one is set up using the onvif integration (using config_flow), and is proxied (this is the entity I'm using in lovelace);

- platform: proxy
  entity_id: camera.backyard_onvif_hires
  name: backyard_hires
  max_stream_height: 1280
  cache_images: true

OT: The reason for proxying is because if I don't, and display the entity directly in lovelace, the ffmpeg parameters i have defined in the onvif settings isn't applied (dewarping of the 180° fisheye lens).

If you are still experiencing this issue after you update to at least BETA 522 please also test once in Chrome and let us know if the issue occurs there as well.

It seams it wasn't fixed on Xiaomi mi 9, I installed beta-522-d99daec-full , and ha consume 1.12 mb/s in Xiaomi security app. I don't have spit screen, and Xiaomi security app is resumed, it not transparent. I also tried to open Google translate App after HA, and when Xiaomi security app. Bug 🐛 is reproduced

@nick2525 can you check in chrome and see if you can reproduce there please.

Screenshot_2020-11-17-01-55-20-018_com miui securitycenter
Same problem on chrome, with only HA tab

Screenshot_2020-11-17-02-05-21-016_amirz rootless nexuslauncher traffic from HA when I am at launcher , also traffic when I am on second tab in chrome, and no app started
Screenshot_2020-11-17-02-09-45-561_com android chrome

How are you exactly doing these tests? Can you make a step by step guide with timing? And what is the config of the problematic dashboard?

@nick2525 also please ensure you are waiting 5 minutes for the connection to close as well, please be precise with your steps when you comment back.

https://drive.google.com/file/d/1fD4z951965KTrxWSIvsIXk4jyztIzPFM/view?usp=drivesdk I uploaded video. Now I didn't wait 5 minutes, as though that onStop fix should work immediately. I have already posted my cameras config at beginning of bug

@nick2525 this is in onPause please wait 5 minutes as thats intended behavior. The feeds should stop after the connection closes in 5 minutes, not immediately.

Screenshot_2020-11-17-03-04-16-242_amirz rootless nexuslauncher begin
Screenshot_2020-11-17-03-09-34-178_amirz rootless nexuslauncher after 5 minutes some cameras stopped stream except still image url cameras.
Screenshot_2020-11-17-03-09-45-403_com android systemui nothing changed after last fix home-assistant/frontend#7362
I have WebView implementation
Android System WebView 86.0.4240.185

@nick2525 and just to confirm you see the exact same behavior in chrome with the 5 minute wait?

Yes, same at Chrome 1.1 mb/s during 5 minutes, 200 kb/s after 5 minutes (some cameras were disconnected after 5 minutes but not all)

Ok, do you know what camera was and what camera wasn't stopped?

@bramkragten Yes, I removed all cameras and when added again one by one, and such camera wasn't stopped

platform: generic
name: slipping_room_camera
framerate: 2
still_image_url: http://.../webcapture.jpg?command=snap&channel=1

Mjpeg cameras were stopped, like this
platform: mjpeg
name: children_camera
username:
password:

mjpeg_url: http://.../live/0/mjpeg.jpg

this happened to my father’s phone today with the companion app.
9 GB used in one day.
Pixel 4XL
He never opens the app. its used for location tracking only.
“auto close connection” has been checked, for months with no issue until today.
I do have some live view cameras on a lovelace page, but no issue until today on 1 phone, not all.

@TRusselo Do your have still image url cameras? I will try also to report bug to Chrome developers

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Bruceforce picture Bruceforce  ·  3Comments

tiagofreire-pt picture tiagofreire-pt  ·  3Comments

Anonym-tsk picture Anonym-tsk  ·  3Comments

simbesh picture simbesh  ·  3Comments

Knoxie picture Knoxie  ·  5Comments