Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

YHS3017 RFUSY keeps crashing #573

Closed
grochib opened this issue Feb 2, 2023 · 9 comments
Closed

YHS3017 RFUSY keeps crashing #573

grochib opened this issue Feb 2, 2023 · 9 comments
Labels

Comments

@grochib
Copy link

grochib commented Feb 2, 2023

Hello everybody,

I successfully could hack my second yi outdoor camera with the allwinner-v2 hack h30ga. My first outdoor cam YHS3017 IFUSY works flawlessly.

Unfortunately, the 2nd cam keeps on crashing irregularely: the picture in motioneye turns grey and when trying to reach the built-in webserver 192.168.178.xxx:8080 the browser can not load it. After a while the picture reappears and so does the webserver of the cam.

I already changed the power supply from 5V 2A to 5V 3A (both are of high quality, industrial standards).

I'm using this cam only with rtsp stream in low quality and audio aalw to be recorded and shown in motioneye. I then use the built-in webstreaming embeded url of motioneye (with the url from the motioneye-server) to be forwarded to home assistant.

As mentioned before, the first cam (without recording and without audio stream though but still mounted in motioneye) does work flawlessly.

On a side note: the same happened with a yi home hd camera (IFUSY with allwinner hack) before. But as mentioned: I changed the power supply. The only two things similiar are the mounting spot as we as the power lines to the power supply.

Now I was wondering how to search for the problem? What logs should I try to look in to?

Thank you so much for your help!

All the best to everyone!

@roleoroleo
Copy link
Owner

Try to enable swap file or disable snapshots.

@grochib
Copy link
Author

grochib commented Feb 2, 2023

I have done both already. The sd card is new on both cams.

@grochib
Copy link
Author

grochib commented Feb 2, 2023

just to be precise: all my cams are mounted on the same motioneye instance. From there some cams are shown either in home assistant (embeded url, so not the ip from the cam itself) or on two tablets showing the motioneye interface. Therefore, the cams are actually accessed by only one client, am I right? motioneye is providing the "multicast", correct?

I was wondering if there is too much drain (by too many clients maybe) on the cam, but again it is only rtsp stream to motioneye, the rest is happening within motioneye

@roleoroleo
Copy link
Owner

just to be precise: all my cams are mounted on the same motioneye instance. From there some cams are shown either in home assistant (embeded url, so not the ip from the cam itself) or on two tablets showing the motioneye interface. Therefore, the cams are actually accessed by only one client, am I right? motioneye is providing the "multicast", correct?

Yes, correct.

Does the cam reboots when it crashes?
Check the uptime.

Try to use the original power supply and cable. I've seen this behavior before.

@grochib
Copy link
Author

grochib commented Feb 6, 2023

Hello roleoroleo,

thanks again for all the help you are giving to so many people. Its amazing what you are accomplishing here!

The rtsp stream just crashed again (showing a grey screen in motioneye) for 5-10 seconds. I did a screenshot of the index page of the camera moments after to show that the camera was up for several days - so no rebooting during/after the rtsp stream crash (as I said: during the crash the website of the cam is not really reachable, it loads until the stream is back):

tempsnip

About the power supply/cable: indeed, in both cases I'm using (rather high quality and expensive) 5V power supply, but not an USB charger but an internal power supply I added a female USB-A mount: https://www.amazon.de/dp/B00MWQD43U?psc=1&ref=ppx_yo2ov_dt_b_product_details (I tested the output and it was perfectly according to specs, according to amazon a lot of people are having good experiences with). And to be honest: I dont know where to find the original chargers anymore... :)

@grochib
Copy link
Author

grochib commented Feb 6, 2023

there is the output of top:

screenshot

in the yi-hack-MStar github I found someone else having a similiar problem, but he didnt post a solution: roleoroleo/yi-hack-MStar#149 (comment)

@grochib
Copy link
Author

grochib commented Feb 6, 2023

There is one factor which might influence the problem: I'm using a wifi mesh network with a fritzbox 7590 and two fritzrepeater 3000. The fritzbox is in the basement (basically almost under the house entrance), the two repeater are on ground floor and 1st floor.
Only the two cameras (and two tasmota switches as well as a ESP cam which is also loosing the stream frequently, but actually due to some heat problem) are connected to the fritzbox directly. All the other trafic (including my 2nd yi outdoor camera) are using the repeater. Now I was wondering: could that reason some problems?
See my mesh overview below:

tempsnip2

I just followed the mail man with both cameras (with the issues) as well as with the third camera (no issues at all). I realized that the video stream of the two problematic cameras were lagging, and freezing: it didnt show any problems but then I realized seeing the mailman walking in the third (unproblematic) camera that the video stream of cam 1 and 2 (still showing the mail man standing in front of the door) that the stream must be frozen.

by the way: both problematic cameras have the audio stream enabled (alaw), the third one has it disabled!

@roleoroleo
Copy link
Owner

What happens if you move one of the non-running cameras under the repeater?

by the way: both problematic cameras have the audio stream enabled (alaw), the third one has it disabled!

There could be a problem with the sync between audio and video. Please, try to disable audio.

@stale
Copy link

stale bot commented May 10, 2023

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.

@stale stale bot added the stale label May 10, 2023
@stale stale bot closed this as completed Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants