Is the "YI Pro 2K Home" supported?

[evider2002]

Hi all,

I have the hack working well on all my Yi home 1080p cameras, but I wanted to upgrade to the "YI Pro 2K Home" to increase resolution from 2MP to 3MP. Does anyone know if the hack will work on that camera?
Here is a link to this camera - YI Pro 2K Home

Thank you in advance.

[roleoroleo]

Please check the fw version in the app.

[vprotsaylo-banking]

@roleoroleo
I have this camera at hand and here is what is written on its back: ZFUSY94P2X (Model: YYS.62121)
May be that information will help to identify the fw version

[vprotsaylo-banking]

My FW he FW versions are the following
Current: 12.0.51.01_202303091901
Available: 12.0.51.08_202403081746

[evider2002]

Thank you for your response roleoroleo.

When I asked, I didn't have the unit, that's why I was asking...
By now I already have the unit, so I will begin testing, to see if I can get the hack to work.

FW version is: 12.0.51.01_202303091901, that is what came preinstalled, and there are no updates..

[evider2002]

I just tested the hack on YI Pro 2K Home (y623), and whatever I tested seems to be working except for RTSP.
I am attaching the backup, can you please see if you can fix the RTSP?
Thank you.
y623_backup.zip

[evider2002]

It is also not working with RTSP alternative server.

[roleoroleo]

At the moment the cam is not supported.
I will check your backup files.

[evider2002]

And I also tried this rRTSPServer file #678 (comment) which did not work either.

[roleoroleo]

I need a copy of the file /dev/shm/fshare_frame_buf to check the format of the stream.

[evider2002]

Attached is the fshare_frame_buf file. Thank you.
fshare_frame_buf.zip

[roleoroleo]

The file is empty (all 0).
Can you repeat the copy?

[evider2002]

Sorry about that, I copied the file when RTSP was off...
Here it is again:
fshare_frame_buf (2).zip

[evider2002]

Another issue besides for RTSP not working, is that the camera freezes when the hack is installed. The video files that the camera produces are very choppy, incomplete, freezing, ghosting etc... It seems that the the hack is overexerting the system resources. On my y291ga cameras, I am getting something like this - "Free/Total Memory 26896/60908 KB". And on y623ga, I am getting "Free/Total Memory 18376/60912 KB", and that is after turning off everything possible on web (even the camera itself.) It seems that just to keep the actual os powered on without any running services, is already using up all resources.

[roleoroleo]

This is a big problem.
Probably rmm process keeps busy most of the memory.
In this case there are no solutions.

[roleoroleo]

Here it is:
bins.tar.gz
The archive contains the beta release of the binaries: RTSP server and snapshot.
Please overwrite the current files in /tmp/sd/yi-hack/bin

[roleoroleo]

lower_half_init.sh.gz

And overwrite this file in the root folder of your sd card.
This could fix the memory problem.

[roleoroleo]

Another detail: edit the file /tmp/sd/yi-hack/model_suffix with the correct model.

[evider2002]

Should it be y623 or y623ga?
Gonna work on all your instructions now..
Thank you!

[roleoroleo]

Just y623

[evider2002]

Also, I have some more info on what is causing the freezing video / memory issue, but I need your expertise to solve it:

In a healthy situation, the camera records the video files to - sd/record/2023Y10M15D06H as a 1 minute clip, but before the full minute is up, a temporary file called tmp.mp4.tmp is put in sd/record and then when the minute is up, the file gets finished up as W400M00S60.mp4 and put into sd/record/2023Y10M15D06H. (This is just an example of the hour an minute...)

This is also how y623 works without the hack. However, when I install the hack, instead of one file being active at a time, there are 2 active files recording at the same time. One file is in sd/record as tmp.mp4.tmp and the second file is in sd/record/2023Y10M15D06H as W405M01S59.mp4. When the minute is up, the tmp.mp4.tmp file gets finished as W405M16S44 and also put in to sd/record/2023Y10M15D06H. So instead of having 60 files in each folder, I have about 120. Each minute is getting randomly split in to 2 files. In a health situation, one file is generated per minute, with the file suffix always being 00S60 - representing the seconds. In this situation, 2 files are generated per minute, with the file suffix being random seconds.

