-
-
Notifications
You must be signed in to change notification settings - Fork 54
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
Error when streaming from Argus 3 pro [was using UID discovery], Deserialization error #36
Comments
Lets try disabling relay for the moment. Can you add [[cameras]]
...other cam stuff...
discovery = "local" to your config. It will disable the remote and relay discovery |
Doesn't work. The battery powered cameras do not respond to broadcasts. Or if they do it takes longer than the timeout. I believe that the only way to establish a connection to one of these cameras is with the remote discovery.
|
Oh then let's try the next level up |
Update... timeout is too short. I tried again with tcpdump monitoring and the camera does respond eventually. It can take a few broadcast attempts (restarting neolink several times). |
Ok I'll bump that up then or maybe repeat more than 5 times |
Which branch are you working on? |
remote discovery has the same problem, packet arrives from relay server and neolink errors.
|
Yes I am working in that branch now. Bump it up really high please, to get us past this problem. Let's say 60 seconds. And keep broadcasting until then. Thanks |
We broadcast every 0.5s for 2.5 seconds I've bump it up to every 0.5s for 60s now but that might be too long for production |
Yes agree. But for production really need to fix the underlying problem of error on the unexpected packet. |
Humm. That didn't fix it. Local discovery now works, but we still error out and this time there is no incoming packet from the relay server. I have to stop for the night now.
|
Btw... the constant logging of start to parse |
The |
All local. |
Could you send the pcap it would be helpful to see the steps in wireshark |
Gents, just to add to this I see the Deserialization error on the Argus Eco, Pro 2 and Pro 3 cameras. The issue is not limited to the Pro 3. I was lucky enough for it to complete on one of my Pro 3's and it is very cool! If I can help troubleshoot please let me know. |
Archive 2.zip |
@dkerr64 Pushed an update to |
I think your push is incomplete, missing keepalive module, so it is not building. |
Ah I see, sorry about that. Since my usual editor (Atom) is no longer being updated I've swapped to something else but the new editor dosen't manage git nearly as well so I'm doing it more manually. Anyways should be pushed |
Now we are building and things have improved a lot. There are still errors like that below, and the VLC player is logging a lot of warnings. Those should probably be new/separate issues. But this bug is now fixed.
|
Maybe I spoke too soon. Deserialization error still exists. Note in this case the IP address was discovered by relay not local. Was not running with debug so don't know if a message was received from the relay server.
|
I've added the UDP keep alive messages so that the camera doesn't drop us for inactivity. However now you are getting a disconnect from the Relay instead of the camera.... I've got to find our what the offical client dose to placate the relay |
Hopefully this is addressed in #40. I did some tests were I stopped discovery methods one at a time until I could replicate your issue then reworked the discoverer to better match the offical client. It seems to now be working for my Argus2E |
If you could test it would be appreciated |
So far I am not seeing the deserialization error. I am still seeing the problem reported in #38 so it may be necessary to get past that one before we know for sure that this is fixed. |
#38 should be addressed in |
See comments in #38. This deserialization is probably fixed. |
With 0.5.4rc I am not hitting the deserialization issue so far. Thank you for addressing that so quickly. I did want to highlight that as soon as gstreamer is invoked/started even without the pause feature enabled I see 100% CPU utilization. The pause feature is not working in this release but I think that is expected. Is there additional information I can provide to help? I have the trace output below. |
Think this is all fixed now so closing. Please make a new issue against the latest neolink if you get something similar |
My wired Reolink is working fine (RLC-520). However the Argus 3 Pro is not. I suspect it is to do with UID discovery as that is the only way to connect to this camera.
After streaming starts the debug log shows continuous
start to parse "Extension"
messages which within 15 seconds ends with an error. Before it errors out I am able to connect to the rstp stream with VLC, but it terminates shortly after the error.Streaming from the camera seems to stop (tcpdump sees no traffic) but neolink is still doing something as CPU continues to run at 25% (4 core, so 100% on one core/thread?)
Monitoring tcpdump, I notice an incoming packet from 20.231.199.129 which is the relay server returned by Reolink. It appears that neolink is not expecting that because it expects traffic only from the camera's local IP address.
Here is tail end of the log.
And the tcpdump...
Error message in neolink coincides with receipt of the packet from 20.231.199.129
The text was updated successfully, but these errors were encountered: