Closed sebastianha closed 1 month 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.
I notice a relatively high load on the camera (1.5 - 2) as soon as I enable "Disable Cloud". Is this normal?
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.
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?
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?
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.
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?)
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.
Please, try to remove line 247 of system.sh:
start_buffer
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)
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
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!
"Long term testing" successful. Still recording events before the motion event and mqtt also still connected with your patched wd_rtsp.sh
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.
Might be, nevertheless it works! Can you put it in a new release?
Yes, of course.
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)