[roleoroleo]

The behavior should be:

• the cam creates the temporary file /tmp/sd/record/tmp.mp4.tmp where the stream is stored
• at the end of the minute the file is closed and moved to the folder of the day
• the 2 digits after 'M' are the second when the record is started
• the last 2 digits are the duration of the stream in seconds
• 3rd and 4th digits are the minute

If you have 2 files with the same minute is not correct.
Check if there are 2 mp4record processes running.

[evider2002]

So I did tons of testing the past few days, and this is what came out.
The beta binary file you sent - rRTSPServer, fixes the RTSP stream. The other beta binary files you sent, are not necessary to fix the RTSP stream.
The memory / corrupted video issue was not fixed with any of your instructions. I tried your new lower_half_init.sh file, and edited model_suffix to the correct model, neither fixed the issue.
But I have a lot more info on the corrupted / double file video issue (as I explained in my last comment.)
Once I installed the hack, I could not fix the video corruption issue even after uninstalling the hack and resetting the camera. There was nothing I could to to get the video to work again. So I very cautiously began testing a second new unit. First I checked the video files, before attempting the hack, to confirm that the unit is working properly before any hack. Indeed, the video was working fine, no corruption and only one file per minute. I then tried installing the hack without the factory folder (only yi-hack folder & lower_half_init.sh file), as I already had a backup from the first unit. However the hack would not install, I cold not access the web page, SSH etc... I then installed only the factory folder to create a backup, but I did not install the hack (not the yi-hack folder & not the lower_half_init.sh file.) Then I checked the video file (still before hack) and indeed it was corrupted. I then installed the hack, and it was working but still with the corrupted video. I then discovered how to fix the corrupted video issue - by restoring from the backup. I put backup_y623 and home_y623 files in the root of the sd card. This returned the camera to recording normal video, but now the hack was not working again.
So in summary: the hack is not causing the corruption, what is causing the corruption is the creation of the backup, which is necessary for the hack to work. Restoring from the backup fixes the corruption, but then the hack wont work.

What advice/suggestions can you offer at this point?
Have you ever experienced anything like this on any of the other cameras?
Is creating a backup necessary for the hack to work on the other cameras, or is it just to have a backup in case...?

Thank you.

[roleoroleo]

So I did tons of testing the past few days, and this is what came out. The beta binary file you sent - rRTSPServer, fixes the RTSP stream. The other beta binary files you sent, are not necessary to fix the RTSP stream.

You are right:

• h264grabber is not used with your configuration
• imggrabber is the program to take a snapshot

The memory / corrupted video issue was not fixed with any of your instructions. I tried your new lower_half_init.sh file, and edited model_suffix to the correct model, neither fixed the issue. But I have a lot more info on the corrupted / double file video issue (as I explained in my last comment.) Once I installed the hack, I could not fix the video corruption issue even after uninstalling the hack and resetting the camera. There was nothing I could to to get the video to work again.

What do you mean with memory corrupted video?
The mp4 files stored in /tmp/sd/record or the real time stream?

So I very cautiously began testing a second new unit.

If there is a problem you can restore the factory fw using the backup you made.

I then tried installing the hack without the factory folder (only yi-hack folder & lower_half_init.sh file), as I already had a backup from the first unit. However the hack would not install, I cold not access the web page, SSH etc...

This is normal.

I then installed only the factory folder to create a backup, but I did not install the hack (not the yi-hack folder & not the lower_half_init.sh file.) Then I checked the video file (still before hack) and indeed it was corrupted. I then installed the hack, and it was working but still with the corrupted video.

The script inside the Factory folder changes the file /backup/init.sh to run /tmp/sd/lower_half_init.sh
This is the only change.
Please send me a copy of /backup/init.sh if you have it.

I then discovered how to fix the corrupted video issue - by restoring from the backup. I put backup_y623 and home_y623 files in the root of the sd card. This returned the camera to recording normal video, but now the hack was not working again.

This is normal.

So in summary: the hack is not causing the corruption, what is causing the corruption is the creation of the backup, which is necessary for the hack to work. Restoring from the backup fixes the corruption, but then the hack wont work.

This is not completely true, as I wrote above the script contained in the Factory folder changes a file in the cam.

