Parallel Processing Deepstack Time Issue about bi-aidetection HOT 12 CLOSED

First try the latest version - There is a zip attached to the other MQTT issue/feature request thread here.

My first guess might be that if a url or image fails for some reason, it gets re-tried, and the new deepstack time gets appended to the last try.

from bi-aidetection.

I just compiled the latest version this morning and did all my tests with that. I don't think they are failing as everything works when using either IP on its own. Times only get weird when I have more than 1 ip set. I'll try to get a log output later today.

from bi-aidetection.

I reworked a few things, try the latest. The FIRST time I submit something to a deepstack URL is almost always 5 times as long as normal, so make sure thats not what is happening. Also the deepstack time in the log is now PER-URL - before it was a combined set of stats for all url's. I have two IP's setup and the times for both seem normal.

from bi-aidetection.

Wasn't sure whether to open as a new subject but as it's related:

I notice with the Deepatack URL's it takes them in order.
URL1, URL2, URL3, URL1, URL2 etc

Would it be possible that they could be prioritized.

So first it uses URL1.
for the next image If URL1 is available it uses that again but if not it uses URL2

Eg URL1,URL1,URL2,URL1,URL2,URL3etc

from bi-aidetection.

@Tinbum1 - what is the use case? I kind of like the current load balancing where it will spread the load evenly between instances and not abuse one machines cpu. btw, how is the version from last night working for you?

from bi-aidetection.

Thought was that if you have one URL that can process quicker than the others it might be best to use that one most.

Everything seems to be going well for me.

from bi-aidetection.

@SHerms - how is the latest working for you?

from bi-aidetection.

The last version I compiled was on 9/11. It is hard to tell if it is better. The times still jump around a lot for the DeepStack time.
Sometimes I will get a bunch of "Not showing further warnings about skipping disabled URL". I'll update / resave the DeepStack URL and it works fine. I'll try to recompile the latest version and post my whole log after running for a couple hours.

from bi-aidetection.

When compiling I get this warning. Not sure if this is coming in to play when using multiple Deepstack URLs

Source\Repos\bi-aidetection\src\UI\AITOOL.cs(331,35,331,49): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

from bi-aidetection.

I wouldnt worry about that warning. But I did discover that my HttpClient requests for the deepstack server were probably building up connections that were not released. (even "USING") Working on trying to understand "IHttpClientFactory" to fix. It may have been causing your task canceled errors.

from bi-aidetection.

Ok, see if the latest is more stable. Each deepstack URL now has its dedicated HttpClient and it gets reused now to prevent too many connections from build up behind the scenes.
AITOOL-VORLONCD.zip

from bi-aidetection.

Everything has been working great. Thanks for all your work!

from bi-aidetection.