Found a bug from a mouse screenshot - incorrect thumbnail watermark timestamp

denven commented 5 months ago

Background: I saw some animal paw prints in the snow in the yard this morning, and I was very curious about which guy had visited last night. Then I checked the uploaded files from my OneDrive folder and the existing files in the camera SD card as well. To my surprise, I found a mouse in the camera video thumbnail file. The interesting thing is that this also gave me a chance 👀 to identify a bug.

The bug appears in the bottom right corner of the thumbnail, the timestamp is not the correct time from its original video file. The camera time is 20:29 (the minute time is from its filename 29M04S56.jpg grabbed from video file 29M04S56.mp4) while this timestamp put in the screenshot shows 20:37. The time difference is around 8 minutes.
BTW: I take the thumbnail jpg file as a screenshot since it is picked from the recorded video file by the Yi-hacked integrated program imggrabber, and the timestamp is added to the file by this program.

roleoroleo commented 5 months ago

This is very very strange. But I don't understand what I'm looking at. Is it a frame of the mp4 or the related jpg. Because the timestamp shouldn't appear in the video.

Another question: which version are you using?

denven commented 5 months ago

This is very very strange. But I don't understand what I'm looking at. Is it a frame of the mp4 or the related jpg. Because the timestamp shouldn't appear in the video.

Another question: which version are you using?

It's a jpg file, you can see the red border marked filename not sure if you can get some clue by checking imggrabber.c and thumb.sh

roleoroleo commented 5 months ago

You are right. The thumbnail is created from the mp4 file but the watermark is added with the wrong time. Is the time when imggrabber is executed and not the time related to the content of the video file. To fix this problem, I need to change imggrabber.

denven commented 5 months ago

@roleoroleo some ideas about the thumb.sh and imggrabber performance:

current situation

it seems this thumbnail feature is cpu expensive, on my camera, it costs about 10% cpu usage
thumb.sh will run every minute, and imggrabber has delay in grab frame to generate jpg file (like about 8 minutes in this bug)

question

what's the most time cost for imggrabber? why there is too much delay when grabbing the thumbnail file?

probably it is caused by the checkFiles() in thumb.sh : echo "${L_FILE_LIST}" | while read file; do

my thoughts

evaluate imggrabber process time and tune SLEEP_CYCLE_SECONDS to ensure imggrabber can be called every minute,
use the lastest 2 minutes to find and grab the latest (0/1/) 2 video file(s) to avoid too much delay, do not find and check from all
- 2: one new video file generated and another old one is not processed in time due to time deviation (less likely)
- 1: one new video file generated and not processed at the last minute, the old file is checked and processed
- 1: no video file generated for the last minute, another old one is not processed in time due to time deviation (less likely)
- 0: no video file generated for the last minute, all recent files in 2 minutes are processed

by doing this, the delay is only 1 minute or none.

roleoroleo commented 5 months ago

I already trying to change the code. The solution I'm trying is very simple. imggrabber accepts a new option useful to pass the timestamp manually. So the script thumb.sh can call imggrabber and pass the value derived from the file name. https://github.com/roleoroleo/yi-hack-MStar/commit/040c90af1e069d0b4b21082b7880ada2a064e718

If you want to test it: thumb.sh.gz imggrabber.gz

denven commented 5 months ago

I replaced the two files and rebooted the camera, which resulted in the camera running into an infinite reboot loop. perhaps the cause is I didn't change the overwritten files permission. Then I hacked the camera with version 0.54 firmware, I previously used 0.49.

have to find another time to test again.

denven commented 5 months ago

tested, the time minute is close to the jpg filename, but it is always a little greater (no more than 2 minutes) than it.

Update: Not true, the above is the previous grabber created time which has delay.

The new grabber has the right time, however it doesn't show the local time, uses UTC time instead.

I have setup the time zone string, however the folders are still organized with UTC time.

roleoroleo commented 5 months ago

