search

FiveLeavesLeft / WyzeCameraLiveStream

Hack to allow live streaming from wyze cameras to vlc or mpv on your desktop.
MIT License
101 stars 7 forks source link

mp4s not saving to SD card #7

Open mrlt8 opened 3 years ago

mrlt8 commented 3 years ago

Hi Charlie, found another SD related bug.

I noticed that I wasn't getting any recording under the "View Playback" section of the wyze app, so I took a look at the SD card and could see the folders for each of the days in /media/mmc/recordings/ were being created, but had some weird characters at the end:

47.9M   /media/mmc/record/20210503
16.0K   /media/mmc/record/20210506?w
16.0K   /media/mmc/record/20210507?w

Got the same result after formatting the card:

16.0K   /media/mmc/record/20210507Ew
16.0K   /media/mmc/record/20210507Yw
16.0K   /media/mmc/record/20210507lw

Replicated the issue on a couple of other cameras as well. The folders normally have a %Y%m%d format, but for some reason they are getting a random character + w at the end of the directory name.

The files in /alarm and /time_lapse seem unaffected and are getting created normally.

FiveLeavesLeft commented 3 years ago

Interesting, I'll take a look. I assume this V2 with the software that requires the wyzehacks install?

mrlt8 commented 3 years ago

Yup, V2 latest stream_hack.

FiveLeavesLeft commented 3 years ago

I'm still looking at this, it's a tricky memory overrun issue in the wyze code or wyzehacks code. Could even be a compiler bug but I doubt it. The wyzehacks C code is triggering it, but it's not clear yet where or why exactly.

endertable commented 3 years ago

You bring up a very good point @FiveLeavesLeft I was wondering why I was not encountering a lot of the same issues you guys were as far as events not logging and this possible issue, but it might be because I don’t use the Wyze hacks. Some of these issues may have to do with the library that wyze_hacks main.sh loads on start up.

mrlt8 commented 3 years ago

Thanks for the update @FiveLeavesLeft!

@endertable Are you running stream_hack without wyze_hacks?

endertable commented 3 years ago

Yes, Mostly because I don’t used NFS recording saving. I use SD cards and access videos remotely as needed.

mrlt8 commented 3 years ago

Same here. I only have STREAM_HACK enabled in my wyze_hack.cfg. Everything else is commented out.

Are your events being recorded to the /record directory on your SD card?

endertable commented 3 years ago

I have all events recorded to SD card and to the cloud. If you are using wyze hacks did you disable the wyze hacks .so library file from being loaded?

ZuluSpl0it commented 3 years ago

I haven't seen the weird characters at the end, but I did notice that the mp4s were not being saved. The permissions for the "record" folder were different than the alarm folder. I did a chmod 755 record from the Camera via telnet and now it saves the mp4s. I have a v2 running WyzeHacks 0.5.06

FiveLeavesLeft commented 3 years ago

I can fix the record directory and funny characters issue, but it would mean disabling the wyzehacks NFS functionality. So far I've been avoiding that but I'm curious how many people are using the stream hack and the wyzehacks NFS functionality.

gtxaspec commented 3 years ago

very interested in maintaining NFS support, we have 6 cameras that all record to NFS, no local storage in the cameras, working well. since the cameras are exterior, I'd hate to lose footage of they were stolen or damaged. and the rtsp streaming means I don't have to use the wyze app or tinycam too.

mrlt8 commented 3 years ago

I personally don’t use the NFS option, but know it’s a popular hack.

Maybe you could disable wyze hacks if none of the NFS options are enabled? Would that break anything else?

ZuluSpl0it commented 3 years ago

@FiveLeavesLeft Could you work with HclX/WyzeHacks to fix the permissions issue there? That might be able to keep the NFS working.

Please refer to: https://github.com/HclX/WyzeHacks/issues/91#issuecomment-841309250

endertable commented 3 years ago

If you are using NFS v4 you may get strange chmods on directories if users are different. You are using rooot on the camera, but it seems like you are using pi on the Linux server. Try using the root user on your Linux NFS server to see what it does

mrlt8 commented 3 years ago

I believe WyzeFirmwareTool also ran into some compatibility issues with NFS and WyzeHacks and had to drop support for both.

I haven't seen the weird characters at the end, but I did notice that the mp4s were not being saved. The permissions for the "record" folder were different than the alarm folder. I did a chmod 755 record from the Camera via telnet and now it saves the mp4s. I have a v2 running WyzeHacks 0.5.06

Is your /record on the SD card or on an NFS server? All the folders in my /media/mmc are drwxr-xr-x root root by default.

ZuluSpl0it commented 3 years ago

The record folder is on the NFS which is running v3. What's weird is that the other folders have the correct permissions when created.

My NFS options used are /mnt/nfsshare *(rw,all_squash,insecure,async,no_subtree_check,anonuid=1000,anongid=1000). . So the anonymous login from the camera should use pi's UID and GID. (1000)

ZuluSpl0it commented 3 years ago

I ran the NFS server on a real raspberry pi 3 (unlike the virtualized Raspberry Pi Desktop for PC i was using earlier) and the camera records without any permissions issues. The folders and mp4 get created as expected.

endertable commented 3 years ago

It is pretty much purely an NFS server issue and not an issue of stream hacks. iCamera does not have to worry about changing permissions on an SD card because default permissions for Linux for a vfat filesystem are 755 no matter what. You couldn’t change permissions on an SD card if you wanted. Because of security, some NFS servers don’t like those loose permissions and use stricter default unmasks, others don’t care. Either way, I don’t believe iCamera issues a chmod command for SD card IO operations and therefore won’t issue them on the NFS mount either. It’s good you found an NFS with a good umask.

mrlt8 commented 3 years ago

I have all events recorded to SD card and to the cloud. If you are using wyze hacks did you disable the wyze hacks .so library file from being loaded?

Are you disabling the Wyzehacks in /tmp/wyze_hack/run/main.sh?

endertable commented 3 years ago

I don’t use WyzeHacks per se so I am only guessing that may be why I am not having a lot of the same issues as some. But I did dabble with it last year and I remember he used a custom .so file to load app_init.sh and I am guessing he is still using it somewhere in the main.sh file. I imagine its main purpose is to prevent iCamera from screwing around with the /media directory for the NFS mount hack to work.

mrlt8 commented 3 years ago

Here's a bash script that temporarily fixes the issue by creating a folder for today and removing all the junk folders:

#!/bin/sh

while : ; do
    [[ $(ls -d /media/mmc/record/*w | wc -w) -ge 1  ]] && rm -r /media/mmc/record/*w/
    [[ ! -d /media/mmc/record/$(date +'%Y%m%d') ]] && mkdir /media/mmc/record/$(date +'%Y%m%d')
    sleep 3600
done

This obviously needs to be run at least once a day to cleanup and create the dir for today, so I have it sleep and run every hour since the camera doesn't have cron.

Not sure if this is related to wyzehacks or just the way vanilla wyze works, but I noticed that the camera continuously writes a new file every min (record/<day>/<hour>/<min>.mp4) regardless of motion, THEN deletes the file IF there was no motion..

I always assumed the "Events Only" record option in the Wyze app only wrote to the SD card IF there was motion, but it seems like it will continuously write which could have an impact on the life of the SD card.