Stream wont reliably start in AP mode without serial connection.

[git512]

Have tested with 2 modules, different cables and power sources. Works great connected to external AP. Works great with internal ap mode if the gnd tx and rx are connected to ftdi. Only gnd connected to ftdi does not work. Have no idea where to start debugging this.

[easytarget]

Interesting; I'm 99% certain there is no code related reason for this. The code here does not care whether there is anything receiving the serial output, none of my module have serial connected by default when in actual use.
But.. I'm going to have a quick test and see if I can reproduce this, simple enough to do and it's piqued my interest.

[git512]

Not sure if this info is relevant (i.e. memory related?) or not: 3 SSID/password combo's were supplied in a myconfig.h . Testing was done with a 2.1A wall plug, an Anker 20,000 mAh powercore battery bank, and my laptop's USB3 port (through an ftdi adapter). Tests were done in a park in a small town but many SSID's are 'visible' from this park.

Also to note: still images worked great the entire time but the "stream" functionality did not (displayed missing image icon) in both chrome and firefox on my linux laptop and chrome on my android.

Thank you very much for your time and if you have any ideas for me to try please send them along.

[ddTech]

I'm experiencing the same behavior, but it is not related to no serial communication, as I can reproduce it with serial connection as well. I have not yet further investigated it, but here are my observations. I think that already might lead into the right direction:

I compiled the project as is, i.e. with the default settings and uploaded it to the ESP32-CAM (AI Thinker).
I connect and use it with an iPhone. At first everything seemed to be fine. I got the stream and then, sometimes not, just the red "x". When I first experienced that I had just lowered the quality to miniumum and saved the settings. So my idea was that the low quality setting led to some divide by zero issues or that the storing and retrieving the settings was not working properly.
Reload of the page or reset of the ESP did not seem to cure, neither did erasing the profile.
However it seemed to work when I switched to the network settings and (without changing anything) back again.
Stills worked always.
The full view seemed to work better than the simple view.

I then connected the CAM to seria portl and activated the debug output.
When switching from "full" to "simple", the stream is requested immediately after the page itself has been requested and while the webpage just shows the "x" the stream is actually running.
Hitting "Stop Stream" has no effekt. The stream just continues to flow. Same with another "Start Stream".
When I switch to another task (i.e. Network settings) or put the phone to sleep for a moment, After a few seconds Safari drops the tcp connections which obviously existed until then. The stream stops and the serial monitor shows "stream stopped".
If I then reactivate the phone or switch back to safari, I can now start and stop the stream in the simple view. I can do that all day long and the actions are reflected in the serial monitor. If I change to "full" and back to "simple", I get back into the ever running stream.
It actually seems to be a javascript problem, as if the request for the stream and the returning "handle" object reference or whatever it gets happen too early to be handled properly.

I'll have to look into the code but at this point I think it's rather a javascript than a c++/esp32 - problem.

I'll keep You updated

Regards

Frank

[easytarget]

This all comes back to the fact that the code, as it, only supports a single connection (stream).

If anything (eg over-eager browsers that refuse to drop connections even after you close the tab) keeps the connection open, you will not be able to open it from any other session/device/tab.

You can check whether the camera is currently serving a stream on the /dump subpage.

The 'Start' and 'Stop' stream buttons in the browser simply start and stop the javascript that requests stream frames in the browser. They do not talk back to the camera itself. The camera is entirely dumb and simply serves a stream to the first client that requests one until that client drops the connection.

Multi-session/client streaming #51 is high on the development priorities, but is non-trivial, and will have to wait for me to have some free time. In the meantime a number of other projects have implemented it, and may be more suitable.