Recent content by SwampdogMash

Just had an email from Ken @ support and this does in fact seem to be a feature - though I have suggested that maybe it needs to have a more clear appearance in the camera settings. the "edit" box is in fact recorded on direct-2-disk regardless of any other settings which changed in version...

I see the behaviour in 3.6.5, but all my cameras have the option for webcast overlays turned off as mentioned above as the fix. I have overlays disabled in the main camera settings also. Yes the work around does seem to be to remove the overlay from the edit window of the "display overlays" edit...

Interesting that this fixed it for some but not others. HTTP error 431 refers to header size too large... is there any way you can use wireshark and check the actual size of the headers coming through? Im going to do some more testing tomorrow and see if i can replicate these 431 errors.

Hi All Yes... i can indeed confirm that 5.3.6.5 seems to fix the issue. Ill do some more testing tonight but the basic scenarios nw work so i assume the "limit" has been removed. Andy

I haven't seen this similar behaviour, but it may be that the CF (cloud flare) UID cookie is actually just happening to take you over the 1024 byte limit. You would have to capture on the BI box to see what impact the cookie removal has to the request size (TCP Data) of the packets received...

Not sure how you mean? I've check all the cameras video settings and they all show up with no entry in the subtream field. I've turned motion detection off on the only 2 clones i have 2. I was running about 40% cpu playing 3 cameras before and now it's averaging around 80 and that means...

Not aware of using any substreams... will check it out and have a look

Not sure what would cause this, if there were some settings that required a restart to take effect, but when i've upgraded from 5.3.6.2 to 5.3.6.3 today to try and resolve another issue (>1k http request getting no response) I've seen the CPU utilisation increase Section 1 - playback of 3...

Same same. Just done the testing all over again. Looks like BI now responds with a valid ACK, but does not follow it up with the HTTP response when the packet size is >1k. I've tested this both by removing my cludge rules that mangle the headers to make it <1k (CF stops working), and by ADDING...

I have a reply from Ken... Hello Please retest this with 5.3.6.3 ... a change was recently made to allow longer HTTP requests over 1K. Thanks Ken

I will add more to the ticket.. once i get a reply to my support request. Am guessing it's busy..... I linked this thread in the email though...

I have a feeling I know... see my post here: https://ipcamtalk.com/threads/error-502-with-nginx-reverse-proxy-and-bi-5-3-1.50416/page-2#post-508932

This also explain weird issues i was having in generally accessing BI over a VPN when accessing certain pages.. where the camera feeds wouldn't start but I couldn't work out the rhyme or reason behind it. It is a function of cookie size and browser user-agent string size at this point...

All, Think i have found the issue! It looks to be related to the overall size of the headers sent to BI. Based on the above comparison of the headers, I had a look at the size of the working versus the non working. I then started messing with various elements of the headers to see what I could...

Hi BI Version 5.3.6.2 (04/12/2020). IIS ARR Reverse proxy and Let's Encrypt cert. Cloudflare free account with DNS proxy enabled. Been having the same issues myself. I've looked at all the headers coming from CF and whilst there are some that differ from the working request when I DON'T use...