Webviewer component 'get' mp4

Hi. I have made a python scipt with a webserver that contains small mp4 movies. I can play them with a normal browser but also with an app with the webviewer component. Just by using the path like http://192.168.1.201:8888?play=name.mp4

When I do this with firefox the python script shows only 1 get event, but with the app on my smartphone it always shows 4 get events directly after each other (all at the start of playing). It shows the movie without problems but I'm just curious what can cause this.

Thanks,
David

Please download and post each of those event block(s)/procedures here ...
(sample video)

Hi ABG, to exclude all possible errors, for testing I made a new app with only a webviewer component. When screen initialize, call webiewer1 url with an url to an mp4 movie and it does the same. 4 gets in about 1 second appear on the python server. With firefox only 1. The mp4's play correct on both firefox and the webviewer. They are small fragments that are recorded with the linux 'motion' program from a camera in the garden when motion is detected.

David
blocks

These are the 4 get events that appear on the python script:

192.168.1.3 - - [01/Jun/2022 18:50:49] "GET /?film=deurbel/20220522-001504.mp4 HTTP/1.1" 200 -
192.168.1.3 - - [01/Jun/2022 18:50:49] "GET /?film=deurbel/20220522-001504.mp4 HTTP/1.1" 200 -
192.168.1.3 - - [01/Jun/2022 18:50:49] "GET /?film=deurbel/20220522-001504.mp4 HTTP/1.1" 200 -
192.168.1.3 - - [01/Jun/2022 18:50:50] "GET /?film=deurbel/20220522-001504.mp4 HTTP/1.1" 200 -

I see no clues at
http://ai2.appinventor.mit.edu/reference/components/userinterface.html#WebViewer

Does your Python server also record the full URLs of each incoming request?
There might be informative differences among the 4 WebViewer request URLs to explain what is happening.

Hi, I added the python log to the previous answer.

I am running out of straws to grasp here.

I do notice a lack of "http://" preceding the URL in your URL text block.

This is guesswork...

Perhaps the WebViewer is engaged in some sort of protocol negotiation at the start of its connection with your doorbell?

That might result in only a small constant set of requests, instead of a continually growing list of requests associated with a constant data stream?

Further diagnosis would require one of those unsafe data stream monitoring tools and deeper http protocol knowledge than I possess.

1 Like

It views an mp4 that is already stored on a harddisk, so no direct view from the doorbel camera.
When I did the test again with http:// in front of the url it had the same 4 get responses.
I was thinking maybe the smartphone can't handle the stream in the beginning so it has to try a couple of (4) times. I could try it with another phone once I have one.

Thanks,
David

I think it's possible that GET is repeated until the required item is made available by the server, or times out.

1 Like