-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Beta2] Frigate clips occasionally do not "autoplay" -- unexpected client/server interaction? #1637
Comments
Can you try and get the nginx logs from inside the frigate container when this happens? They should be at |
On load (no autoplay, ignore /api/stats from various HA instances):
On manual play click:
|
I haven't been able to reproduce this. Does this happen for the same clip consistently? |
Yes -- once a clip behaves this way, it seems to reliably & repeatedly behave this way. I see it on multiple cameras. |
Do you have any errors in the browser console? What browser are you using? |
Nothing on the console. Tested:
|
I am wondering of there is something wrong with the first segment referenced in the m3u8 playlist. Can you curl that endpoint for the failing event and post the contents? |
Verified on Safari |
Assuming you mean on the index, here is a curl of a "bad" clip
|
I can manually fetch the segments referenced:
|
Hmm. This is interesting, two segments captured from a good clip and bad clip from the same camera (Note: I have no idea what this command should output, I'm stabbing in the dark here):
|
I am guessing this is related: kaltura/nginx-vod-module#675 What is the i-frame interval on your camera? |
Do you see the same behavior for this event in Frigate's Events UI? |
Sorry, I don't know that. The cameras I have seen this behavior on so far are WYZE with the "official" RTSP firmware, I don't think they have a means to configure i-frame interval. |
It plays fine on the Frigate Event UI (but that does not autoplay anyway, for any clips, AFAICT). |
The workaround described in that other bug works! Adding this to the server section of
I do not understand the implications of enabling this more generally, do you? This implies there may be timing implications. |
Fantastic! Thanks for testing. I actually think this will help some other issues that have been hard to track down. I believe it tries to force 10s segments, but not all cameras have consistent enough key frame intervals. I will add it in and do some testing on my end in the morning. If I don't run into anything, I will add it in and put up the next RC. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Describe the bug
With Frigate 0.9.0 beta2, and the matching HA integration pre-release 2.0.0, occasionally a clip/event will not autoplay in the browser. When the video element loads, manually clicking the play icon will correctly play the video. I have observed this behavior:
I am confident this is new behavior from Frigate 0.9.0 onwards, and as the URLs are resolving to correctly formed Frigate URLs and the video elements have the attribute autoplay enabled -- I am not convinced this is a "client-side" issue even though it has all the appearance of one. This happens across multiple browsers and OSes.
This makes media browsing more painful.
Version of frigate
0.9.0-3340952
Config file
Include your full config file wrapped in triple back ticks.
Frigate container logs
Nothing logged of interest.
Query logs
Logs from my reverse proxy (Apache) on the requests being made from HomeAssistant to Frigate:
On video element load (where I would expect autoplay):
... when play is manually clicked:
Frigate stats
Screenshots
If applicable, add screenshots to help explain your problem.
Maybe ~75% of clicked clips will autoplay, 25% will act like this (no autoplay, but work fine when play is manually clicked).
Computer Hardware
The text was updated successfully, but these errors were encountered: