Do you get any error of type "header fields are too long for server to interpret"?
when i try to connect to the camera Now I'm getting a message.
Header fields are too long for server to interpret.
That might possibly be a change by Google (Web Viewer). One snag is that anything http is treated with suspicion.
However, a more advanced WebViewer is available as an extension, it might be able to deal with longer headers. Certainly, it is worth a try. Make a copy of your project first as the extension works a bit differently.
http://sunnythedeveloper.epizy.com/2020/05/13/customwebview-an-extended-form-of-web-viewer/
Does that IP address still work in a web browser?
Maybe your router's DHCP assigned it a different local address?
Whoa Horsey - you have not done anything at all to the ESP32 board? The solution last time was a wrapper for the camera library:
Try Frank Bröker's solution:
it is not a stream WiFiCam.ino its a still image i need a stream
Right 
- How about the WebViewer Extension?
- Reloading the firmware on the ESP with a larger memory allocation for header processing? https://randomnerdtutorials.com/esp32-cam-troubleshooting-guide
Also. back to basics, what is the exact model number of your ESP32 CAM? Where did you get the Sketch (Script) for it?
Also, on Button Click:
I tried every single sketch you sent none of them work this isn't my fault you downgrade your app
if you can please send me something that will work that you tried then I will do it I have wasted 3 days on this.
I'll just not use your app.
We are trying to help you Tzvi and for the record, we have not changed App Inventor in a way that would affect your App, but Google have changed Chrome - the WebViewer uses Chrome.
I have not sent you any Sketches to try either. I have sent you links to discussions about how to fix this problem. If you read those, you will see that all platforms are affected by Google's change not just App Inventor.
It is nobodies fault. This is what software developers deal with every day. When your code/hardware design depends on external software/hardware, whenever they change, you have to update your project too. That is just the way it is and has always been.
Have you tried the things I actually suggested you try? Starting with the easiest, the Button Click? Are you going to answer my questions, which were asked so that we might be able to help more?
I should add that if it is necessary to update the firmware with a larger memory allocation for the headers, it can't be done via the Arduino IDE, ESP-IDF has to be used.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32
With that IDE you can change the following setting
menuconfig the value: HTTPD_MAX_REQ_HDR_LEN
It defaults to 512 (depending on the model of your board). You can change 512 to 1024.
Guide on installing and using ESP-IDF (there is more than one, perform a Google search to find one you prefer)
https://esp32developer.com/programming-in-c-c/compilers-and-ides/esp-idf/installing-esp-idf
I'm sorry I have not understood the problem wasn't with you and I thank you for your help trying to fix it.
I have with the original library esp32 I've changed the button I'm now trying different libraries and I'll try your newest solution really thank you and I am sorry
The worst case I'll use split screen with chrome I know that works it won't look like it's part of my project but it's the best l can do
I thank you on what you enabled me to do
Likely this problem will only get worse in the future. IIRC, the WebView does not let one adjust the User Agent header--Chrome always sends what it is--and as the version number of Chrome goes up in the future the string will continue to get longer.
Would it be possible to add a method to the web
component that would give us access to raw http streams and headers? That would be helpful for this (parsing mjpeg) and also for push with SSE which I've had to use webviews for in the past.
We'll have to think about it. One issue is that App Inventor doesn't natively provide a type in the blocks for a binary data buffer, so allowing access to the HTTP body when it could contain binary data is an open question. Access to the response headers would be easy enough to implement.
hello, I'm trying to read the video stream from my ip camera in a birdhouse. Would it be possible to share the code of your Tzvi_Kut application?
Thank you for your help. Good day to you.