What advice/suggestions can you offer at this point? Have you ever experienced anything like this on any of the other cameras? Is creating a backup necessary for the hack to work on the other cameras, or is it just to have a backup in case...?

Maybe there is an error in the script.
Please send me a copy of /backup/init.sh
And try to run a ps command in the hacked cam.

[evider2002]

Thank you for your detailed response.

I want to clarify the video corruption issue I am describing:
Once I install Factory folder, the cam records 2 real time stream files at the same time simultaneously.
The first one is the correct one - /tmp/sd/record/tmp.mp4.tmp.
The second one is in the folder of the hour, where the first/correct temp file moves to when it is closed. This second real time stream file name does not have .tmp at the end, it has the same name and location as the closed file - /tmp/sd/record/2023Y10M19D06H/W405M01S59.mp4. So this second real time stream file does not go through any change when it closes, not a change of name, nor a change of location.
The way I know that both of these are real time streams, is because they become larger in size as the minute progresses, and then start out again at 0kb when the new minute begins. And yes, there are 2 mp4record processes running. The result of this, is that I have 2 closed files for every minute in the hour folder - /tmp/sd/record/2023Y10M19D06H, one that came from /tmp/sd/record/tmp.mp4.tmp when it was temporary, and then a second one that was all along in /tmp/sd/record/2023Y10M19D06H/W405M01S59.mp4, even when it was temporary. So there are 120 files per hour instead of 60. These videos are terribly frozen/choppy, and can be out of order, where I will see an earlier time stamp later in the video, after already seeing a later time stamp earlier in the video
My understanding is, that this is why the closed videos are corrupted, because there were 2 files fighting for the live stream, so each one just gets randomly about half the frames of the minute.
This is also my understanding of why there is a low memory issue, because there are 2 recording processes active that are fighting with each other.

I am attaching an example of a corrupted 2 videos from 1 minute, /backup/init.sh file, ps command & a screen shot.

Thank you.
Corrupted video.zip
init.sh.zip
ps.txt
Capture176.JPG

[evider2002]

Further testing:
I killed one of the mp4record processes, and Bingo! Problem solved. Only one file recording.
The issue is, that when the camera is restarted, both mp4record processes come back on, and there are again 2 files recording.
Do you have a solution to have only 1 mp4record process running on startup without killing, so that there should only be one even after restart?

By the way, there is still low memory (Free/Total Memory 15560/60912 KB) even after killing and having only one mp4record processes running. On my other cameras (y291ga) the memory is much better (Free/Total Memory 28892/60908 KB.)
Is this an issue? (I have Swap File enabled on both.)

One more question: are the backup files generated from the script in Factory folder unique/custom to each device/serial, or are they interchangeable with any device of the same model?

Thank you!

[roleoroleo]

I have to check the code to find the problem about mp4record.
When i write real time video I mean RTSP stream, is it correct?

One more question: are the backup files generated from the script in Factory folder unique/custom to each device/serial, or are they interchangeable with any device of the same model?

mtd6 and mtd7 are different for each serial.
other partitions are equal for each model suffix.

[evider2002]

No I don't mean RTSP, you already fixed that with beta rRTSPServer.
When I say realtime/live stream, I mean - "/tmp/sd/record/tmp.mp4.tmp, or /tmp/sd/record/2023Y10M19D06H/W405M01S59.mp4 (when there are 2 mp4record processes.)

[roleoroleo]

mp4record is started from system.sh and cannot be run twice.
Unless system.sh is run twice.
Post your init files:

cat /tmp/sd/lower_half_init.sh
cat /backup/init.sh

[evider2002]

I attached /backup/init.sh here: #721 (comment)
And I am using /tmp/sd/lower_half_init.sh that you sent here: #721 (comment)

[roleoroleo]

Found.
Your init.sh contains 2 lines with source /home/app/lower_half_init.sh
Please remove the 1st one.

[evider2002]

Deleting the first source /home/app/lower_half_init.sh does fix the duplicate mp4record process issue (and all the other duplicate processes).
However, now HTTPD does not work, SSH still does.
I double checked /tmp/sd/yi-hack/etc/system.conf and it is set to - HTTPD=yes.
When I put back in the duplicate line, HTTPD works again.

