2.9.0 suddenly causes poor connection to cameras #1193
Comments
|
I am experiencing the same thing. I reverted back to 2.8.3 which has been solid. I did confirm I have the same issues with 2.9.1 as well. |
|
This doesn't have anything to do with the new FFMPEG option |
|
Could you try the latest dev build to see if it helps? @vipergts450 it's a timestamp issue with the raw h264 - the cameras return a timestamp together with the raw h264, but there doesn't seem to be a way to pass that info on to ffmpeg so use_wallclock_as_timestamps seems to help keep everything in sync. |
|
On the dev branch as of this morning. Will report back in a bit. |
|
It's certainly more stable than yesterday, which is a big help. However, something's still going on with the timestamping or keyframing on my Cam v3 (oddly not happening with my very old OG Cam Pan). Do these cams handle the stream keying differently? Once the stream came back up on its own, it's stable again for the moment. It looks like the stream was up for almost exactly 30 minutes before resetting. Update: happened again after exactly 30 minutes just as before. So looks like there's a 30 min cycle for resets on the Cam v3 at least, maybe as a counter rolls over? My Cam Pan stream has not reset at all since the container went online. |
|
hmmm, thank you for the data point! I wonder if the camera's might be running some kind of clock sync every 30 minutes that might be throwing off our av sync checks.... |
|
Updating again. Since this morning, the Cam V3 has done the 30 min reset consistently, but it's now fast enough that the NVR it's connected to doesn't "notice" the camera going down every single time (only maybe 3 times total all day did it notice the disconnect and send me a warning email) and quickly resumes when it comes back up. The old Cam Pan has never dropped. So the two firmwares seem to do keyframing/timestamping/time sync a bit differently. This current dev version seems to be a reasonable stopgap fix in the interim as compared to 2.9.0-2.9.1 in my opinion until a more permanent fix is discovered. |
|
Update: Stream for the Cam v3 finally went kaput exactly 9 hours, 21min, 25 seconds after starting this morning and did not recover. That's about 33,685 seconds or ~15 min after a signed 16-bit integer counter would roll over past 32768. Not sure if coincidental or related some way how the new FFMPEG counter works. It did not recover again as it had throughout the day and remains permanently down. That's the log from the last "normal" reset I saw all day until the final stream ended. The Cam Pan (cam2) has stayed up all day and never had a "blip". |
|
Today's dev release has kept both streams up since starting up 4 hours ago. |
|
I can also confirm that the latest DEV build is solid in regards to the original issue of the thread. I still have zero success with V4 cameras but I don't want to get off topic of this thread. |
|
Unfortunately, it seems like the audio seems to drift behind on the dev branch. |
|
How about trying the live_flv flag? Also, this issue with the 13hr 15min bug I mentioned a few days ago. Maybe I did my math wrong when I said 9 hours? That thread references using And later in Looks like it was fixed in MediaMTX in 0.18.4? |
|
Thanks @vipergts450, I will have to take a look at those. I've added the Would appreciate any feedback! |
|
I am pulling the dev now as of this writing and will report back. |
|
@vipergts450 Any feedback on the last dev build? |
|
@mrlt8 I have a full day under my belt on this latest dev build and have received no disconnects from the NVRs connected to the stream, and the logs only give the occasional |
* Tweak AV sync and ffmpeg cmd #1175 #1196 #1194 #1193 #1186 * Catch AccessTokenError * don't drop timestamp #1175 #1196 #1194 #1193 #1186 * Don't use_wallclock_as_timestamps #1175 #1196 #1194 #1193 #1186 * keep audio in sync #1175 #1196 #1194 #1193 #1186 * Ignore whitespaces in api key/id #1188 * Remove quotes from credentials #1158 * HA Add FORCE_FPS option #1161 * FORCE_FPS option for all cameras #1161 * changelog
Hello,
I upgraded to 2.9.0 yesterday and suddenly the connections from the bridge to my two cameras is very unstable. The log has these messages every couple of seconds. I have
ON_DEMAND=Falseset in my config but that did not help. Nothing about my configuration changed since the prior version which had been rock solid.Possible related to this person's issue: #1186 (comment)
Could this be a port mapping issue that arose with the latest update? I don't see any log lines that suggest the bridge is losing the feed from the cameras, but seemingly clients connecting externally to the bridge to retrieve the feeds have this constant connect/disconnect problem.
The choppy stream, timeout when fetching snapshot on the WebUI (the auto refresh sometimes pulls a new snapshot image and sometimes does not for 15-20min), and general misbehavior seems to point to something between the front-end and the mediamtx backend, but I can't seem to figure out what exactly.
The text was updated successfully, but these errors were encountered: