streaming not working in 1.21.3 #199
Comments
|
Same problem here! Screenshots do work, but no video stream. |
|
Also .. I dont know if this is connected to the problem, but I found a stacktrace after restarting the unifi protect application on my udm pro: |
|
hopefully it will be fixed soon cause 1.21.3 is out now since 1 hour official |
|
Finally got the update and looking for a fix. At the moment, it doesn't look like an easy one, so I'd suggest disabling auto-update and downgrading if you rely on the proxy for important cameras. |
|
Seeing same thing on my setup. I mean right now there are NO cameras to buy from Unifi so this is our only option. :-/ |
|
What's the latest version of protect that should work? I tried back to 1.19.2 but kept getting the same error. Do I need to downgrade the entire unifi-os on the udm pro since I updated to 1.11.4? |
|
1.21.2 works |
|
Identical issue here. 4 x Hikvision cameras working perfectly with Protect v1.21.2, only low-res screenshots with v1.21.3 and seeing the identical crash as @eltomato89 above. Reverting to Protect v.1.21.2 got the cameras back online. To save time for others looking for how to revert, ssh into the UDM-Pro and: |
|
Same here with Amcrest / Dahua cams. |
|
Any updates? |
|
A few posts up he said it wasn't going to be easy to fix, so I would stay on 1.21.2 (if you have access) as long as it takes if you need them. Nothing in .3 is really exciting enough to upgrade anyway. |
|
FYI this is still broken in Protect 1.21.4 incase anyone was curious on upgrading. |
|
Same Issue |
|
Any chance it will be resolved or Ubiquiti killed that project :/ ? |
|
Ah damn, should have looked in here first... going mad for weeks now because the cameras froze for no apperant reason. Changed switches, cables, firmware... oh my... My Dahua cams always worked for one up to four days, then died in a way that only a loss of power could revive them. no access via webinterface was possible. switching to protect 1.21.2 now for testing. |
|
1.21.2 seems to work for the past 4 hours but only without seperate screenshot URL. I hope the cameras stay on. |
|
New version 1.23.4 with changelog: Maybe it's be a bug? Somebody can check it's be resolved on new Protect version? |
Still not work in 1.21.4 |
|
Same here. 1.21.4 only snapshots are working. I have not had any time to debug but maybe I will see what I can find over the next few days. Has anyone looked at 1.21.3 release notes to get a clue what may have changed? I will check that too. |
This works perfectly. Thanks! |
|
Any updates? |
|
So Just an update for me I updated the console to 2.3.15 (NOT THE PROTECT APP ) and my cameras stopped working :/ . I'm getting a streamname: = nlkjljoilkljkljjijj898yo invalid arguments Config |
|
I've made some progress trying to understand the new entirely custom video feed, but haven't quite been able to figure out which bits are necessary just yet. Thank you for your patience! |
If I can assist in any way let me know |
|
Getting a similar error |
|
So Im not sure if this has anything to do with a broken pip error. But since the update of the controller only not the app. I can no longer reach the unvr or protect by the specified ports So I assume the port mapping for the UNVR has changed the ports listed below |
|
Update: I've been able to make progress and get basic streaming working again in 1.21.4, but it will take me a few days to get things in good enough shape to ship a fix and push a new version. |
|
Thank you for your effort to get things back. |
|
If somebody doesn't get to it sooner, I can try this out in a few days! If you'd like, you should be able to clone this repo, create and activate a virtualenv, 'pip install -e .' within this repo and then run the UniFi-cam-proxy command. At this point, any changes you make to the clock_sync script should take effect. |
|
So don't think this makes any difference regarding the timestamp, as if
it's zero it will just be the high bits being zero, and if not it will be
used. So indirectly it's not used if it's zero.
Been looking into the trail timestamp, and I can't make sense of it.
…On Fri, Aug 25, 2023 at 11:20 PM Keshav Varma ***@***.***> wrote:
If somebody doesn't get to it sooner, I can try this out in a few days! If
you'd like, you should be able to clone this repo, create and activate a
virtualenv, 'pip install -e .' within this repo and then run the
UniFi-cam-proxy command. At this point, any changes you make to the
clock_sync script should take effect.
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMTLTSE7P4QATM6KHFL6FDXXGISNANCNFSM5QFNMCAA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@ptorsten when poking around in the unifi protect software. I found some references to “Live flv” . Does this mean anything to you? |
|
That seems to only be applicable to rtmp, unless I'm missing something.
…On Sun, Aug 27, 2023, 11:31 redalert11 ***@***.***> wrote:
@ptorsten <https://github.com/ptorsten> when poking around in the unifi
protect software. I found some references to “Live flv”
<blakeblackshear/frigate#1467 (comment)>
. Does this mean anything to you?
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEBT42PY4GMTPUDV3GOMDXXNR6JANCNFSM5QFNMCAA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
The trailing timestamp moves around 0.35 of the streamClock, and that
doesn't make any sense to me, anyone?
On Sun, Aug 27, 2023 at 8:51 AM Brett Smith ***@***.***>
wrote:
… That seems to only be applicable to rtmp, unless I'm missing something.
On Sun, Aug 27, 2023, 11:31 redalert11 ***@***.***> wrote:
> @ptorsten <https://github.com/ptorsten> when poking around in the unifi
> protect software. I found some references to “Live flv”
> <blakeblackshear/frigate#1467 (comment)>
> . Does this mean anything to you?
>
> —
> Reply to this email directly, view it on GitHub
> <
#199 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAAEBT42PY4GMTPUDV3GOMDXXNR6JANCNFSM5QFNMCAA>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMTLTT6KDBHYXVPSQUE42DXXNUHNANCNFSM5QFNMCAA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
it can be FLV as well. if I compare what port we are using to what unifi-protect is looking for in /srv/unifi-protect/data/ems.json (line 103). it references that unifi-protect is looking for Live-FLV. ill see if can figure out how to try it. I found at test implementation here. |
|
On my fork I'm seeing that the live view is almost exactly 50% speed from what it should be. The timestamps in code however look fine. I tried adjusting fps to see if there was some frame rate component but I didn't notice any change. |
Tried this on my hikvision ... seems to work. Before this my video was getting out of sync pretty quicky, now it seems to stay within 1 second of the actual time. The only thing I changed was |
|
edited, didn't see evilworm's full comment. now only warning I'm getting is "filtered_messages() is deprecated and will be removed in a future version. Use messages() together with Topic.matches() instead." great job everyone working on this. |
|
FYI my testing is happening on this branch. I still don't think I have it nailed down yet: https://github.com/phillijw/unifi-cam-proxy/commits/main |
FYI I think |
|
@keshavdv I'm trying to understand the |
|
These are all new custom script tags that were added in Protect 2.x and aren't described anywhere, I think these are some latency related metrics and don't seem to have any effect on the time stamp skew problem. I chose values from a test stream and haven't been able to identify what that are used for within the UI |
|
I think they are bitrate reporting as I see them being different between
cameras. I can't make sense of the trailing timestamp...
…On Tue, Aug 29, 2023 at 08:32 Keshav Varma ***@***.***> wrote:
These are all new custom script tags that were added in Protect 2.x and
aren't described anywhere, I think these are some latency related metrics
and don't seem to have any effect on the time stamp skew problem. I chose
values from a test stream and haven't been able to identify what that are
used for within the UI
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMTLTQCH26OKUZKUFTB6ATXXYDPJANCNFSM5QFNMCAA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I've done a few checks of how far out the cam timestamp is from the protect timeline (during playback) and every time I am getting something almost exactly close to a ratio of 2.85:1 such that 10min on the timeline equates to 3.5min on the recording (10 / 3.5 = 2.85). Basically the recording is playing in slo-mo. Anyone have raw data (wireshark?) that shows several examples of the trailer being sent along with real-time timestamps to compare against? |
|
Interesting - I have multiple recordings of timestamp and the trailing
timestamp is always 0.351574213 of the stream timestamp, but when I try to
match that it goes even slower.
wrote a small python parser to pull it out of the binary stream from
wireshark:
trail: 178984526 stream: 509096209 wallclock: 1688425685094
trail: 178985010 stream: 509097668 wallclock: 1688425686475
trail: 178985874 stream: 509100043 wallclock: 1688425688921
…On Tue, Aug 29, 2023 at 10:41 AM Joe Phillips ***@***.***> wrote:
I've done a few checks of how far out the cam timestamp is from the
protect timeline (during playback) and every time I am getting something
almost exactly close to a ratio of 2.85:1 such that 10min on the timeline
equates to 3.5min on the recording (10 / 3.5 = 2.85). Basically the
recording is playing in slo-mo.
Anyone have raw data (wireshark?) that shows several examples of the
trailer being sent along with real-time timestamps to compare against?
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMTLTUQQ3LTI6TPRYRTOFLXXYSWDANCNFSM5QFNMCAA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I'll share some dumps later today, but I've seen similar behavior except different cameras have a different "ratio" which makes me think a part of it is tied to elements of the stream itself (e.g. fps) and isn't just off by some set value. |
|
also noticed that it's very sensitive to the stream itself, some works well
and some doesn't. Rebroadcast via go2rtc etc helps unify them, but it's all
a bit messy.
On Tue, Aug 29, 2023 at 10:47 AM Patrik Torstensson <
***@***.***> wrote:
… Interesting - I have multiple recordings of timestamp and the trailing
timestamp is always 0.351574213 of the stream timestamp, but when I try to
match that it goes even slower.
wrote a small python parser to pull it out of the binary stream from
wireshark:
trail: 178984526 stream: 509096209 wallclock: 1688425685094
trail: 178985010 stream: 509097668 wallclock: 1688425686475
trail: 178985874 stream: 509100043 wallclock: 1688425688921
On Tue, Aug 29, 2023 at 10:41 AM Joe Phillips ***@***.***>
wrote:
> I've done a few checks of how far out the cam timestamp is from the
> protect timeline (during playback) and every time I am getting something
> almost exactly close to a ratio of 2.85:1 such that 10min on the timeline
> equates to 3.5min on the recording (10 / 3.5 = 2.85). Basically the
> recording is playing in slo-mo.
>
> Anyone have raw data (wireshark?) that shows several examples of the
> trailer being sent along with real-time timestamps to compare against?
>
> —
> Reply to this email directly, view it on GitHub
> <#199 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAMTLTUQQ3LTI6TPRYRTOFLXXYSWDANCNFSM5QFNMCAA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Maybe it's related to keyframes in some way, like the position of the key
frame?
On Tue, Aug 29, 2023 at 10:49 AM Patrik Torstensson <
***@***.***> wrote:
… also noticed that it's very sensitive to the stream itself, some works
well and some doesn't. Rebroadcast via go2rtc etc helps unify them, but
it's all a bit messy.
On Tue, Aug 29, 2023 at 10:47 AM Patrik Torstensson <
***@***.***> wrote:
> Interesting - I have multiple recordings of timestamp and the trailing
> timestamp is always 0.351574213 of the stream timestamp, but when I try to
> match that it goes even slower.
>
> wrote a small python parser to pull it out of the binary stream from
> wireshark:
>
> trail: 178984526 stream: 509096209 wallclock: 1688425685094
> trail: 178985010 stream: 509097668 wallclock: 1688425686475
> trail: 178985874 stream: 509100043 wallclock: 1688425688921
>
>
> On Tue, Aug 29, 2023 at 10:41 AM Joe Phillips ***@***.***>
> wrote:
>
>> I've done a few checks of how far out the cam timestamp is from the
>> protect timeline (during playback) and every time I am getting something
>> almost exactly close to a ratio of 2.85:1 such that 10min on the timeline
>> equates to 3.5min on the recording (10 / 3.5 = 2.85). Basically the
>> recording is playing in slo-mo.
>>
>> Anyone have raw data (wireshark?) that shows several examples of the
>> trailer being sent along with real-time timestamps to compare against?
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#199 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAMTLTUQQ3LTI6TPRYRTOFLXXYSWDANCNFSM5QFNMCAA>
>> .
>> You are receiving this because you were mentioned.Message ID:
>> ***@***.***>
>>
>
|
|
On my branch I pushed a change to log the framerate and duration and width/height of the video. Unfortunately it's not sending anything useful at the moment: There is more data available but, for me, framerate is not there for some reason. |
|
after some more testing of @phillijw patch:
FYI I'm running dockerized version from :dev branch with --ffmpeg-args="-c:v copy -ss 0:01". |
|
I'm having the same experience and evil worm. basically does not work. |
|
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. |
|
still not working |
|
Confirmed, still not working. Please reopen this. |
|
Anyone still actively working on this anymore? |
|
Trying but not making progress.
…On Mon, Nov 6, 2023 at 11:54 AM cmille34 ***@***.***> wrote:
Anyone still actively working on this anymore?
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMTLTVKNQLMI7YFZXD3PATYDE56TAVCNFSM5QFNMCAKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGYZDKMRYGE4Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Has support for unifi-cam-proxy stop working under the latest Protect 3.0.26? I was able to add an Amcrest cam, but the live feed frame rate is very slow. Plus it will not record to the NVR at all. It may have to do with the cam model set to unknown. Have not been able to get it to recognize a unifi model cam. |
and others
no streaming in version 1.21.3
snapshots are there, but streaming is KO
in proxy site, looks like all is ok, but in unifi UDM pro - there is no video, 3dost all the time (loading)
Camera:
The text was updated successfully, but these errors were encountered: