Closed vrurg closed 3 years ago
Is that a V2 Camera @vrurg ? I Had the same issue in #98 but the updates that @HclX added last week fixed it.
It is v2, yes. I saw the other issue. But it ends with fixes merged to master, and the master is what I use. So, I guess this time it's something different.
@vrurg - i never installed the master branch - you can try the "bugfixes" branch - that's the one i think i'm running. Just in case?
Will try later today or tomorrow. Though I think I saw the merge in the git log.
As I expected, bugfixes
branch is no different from master
, git diff
confirms it. Re-installation from bugfixes
also didn't change the situation.
Master has the latest change. This is strange as I tested on a couple of v2 cameras running on this version firmware. I will come up with some instructions for debugging tonight.
@vrurg Here is what I would do to debug what's going on:
Your NFS share still works, so if you have log sync enabled, you should see logs under
You should still have telnet access to the camera. Try telnet into the camera and run the following command and paste the output here:
cat /proc/`pidof iCamera`/environ
ls -l /tmp/wyze_hack/run/bin/
cat /system/init/app_init_orig.sh
* he first couple lines shows the versions, check what's the "WyzeApp" version and "WyzeHack" version
Ok, this is where I should've started from the beginning. It was v0.5.02 to start with and that I should've noticed from the beginning. Now I see what happened: I didn't know that the firmware binary is not part of the repository and that it is updated with build.sh
.
So, no problem here. Closing. Thank you!
I just have realized today that my cameras do not record on NFS due to the updated firmware. So, updated the
master
and re-installed. Got telnet and NFS back but the camera still doesn't consider it as SD.Here is my config, the same used on all cameras. Apparently, some sensitive info removed.
With this config I do have NFS mounts alive:
They're writable. There is no issue here. But what is curios is this excerpt from boot log:
I think the problem should be hidden behind the
sendto failed
line. I have traced it down to the location in the main.sh script and tried to reproduce it manually:Unfortunately, I don't have time to analyze it any further.