Yes. The last version fixes a very old bug related to the time. Now the cam uses the correct timezone (localtime). But I changed all other pages and features related to the time, so the only difference is the time of the folder structure in /tmp/sd/record. I hope...

denven commented 5 months ago

Yes. The last version fixes a very old bug related to the time. Now the cam uses the correct timezone (localtime). But I changed all other pages and features related to the time, so the only difference is the time of the folder structure in /tmp/sd/record. I hope...

By adding and using get_timestamp function (convert UTC time to local time), we can put local time into the thumbnail file.

Or if possible, use the function to generate the video folder names by using local datetime, then no need to change thumb.sh.

# input sample: /tmp/sd/record/2024Y01M24D09H/24M00S60
# will output: 2024-01-24 09:24:00
get_timestamp() {
        local_time=$(date +"%Y-%m-%d %H:%M:%S")
        utc_time=$(date -u +"%Y-%m-%d %H:%M:%S")

        local_ts=$(date -d "$local_time" +%s)
        utc_ts=$(date -d "$utc_time" +%s)

        local_utc_offset=$((local_ts-utc_ts)) # seconds

    # get utc time path without minute: 2024Y01M24D09H
        # utc_path=$(echo $1 | grep -oE "[0-9]{4}Y[0-9]{2}M[0-9]{2}D[0-9]{2}H")
        # utc_path_ts=$(date -d "${utc_path:0:4}-${utc_path:5:2}-${utc_path:8:2} ${utc_path:11:2}:00:00" +%s)
        # local_path_ts=$((utc_path_ts+local_utc_offset))

        # output local date path: 2024Y01M24D01H
        # echo $(date -d "@$local_path_ts" +"%YY%mM%dD%HH")

    # get utc time path with minute and second: 2024Y01M24D09H24M00S
        utc_path=$(echo $1 | grep -oE "[0-9]{4}Y[0-9]{2}M[0-9]{2}D[0-9]{2}H/[0-9]{2}M[0-9]{2}S" | tr -d "/")
        utc_path_ts=$(date -d "${utc_path:0:4}-${utc_path:5:2}-${utc_path:8:2} ${utc_path:11:2}:${utc_path:14:2}:${utc_path:17:2}" +%s)
        local_path_ts=$((utc_path_ts+local_utc_offset))

        # output local time: 2024-01-24 09:24:00
        echo $(date -d "@$local_path_ts" +"%Y-%m-%d %H:%M:%S")
}

checkFiles ()
{
    ....
            # TIME_STAMP="${file:15:4}-${file:20:2}-${file:23:2} ${file:26:2}:${file:30:2}:${file:33:2}"
            TIME_STAMP=$(get_timestamp "$file")
    ....
}

roleoroleo commented 5 months ago

By adding and using get_timestamp function (convert UTC time to local time), we can put local time into the thumbnail file.

Sorry but I don't understand. The time in the thumbnail jpeg should already be localtime. Is it in UTC for your cam?

Could you try to switch on the option "Enable/disable time OSD" and check the time in the upper left corner? immagine

roleoroleo commented 5 months ago

A little fix here: imggrabber.gz Not related to the timezone.

denven commented 5 months ago

By adding and using get_timestamp function (convert UTC time to local time), we can put local time into the thumbnail file.

Sorry but I don't understand. The time in the thumbnail jpeg should already be localtime. Is it in UTC for your cam?

Could you try to switch on the option "Enable/disable time OSD" and check the time in the upper left corner?

Running the latest imggrabber and turn on OSD option:

when OSD is enabled, I can see the local time in the upper left corner for the live video stream, this is really a great enhancement
however, unfortuately, when it is enabled, I find the camera stops to record new video files
once I disable it, video files can be generated, but the time on the thumbnail pic is still in UTC, not my local, and it has delay to generate thumbnail jpg files as well.

