Check recording?

[jmbulan]

From the sev server the link to "check recording" but page displays

NG Date directory does not exist (/opt/record/)

How do I properly configure this?

[virmaior]

this means that your camera is not recording video to the SD card.

Either configure it using wyze's app (Risks getting hit with an unwanted firmware update) or try rebooting the camera and see if starts recording.

On my cameras, this happens under one of two circumstances:

1. something has clobbered the /configs directory (currently investigating what could do that)
2. it has just stopped recording (also not sure why -- maybe after it has had a problem with the SD card)

[jmbulan]

But they are recording.... Could it be because recordings are in opt/Record and not opt/record?

[virmaior]

okay, that is interesting. I only have experience with my V3s and an AtomCamV2 and all of mine are lowercase opt/record

Did wyze create the /opt/Record directory on the SD card or are you doing something a bit different where you're creating it with the capitalization? (if it's a setting I can change the code to check for the value in that setting).

[jmbulan]

That's my mistake the directory is opt/record.

I do see there's a recent update ill start fresh on a spare cam

[virmaior]

okay, now things get more interesting.

1. can you cat /configs/TZ and show me the output?
2. these are standard run of the mill v3s?

Current hypothesis is that my code is guessing the date wrong.

There's actually an error in /opt/wz_mini/www/cgi-bin/status.cgi

        echo "Date directory does not exist ($base$fname)"

should be:

        echo "Date directory does not exist ($base$fpath)"

which would be more informative. I'm guess something is happening where my code is not correctly parsing your TZ

[kzaoaai]

Changing status.cgi results in this: NG Date directory does not exist (/opt/record/20240107)

[virmaior]

what is the result for cat /configs/TZ ?

