You could set the timeout to 0 and it will never time out. Or just to a large value.
Im continuing to refactor and add functionality to the backend. One thing I want to do is review and update the RTSP handler. Having configurable timeout would be one thing
And why it doesn’t reauthenticate when getting a 454 is because this is my own implementation of RTSP and up until now there was no need to support it. 
Thanks for your hard work. I still think its weird that this only happens with the newer of the 2 cameras. I tried the timeout 0 and weirdly enough I couldn’t get the VMD4 page to work with it set. I rebooted the camera a couple of times but it just wouldn’t open. I am testing a much longer timeout (30min) now so hopefully it will work better without having to constantly keep it open. I don’t think you would need a configurable timeout but what if it send the option command at 90% of the camera timeout value and again at 95%? Something like that so it gets multiple chances to keep it alive.
Why send twice if the pi is the one having issues with load? The supposed problem here is that the first one isn’t sent in time.
The keep-alive is always sent 5 seconds before timeout occurs. The timeout is specified during setting up the session
Looked a bit more at the logs. Since you get a “RTSP session lost connection” message that means in your case that the device closes the connection for some reason.
Shouldn’t really be any issue to cover this case with a retry. I will add it to my list
First beta of 0.92 is building right now. There are a quite a few improvements for the component following.
Just Info:
In 91.3 axis component found all 18 Q7407 cameras from the Q7404 blade server (3x6).
Did not find 212PZT cameras
Did find P7414 quad server (P7414 0) which is channel 1 but did not find channels 2-4.
Great job, very nice to have Axis cameras back.
212 runs a way too old firmware which has Vapix2 whereas the component only supports Vapix3
Thanks. I try to get it up manually.
Any idea about the Q7214? Doesn’t see the other channels…
There is no logic for multiple channels. I can have a look at that after I’m done with IO port management
Thank you Robban. I can open a Q7214 up for you to access if you need one available for testing. Let me know.
PR adding back support for IO-ports (inputs, outputs, relays and supervised inputs), will now also create switches for outputs.
With upgrade to 92.1 lost access to all Q7406 Blade cameras (18) in Lovelace. These were discovered and working in 91.3. I manually configured the 212PTZ cams and the P7214 quad video server in 91.3 and these all still work.
Not getting any errors I know of.
Ok, can you share debug logs for the Q7406 and P7214 so I can see what happened?
I am having the same problem with intermittent motion notification from 4x Axis cameras
2x M2025-LE
1x M2026-LE
1x M2026-LE MKII
The cameras are all running ver 9.10.1 firmware with VMD4.3-3 motion detection. They run initially then only intermittently. The stream and snapshots work perfectly.
Is there an alternative method to push the motion event to HA which would be 100% reliable?
The way to get it 100% reliable is to identify why this behaviour shows up 
I have on my list to add support for that other error message to automatically reconnect when it happens. But logs from cameras when this happens are appreciated, better to understand the root cause
Thank you, and yes I agree. I’m very new to this, so your advice would be appreciated to set up logging.
Just to chip in on this topic regarding Axis cameras
Slightly off topic but probably good to know. Axis have had a component issue on the P14 series particular the p1425 and p1435. Cameras can fail to power up after 6months use due to a diode failing.
I will get back to you tonight with details
Do you need logs when the first attempt has failed or just ongoing motion detection isn’t working? Which logs do you need?
The more relevant data the better. So hard to say exactly since I don’t know exactly what the issue is