The delay is likely caused by the cron job of thumb.sh execution every minute, and it loops and check all mp4 files which will cost more cpu time. there is already a while true loop in thumb.sh, and it will keeps 2 processes running thumb.sh, maybe keeping one is enough, and do not need to start it as cron job. I change thumb.sh with above code I pasted here and I change only to check the latest 2 mp4 files, there is no delay of thumbnail files generation after mp4 files created (although 2 thumb.sh processes are still running).

roleoroleo commented 5 months ago

How is the time in the snapshot (from web gui for example)?

The delay is likely caused by the cron job of thumb.sh execution every minute

thumb.sh is executed with a delay, but, if you are using the version I posted above, when it runs imggrabber it passes the timestamp as an argument:

...
TIME_STAMP="${file:15:4}-${file:20:2}-${file:23:2} ${file:26:2}:${file:30:2}:${file:33:2}"
imggrabber -f $BASE_NAME.h26x -r low -w -t "$TIME_STAMP" > $BASE_NAME.jpg
...

thumb.sh reads the time from the name of the file (and the dir) and passes it to imggrabber. Imggrabber uses this time to print the watermark. Since the image is extracted from the first frame, the time of this frame is the same as the time extracted from the name of the file.

denven commented 5 months ago

How is the time in the snapshot (from web gui for example)?

The delay is likely caused by the cron job of thumb.sh execution every minute

thumb.sh is executed with a delay, but, if you are using the version I posted above, when it runs imggrabber it passes the timestamp as an argument:
...

TIME_STAMP="${file:15:4}-${file:20:2}-${file:23:2} ${file:26:2}:${file:30:2}:${file:33:2}"

imggrabber -f $BASE_NAME.h26x -r low -w -t "$TIME_STAMP" > $BASE_NAME.jpg

...
thumb.sh reads the time from the name of the file (and the dir) and passes it to imggrabber.

Imggrabber uses this time to print the watermark.

Since the image is extracted from the first frame, the time of this frame is the same as the time extracted from the name of the file.

currently, the time in thumbnail is correct after using your new imggrabber. However, it is still in UTC time. z The video records directories are orgnized in UTC date hour time. do you convert the time to local timezone in imggrabber?

roleoroleo commented 5 months ago

Something is wrong, I don't understand. With the last release, the file/folder structure in /tmp/sd/record should be oganized in local time. Not in UTC.

I will send a whole image to test.

denven commented 5 months ago

Something is wrong, I don't understand. With the last release, the file/folder structure in /tmp/sd/record should be oganized in local time. Not in UTC.

I will send a whole image to test.

I noticed that the record folders' naming was changed to UTC since version 0.49 or earlier. I thought it was a universal change since that version, so that's why I had to write the time conversion code to handle this.

I am not sure which setup of mine is not correct or if some other thing is wrong at my end because you've already adjusted this.

roleoroleo commented 5 months ago

This commit (included in 0.5.4) changes the behavior of the cam. The cam should work in localtime and save the files/folders in localtime. I don't understand why your cam works in UTC...

A question. What time does the cam use when cloud is on?

denven commented 5 months ago

from the Yi App stream, the OSD time is local. I think I never turned off the official cloud feature, although I don't use their cloud storage plans.

denven commented 5 months ago

@roleoroleo I've mentioned that the camera stops to record video files in the previous issue discussion as well.

And it is not true, it is recording files, and using the local time to do it, the files in utc-time directories are overwritten by the new files.

So now the issue is when OSD is disabled, the camera still uses UTC time to organize folders.

Another issue found after OSD is enabled, it still has a chance to create folders in UTC time., I found this in the noon a several hours later folder was created of a sudden, and confirmed it existed on SD card from that time.

denven commented 4 months ago

after several days of use the latest version, the timestamp on thumbnail file still doesn't match the osd time,delayed by hours.

roleoroleo commented 4 months ago

Check this issue: https://github.com/roleoroleo/yi-hack-MStar/issues/436

github-actions[bot] commented 1 month ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

roleoroleo / yi-hack-MStar