[roleoroleo]

Please, try to reinstall the hack.
Format the sd card and restart from scratch.

[evider2002]

That worked @roleoroleo !
I can now confirm that public release 0.2.9 works on y623 with 2 minor tweaks:
A- Editing init.sh per your instructions here #721 (reply in thread), and
B- Replacing rRTSPServer with your beta version here #721 (comment).
You can add y623 to the list of supported cameras.

Thank you!!!

[roleoroleo]

Ok, I will add this model to the supported cams.
Thank you for your tests.
Issues A and B won't happen with the official release.

[roleoroleo]

The last question.
What the 4 start digits of the serial number?
SFUS, BFUS, ...?

[evider2002]

RFUS

[isibizi]

I have the same cam, when i install the hack, the first start is ok, when i change something in the config, the cam freezes.

[nemonoid]

@evider2002 out of curiosity, could you please post the output of cat /proc/cpuinfo of the 2K model ?

I'm curious to see if it's the same exact chipset of the 720P and 1080P version :-)

How is it the image quality by the way ?

[evider2002]

Here it is.

Regarding image quality, a few points:
A: This unit suffers from image ghosting, primarily at night / dark situations. Yi provided a firmware update to address specifically this issue. The update did help a bit, but it is still not perfect.
B: Even though the resolution of this camera is 3mp, you don't actually get that much more picture resolution than the y211ga (2mp), because the FOV is greater. The majority of the increased 1mp goes towards the extra FOV, but there is a slight increase of resolution in the areas of FOV that they share.
C: Regardless of resolution, the overall picture quality is probably a bit better. The picture interpterion of the scene, is probably a bit better.
D: File size for y623 is about 3 to 4 times larger than y211ga. It should only be 50% larger, as the resolution is only 50% more. I guess this is a CPU limitation, as compressing a higher resolution stream is more taxing on CPU. If you want the same amount of storage time on your card, you will have to get a card 4 times larger. (I went from 64GB to 256GB).

As noted, my comparison/frame of reference, is against the y211ga, which is the other Yi cameras I have.

I'm happy to answer any other question...

[nemonoid]

OK, I can confirm that it's the same CPU of my 1080P y291ga / RFUS.
From various info I believe it's a single-core ARMv7 at 816Mhz, altough most of the encoding work is done by a hardware encoder.

Thank you very much for the detailed review.

It seems that YI is managing to keep the prices low by reusing the same platform, but they are getting close the limits...

[roleoroleo]

It seems that YI is managing to keep the prices low by reusing the same platform, but they are getting close the limits...

Very close...

[DvsionByZro]

I have a ZFUS model. Any info about wether it will also be supported? I'm willing to test if needed.

[roleoroleo]

Maybe it's already supported.
Let me know the fw version.

[DvsionByZro]

Firmware version is 12.0.51.01_202303091901

[roleoroleo]

You could try y623.
It should work.

[DvsionByZro]

y623 is working fine for a few days. Thanks!

[oguime]

y623 is working but I don't get a Low Res stream...
YFUS with FW: 12.0.51.01_202303091901
Any hints?

[roleoroleo]

Send me a copy of the file /dev/shm/fshare_frame_buf

[oguime]

fshare_frame_buf.zip
Thanks!

[oguime]

By the way, I see occasional errors when using the high def stream on go2rtc 1.8.4 under on frigate 0.13.2:

2024-08-09 12:17:49.257931871 09:17:49.257 WRN github.com/AlexxIT/go2rtc/internal/streams/producer.go:171 > error="read tcp 172.18.0.2:60236->192.168.20.57:554: i/o timeout" url=rtsp://192.168.20.57:554/ch0_0.h264

Not sure this could be related to yihack in any way...

Thanks,
Gilson

[roleoroleo]

The frame_buffer is ok.
It should be properly handled by the rtsp server.
I need a log.

• Kill rRTSPServer process
• Run it with a full debug option "-d 15"
  rRTSPServer -m y623 -r both -a no -d 15
• Start the rtsp client
• Send me the output log

[oguime]

Hi,

Sorry, I don't remember manually changing anything, but for some reason the RTSP Stream option was set to High instead of Both...

The Low Res Stream is working fine! Thanks for your support.