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

Live stops working after a while #61

Open
mrTuomoK opened this issue Feb 15, 2020 · 24 comments
Open

Live stops working after a while #61

mrTuomoK opened this issue Feb 15, 2020 · 24 comments

Comments

@mrTuomoK
Copy link

I'm experiencing trouble with the live viewing, it works ok-ish for some time and then stops working at all. The 10s preview in homekit works just fine event after this but the live-viewing doesn't work at all. Only way to fix this is to power off & on the esp32 after which the live viewing works for a while. ANyone else experiencing this and is the a fix for it?

@pocketscience
Copy link

pocketscience commented Feb 21, 2020

I haven't had it die completely requiring a restart, but the stream stop after ~30 seconds - not sure if that's by design. The logs don't indicate any errors, so it certainly looks like the shutdown on streaming is planned. Session command 0 is SESSION_COMMAND_END

13:05:16.462 -> >>> HomeKit: [Client 57] Update Characteristics
13:05:16.462 -> �[0;32mI (1178795) esp32_camera: Processing session command 0�[0m
13:05:19.962 -> �[0;32mI (1178805) esp32_camera: Done sending frame data�[0m
13:05:19.962 -> �[0;32mI (1178805) esp32_camera: Removing streaming session�[0m
13:05:19.962 -> �[0;32mI (1178805) esp32_camera: Stopping video stream�[0m
13:05:19.962 -> x264 [info]: frame I:60 Avg QP:28.95 size: 2300
13:05:19.962 -> x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
13:05:19.962 -> x264 [info]: coded y,uvDC,uvAC intra: 82.0% 81.8% 46.9%
13:05:19.962 -> x264 [info]: i16 v,h,dc,p: 20% 38% 16% 26%
13:05:19.962 -> x264 [info]: i8c dc,h,v,p: 50% 27% 15% 8%
13:05:19.962 -> x264 [info]: kb/s:459.93
13:05:19.962 -> �[0;32mI (1178835) esp32_camera: Done with stream�[0m

@pocketscience
Copy link

pocketscience commented Feb 21, 2020

OK, so after some playing I'm seeing the live stream die as well. Logs show:

13:29:12.650 -> >>> HomeKit: [Client 61] Resource
13:29:12.650 -> �[0;32mI (2627995) esp32_camera: Resource payload: {"image-width":640,"image-height":480,"resource-type":"image"}�[0m
13:29:15.377 -> �[0;31mE (2630725) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:�[0m
13:29:15.377 -> �[0;31mE (2630725) task_wdt: - IDLE1 (CPU 1)�[0m
13:29:15.377 -> �[0;31mE (2630725) task_wdt: Tasks currently running:�[0m
13:29:15.377 -> �[0;31mE (2630725) task_wdt: CPU 0: IDLE0�[0m
13:29:15.413 -> �[0;31mE (2630725) task_wdt: CPU 1: Camera Stream�[0m

The previews continue to come through, but those lines above are flooding the log every few second and going to live view just gives a black screen.

Would invoking the panic handler (via updated config) force a reboot to bring the camera back online?

@pocketscience
Copy link

OK, seems invoking the panic handler has the desired affect... @mrTuomoK suggest you try that and recompiling. The biggest question of course is why the task gets stuck in the first place.

15:09:51.902 -> �[0;31mE (3507105) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:�[0m
15:09:51.902 -> �[0;31mE (3507105) task_wdt: - IDLE1 (CPU 1)�[0m
15:09:51.902 -> �[0;31mE (3507105) task_wdt: Tasks currently running:�[0m
15:09:51.902 -> �[0;31mE (3507105) task_wdt: CPU 0: IDLE0�[0m
15:09:51.902 -> �[0;31mE (3507105) task_wdt: CPU 1: Camera Stream�[0m
15:09:51.902 -> �[0;31mE (3507105) task_wdt: Aborting.�[0m
15:09:51.902 -> abort() was called at PC 0x400d618f on core 0
15:09:51.902 ->
15:09:51.902 -> ELF file SHA256: 6652ce5536cc15ff85edfcce0ad00c74408c4b5b9d447ce44aa82c98eaa39930
15:09:51.902 ->
15:09:51.902 -> Backtrace: 0x4008c40c:0x3ffb0640 0x4008c655:0x3ffb0660 0x400d618f:0x3ffb0680 0x40084fd1:0x3ffb06a0 0x401e1f6f:0x3ffbe5b0 0x400d683a:0x3ffbe5d0 0x40094dc5:0x3ffbe5f0 0x40092ded:0x3ffbe610
15:09:51.902 ->
15:09:51.902 -> Rebooting...

@mrTuomoK
Copy link
Author

Stupid question is how to invoke the panic handler @pocketscience? I'm not that familiar with these esp-coding -things

@pocketscience
Copy link

make menuconfig
Component config->ESP32-Specific->Invoke panic handler on Task Watchdog timeout

@mrTuomoK
Copy link
Author

THX @pocketscience, I'll give it a shot later today :)

@pocketscience
Copy link

Good luck, although it seems pretty stable (apart from the actual issue that's causing the stuck thread in the first place - which I haven't looked into at all) from my testing over the weekend.

@hassbian-ABC
Copy link

I can’t find Invoke panic handler on Task Watchdog timeout @pocketscience

@pocketscience
Copy link

Did you scroll down on the ESP32-Specific page? There's a few pages of options and it's roughly halfway down...

@hassbian-ABC
Copy link

Panic handler behaviour (Print registers and @reboot)

@pocketscience
Copy link

No, keep scrolling :)

@hassbian-ABC
Copy link

[] Make exception and panic handlers JTAG/OCD aware x x
x x [
] OpenOCD debug stubs x x
x x [] Hardware brownout detect & reset x x
x x Brownout voltage level (2.43V +/- 0.05) ---> x x
x x [
] Reduce PHY TX power when brownout reset x x
x x Timers used for gettimeofday function (RTC and high-resolution timer) --x x
x x RTC clock source (Internal 150kHz RC oscillator) ---> x x
x x (1024) Number of cycles for RTC_SLOW_CLK calibration
(2000) Extra delay in deep sleep wake stub (in us) x x
x x Main XTAL frequency (40 MHz) ---> x x
x x [ ] Permanently disable BASIC ROM Console x x
x x [ ] No Binary Blobs x x
x x [ ] App compatible with bootloaders before IDF v2.1 x x
x x [ ] Use fixed static RAM size x x
x x (5) Disable the interrupt level for the DPORT workarounds @pocketscience

@pocketscience
Copy link

Screen Shot 2020-03-27 at 6 54 28 am

@hassbian-ABC
Copy link

thanks,but i can not find it @pocketscience

@tiagokall
Copy link

tiagokall commented Mar 28, 2020

@hassbian-ABC I couldn't find it by the instructions above as well (updated esp-idf today), but if you type "/" you can search for "invoke panic" and you'll find it.

Edit:
This setting is on Component Config > Common ESP-related

@patafix18
Copy link

Same issue here. The panic handler solves the issue but the esp restarts every 10-20s due to the panic handler. Is there a bug fix of the real problem which involves the panic handler available?

@cgmckeever
Copy link

@tiagokall NICE CALL

Just got this up and running, experiencing the same issue, and this rectified, but now reboots constantly. Any status/thoughts/updates on this?

@cgmckeever
Copy link

I just tried one of the non-homekit streamers, and no dropping/rebooting. Im sure there are many layers to peel back to look at the WHY of this.

@maximkulkin
Copy link
Owner

@cgmckeever contributions are always welcome!

@cgmckeever
Copy link

I def want to roll up my sleeves ... and I may, I just need to digest it, there are a lot of moving parts. But its has me very curious

@florianrehm
Copy link
Contributor

florianrehm commented Nov 28, 2020

Any updates regarding this issue?
I have the same behavior on m5stack TimerX camera - Session command 0 is received after approx. 20s.
If I comment out the section in the switch block, the watchdog goes into timeout.

@andy899
Copy link

andy899 commented Dec 31, 2020

Live works, but after a while HomeKit: [Client 56] Update Characteristics, live stops. If try to switch between picture and live severl times, total free memory(esp32_camera: Total free memory: 1729159) shows less and less, then panic, possible memory leak on streaming.c?

@florianrehm
Copy link
Contributor

I finally found the root cause of the issue and fixed it in #84

@florianrehm
Copy link
Contributor

There are still some additional tweaks needed to avoid the watchdog being triggered after some minutes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants