roleoroleo / yi-hack-Allwinner-v2

Custom firmware for Yi 1080p camera based on Allwinner platform
MIT License
752 stars 90 forks source link

Motion Detection / Recording changes between 0.3.1 and 0.3.2? #867

Closed sebastianha closed 1 month ago

sebastianha commented 2 months ago

Has anything changed regarding the motion detection or the recording?

I am pretty sure that before 0.3.2 a recording started before the motion was visible in the image but with 0.3.2 the recording starts a second after the motion has been detected.

Before when I opened the door to get in the room I could the the handle being pushed down and now the recording start when the door is completely open.

(using y623 cam, Base Firmware 12.0.51.01_202303091901)

sebastianha commented 2 months ago

I just downgraded one of my cameras to 0.3.1 (via local SD update) and there is no difference.

But I am pretty sure that I was impressed that the camera also catches the moment before the actual movement and this is definitely no longer the case.

I found an old recording where I can see the door closed before coming in. So the recording catched the moment of motion. Currently it is always 1-2 seconds too late.

sebastianha commented 2 months ago

I notice a relatively high load on the camera (1.5 - 2) as soon as I enable "Disable Cloud". Is this normal?

sebastianha commented 2 months ago

I still could not figure out why there is such a high load on my camera (all 3 of them).

I tried disabling everything but "no cloud" + "motion detection", different SD cards, different methods to format them.

Sometime I get motion recording where the start is before the motion but most of the time it is 1-2 seconds after the motion event has appeared.

roleoroleo commented 1 month ago

Motion recording is handled by Yi process and I can't change this behavior.

I notice a relatively high load on the camera (1.5 - 2) as soon as I enable "Disable Cloud". Is this normal?

This could be a cause of your problem. Are you able to understand if the load is greater in the last hack version?

sebastianha commented 1 month ago

Until now I have no idea why the load is so high and I could not spot any relevant differences between the versions.

Perhaps this is normal load & behaviour? Or is it different for somebody else?

Can you confirm that motion video recording always starts a little bit after the event?

roleoroleo commented 1 month ago

Here is my top:

Mem: 57820K used, 3092K free, 1148K shrd, 416K buff, 11528K cached
CPU: 30.4% usr  8.4% sys  0.0% nic 61.0% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 1.23 1.24 1.32 1/114 29731
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1354     1 root     S    40120 65.6   0 35.3 ./rmm
 2211     1 root     S<    5384  8.8   0  1.1 rRTSPServer -m h52ga -r both -a ulaw -p 554 -b AAC
28913  1803 root     S      920  1.5   0  0.3 /tmp/sd/yi-hack/bin/dropbearmulti /tmp/sd/yi-hack/sbin/dropbear -R -B -p 0.0.0.0:22 -2 7
  594     2 root     SW       0  0.0   0  0.3 [ksdioirqd/mmc1]
 1359     1 root     S     1468  2.4   0  0.1 /backup/tools/wpa_supplicant -c/tmp/wpa_supplicant.conf -g/var/run/wpa_supplicant-global -Dnl80211 -iwlan0 -B
  613     1 root     S     1164  1.9   0  0.1 ./dispatch
 1684     1 root     S     1152  1.8   0  0.1 ./cloud

Can you confirm that motion video recording always starts a little bit after the event?

I haven't got your model, so I can't test it. With my cam the recording starts a few seconds before the event.

sebastianha commented 1 month ago

interesting. Right now I never have recordings that start before the event but I am sure that I had this in the past. And I have no idea what has changed.

I wonder why the load is >1 but the CPU usage is <50%. There might be something else blocking the scheduler (IO?)

roleoroleo commented 1 month ago

With my cam the recording starts a few seconds before the event.

What I wrote is not completely true. MStar based cams work properly: the video starts 1 sec before the event. Allwinner-v2 based cams have the problem you described. I'm trying to understand where is the problem but it's very difficult.

I wonder why the load is >1 but the CPU usage is <50%. There might be something else blocking the scheduler (IO?)

I don't know, this load happens even without hack.

roleoroleo commented 1 month ago

Please, try to remove line 247 of system.sh:

        start_buffer
sebastianha commented 1 month ago

That does the trick! (confirmed on two cameras) Now I get a video which starts before the event.

BUT then MQTT does no longer work (also confirmed on two cameras)

roleoroleo commented 1 month ago

I can't do any further tests over the weekend. Please, try to start mqttv4 manually and check if:

/tmp/sd/yi-hack/bin/mqttv4

EDIT

Maybe I fixed... Overwrite wd_rtsp.sh with this one: wd_rtsp.sh.gz

sebastianha commented 1 month ago

Just started to debug, then saw your edit: Works!

I am not sure if the watchdog is the best way but it works. If I find some time I will investigate why it does not start in the first place.

I will continue testing over the day and let you know, but it looks very promising!

Thanks for your work!

sebastianha commented 1 month ago

"Long term testing" successful. Still recording events before the motion event and mqtt also still connected with your patched wd_rtsp.sh

roleoroleo commented 1 month ago

Probably, mqttv4 doesn't start in the first place because dispatch hasn't created yet the queues /dispatch_1 ... /dispatch_9. mqttv4 starts and exits with an open error.

sebastianha commented 1 month ago

Might be, nevertheless it works! Can you put it in a new release?

roleoroleo commented 1 month ago

Yes, of course.