(note that it's presently 20240210 or 20240209 or so ..., are your cameras recording to the current date?)

[kzaoaai]

the TZ command results in PST+0800PDT+0700,M3.2.0/02:00:00,M11.1.0/02:00:00

[qip]

I believe the issue with the date directory not found / time zone is related to libc.

While the date command from GNU coreutils with glibc is able to parse various kinds of timezone strings, such as JST-0900JST-0900 (what I have in /configs/TZ), or PST+0800PDT+0700,M3.2.0/02:00:00,M11.1.0/02:00:00 (as mentioned in the comment above), the BusyBox version of date in wz_mini apparently uses uclibc, which accepts a different format in tzset(). See: https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html

I'm not sure how the /configs/TZ is set, it's possible glibc is used by wyze cam firmware and time zone is set through it. (Or a different source?) For now, I've manually set TZ to JST-9 (in my case) just to test how the script works.

[virmaior]

@qip that's very helpful and explains the current issue. I'll see if I can recode the status.cgi code to use GNU glibc somehow.

In my case the /configs/TZ is JST-900

[virmaior]

so far no luck finding a function on busybox that will enable the parsing of more complicated TZs

This is interesting because obviously something in iCamera is parsing them and not only parsing them once but parsing it every minute to figure out what file to make (Since it loses this when /configs gets clobbered.

[qip]

I guess we can parse and reformat the time zone string:

[root@FRONTPORCH:~]# cat /configs/TZ
JST-0900JST-0900
[root@FRONTPORCH:~]# TZ=$(sed -E 's/([+-])([0-9]{2})([0-9]{2})/\1\2:\3/g' /configs/TZ) date
Wed Feb 14 14:24:18 JST 2024
[root@FRONTPORCH:~]# echo "JST-900" > /tmp/tz1
[root@FRONTPORCH:~]# echo "PST+0800PDT+0700,M3.2.0/02:00:00,M11.1.0/02:00:00" > /tmp/tz2
[root@FRONTPORCH:~]# TZ=$(sed -E 's/([+-])([0-9]{2})([0-9]{2})/\1\2:\3/g' /tmp/tz1) date
Fri Mar 22 17:25:01 JST 2024
[root@FRONTPORCH:~]# TZ=$(sed -E 's/([+-])([0-9]{2})([0-9]{2})/\1\2:\3/g' /tmp/tz2) date
Tue Feb 13 21:25:04 PST 2024

edit: Still need to figure out why JST-900 could be set. Meanwhile, it's possible to use 's/([+-])([0-9]{1,2})([0-9]{2})/\1\2:\3/g'

[root@FRONTPORCH:~]# TZ=$(sed -E 's/([+-])([0-9]{1,2})([0-9]{2})/\1\2:\3/g' /tmp/tz1) date
Wed Feb 14 14:29:22 JST 2024
[root@FRONTPORCH:~]# TZ=$(sed -E 's/([+-])([0-9]{1,2})([0-9]{2})/\1\2:\3/g' /tmp/tz2) date
Tue Feb 13 21:29:26 PST 2024
[root@FRONTPORCH:~]# TZ=$(sed -E 's/([+-])([0-9]{1,2})([0-9]{2})/\1\2:\3/g' /configs/TZ ) date
Wed Feb 14 14:29:33 JST 2024

[virmaior]

It seems like we could try and regex this as you're suggesting, but considering we're reinventing the wheel and a copy of the wheel is somewhere in the camera, it'd be nice if we could avoid that.

[qip]

There is a user_config_tz_str_init() function in iCamera's base/paracfg/user_config.c, which seems to parse the timezone string from setup pairing (yeah I figured).

I cannot confirm this right now because my cam has been offline since last check while I was trying to pull iCamera binary for disassembling, and I'm not around to reset it. I believe it's due to /configs wiped out issue (learned the hard way).

Nevertheless, it's unlikely, by itself, iCamera exposes this function, or the specific part of parsing mechanism, into a formattable date string. The wheel is welded, not bolted. (IMO, of course)

[endertable]

Hi, I actually have iCamera and all the Wyze libs open in Ghidra ATM. That function , user_config_tz_str_init(), grabs the value of TZ_STR from /configs/.user_config and writes it to /etc/TZ

[virmaior]

@endertable at least on my camera (old firmware) that's a symlink at /etc/TZ rather than a copy. Did that behavior change at some point?

iCamera is somehow interpreting the more complex TZ values as the system itself doesn't know the time zone

[qip]

Thanks for checking the user_config_tz_str_init() function! @endertable

The symlink is a filesystem feature that open() doesn't really need to worry about, so that writing to the file actually occurs at the linked target.

This function is intended to read config (as the name suggests), so writing to /etc/TZ is an indication of subsequent calling tzset(), which is offered from external libc, in this case it should be the uclibc variant. This wouldn't be able to correctly parse the time zone string in question (time without colon). Hmm... I guess I'll need to go back and redo the pairing process to debug on the hardware.

[jmbulan]

Whoa this thread took off. I really need to set up notifications. I feel bad now that you where so eager to get this figured out and I basically left you hanging.. I really appreciate!

[virmaior]

This pull request (https://github.com/gtxaspec/wz_mini_hacks/pull/727) might help with clobbering if @gtxaspec 's hypothesis is true. Instead of composing the cgi-bin variables every time this makes it so that it composes the once and assumes they don't change between reboots.

I'm not sure what to do on the TZ issue so far. It's possible my cameras are just oddly configured since I haven't opened the wyze app in maybe 18 months or so and my cameras are on an old version.

We can possibly add the TZ resolution code into shared.cgi when it's doing the compose_www_env

[jmbulan]

this means that your camera is not recording video to the SD card.

Either configure it using wyze's app (Risks getting hit with an unwanted firmware update) or try rebooting the camera and see if starts recording.

On my cameras, this happens under one of two circumstances:

1. something has clobbered the /configs directory (currently investigating what could do that)
2. it has just stopped recording (also not sure why -- maybe after it has had a problem with the SD card)

My initial concern was trying to figure out why on some cameras when ever there's motion it just falls flat on its fave and starts lagging and messing up recording. Both have genuine high speed cards (I forget the spec) but would that even matter since we have to format to fat32?

Also I recall around this time last year I bought a two pack of cams and tried setting them up without using the app at all... I think if you put an SD card in they just automatically start recording...

On time where recording has stopped... the app will say the card inserted is 14mb or something way different. I think someone mentioned it was due to leave the connect to winscp on for extended periods.

[virmaior]

On time where recording has stopped... the app will say the card inserted is 14mb or something way different. I think someone mentioned it was due to leave the connect to winscp on for extended periods.

definitely never encountered this but use OSX and am rarely terminaled into the cameras for long.

@qip - instead of parsing the TZ, another option I just thought of his finding the latest file in /opt/record and using that to estimate the shift from UTC. I don't know which approach is better but I've whipped up a version to find the timezone based on the latest file (this would fail if the latest file is not current when the script is first run -- but if the latest file is correct when first run, it will do so correctly)

assuming gtxaspec accepts the pull request, then location for setting the TZ is in /opt/wz_mini/www/cgi-bin/shared.cgi .