Alexa Suddenly Stopped with Unifi
-
My setup quit working also, but not sure exactly when. I run beta versions of Protect and UNVR, so tend to update the system frequently.
Rebooting the old Win7 PC that hosts the Monocle gateway service usually fixes it, but not this time.
I haven’t spent much time on it other than double checking that the stream URL’s are correct, and verifying that they still work in VLC.
I have noticed some of my Alexa devices recently updating:
FireTV v6.2.89
FireStick v6.2.89
Echo Spot v675709420
Echo Show5 v6812522884 -
@GreggC Yea:
Just Want the Monocle folks to step this one up and let us know whether it is UI or Amazon that is causing the issue …
Guys ?? Anytime … PLEASE
-
@GreggC Yea I cant seem to pin it down, but based on the logs it looks as though something is being rejected within the stream …
-
Maybe @Monocle can shed some light.
-
Apparently, some Blue Iris users have also had RTSP issues since updating to Protect 2.0. I wonder if it’s the same underlying problem we’re experiencing. Some users have stated that permanently disabling audio on cameras resolves the issue, and also that the Protect 2.0.1 is in EA to resolve the issue. I don’t have time today to go through disabling audio on a camera in Protect (then factory resetting & re-adopting after testing), but can probably test it out this weekend. I’m not sure I want to switch to the EA branch either, but if either of you guys is on it and has 2.0.1 installed, it would be good to know if you’re still having the issue.
-
well, so much for my hunch. I had some time at lunch and I disabled the microphone on one of my G3 Flex. No luck with monocle. Switched to EA branch and installed 2.0.1 of Protect on my UCKG2+. Still no luck. Back to the drawing board…
-
@pineapplebigshot Protect 20.0.1 does not resolve for me either. Again, the streams do work in VLC, also in IP Camera Viewer Pro for Roku, neither of which have anything to do with Monocle.
-
@GreggC yep, still works in VLC and scrypted for me. The issue Blue Iris users discovered is that in Protect 2.0, Unifi made changes to the audio codec for their streams. The changes are still in spec for RTSP, so other endpoints like VLC, etc still work fine, but BI didn’t like the change. I was hoping we were seeing the same issue with Monocle not liking the audio codec change. It might still be related, but the disabling audio and 2.0.1 upgrade workarounds don’t fix it, so it could also be something else entirely.
-
I have tried the fixaudio and noadio tags in Monocle, but no improvement.
-
Well, there’s a storm happening over on the Ubiquiti forums regarding changes to RTSP introduced in Protect 2.0 that have broken some 3rd party integrations. Ubiquiti hasn’t yet provided details on exactly what changed, but claims to be within the various standards and says it’s the responsibility of the 3rd parties to update their software accordingly. Apparently, some have already done this. If I ever get more useful details, I’ll post them here.
-
From what I can see in VLC:
Older versions of Protect had one audio stream (0) MPEG-AAC
Protect 2 adds a second audio stream (1) Opus
Video H264-MPEG-4-AVC moves from stream (1) to (2) -
So, in addition to Monocle/Monocle Gateway, I’ve also been running Scrypted on the same rpi to get my unifi cams into HomeKit for the past few months.
After these past few days trying to figure out what’s going on between Monocle & Protect, I discovered that Scrypted has an Alexa plugin and skill that work really well to get my Protect cams onto my Echo Shows. So I’ve switched over to that for now. No offense to the developers of Monocle, they have a great product that I’ve been using flawlessly for years. I’ll continue to follow this thread and Monocle’s development going forward. Hopefully this particular issue comes to a resolution quickly.
-
Further insight from VLC:
Permanently disabling the microphone on the UniFi cameras does NOT stop the transmission of an audio stream. The streams are simply empty.
Further, the new Opus stream (1) that was added in Protect 2 is always empty, even when the mic is enabled. Only the AAC stream (0) carries data (including for Protect 2.0.1 released to GA yesterday).
So it seems Ubiquiti has provisioned the Opus stream for future use. As of now, I don’t see any controls to tell Protect which stream to use, but in the name of network efficiency it really doesn’t make sense to simultaneously populate both stream types with data. Perhaps they will make the switch to the more efficient Opus codec for us in a future release.
On the subject of efficiency, Ubiquiti introduced another new beta/lab feature in Protect 2 called “Low Latency Video” (Settings, General, Other Configurations). It was enabled by default in some of the betas, but I believe is disabled by default in 2.0.1.
VLC shows that LLV is only effective on the G4 series cameras, dramatically reducing the RTSP frame rate while continuing to use the same AVC codec. Depending on camera model and the selected stream quality, rates were in the range 3-10 FPS for cameras that would normally be at 24-30 FPS.
This is only for RTSP, but amazingly it is difficult to see a difference in side-by-side viewing of a VLC LLV stream and a Protect Live View at High-Quality. The LLV stream is just as responsive to real-time motion.
As for Monocle, it is still failing no matter the G3/G4 camera model or the LLV setting, and I would expect this has more to do with the second audio stream than the changes to the video stream.
-
@GreggC has anyone tried using RTSPS instead of just RTSP? Just curious if that might work with the real ports?
-
@Dave1137 Never mind, just tried all the options that were not set in the Protect UI to no avail and also tried the RTSPS as well with zero results. Works GREAT in VLC, now how do I get VLC on my Firestick and is it possible to use VLC to pull up the stream with the Firestick/Alexa apps?
-
OK after doing a bit of digging over at Unifi, I ran across a thread that addresses this issue in detail. First off, the folks over at Ubiquiti think that they added a feature and “feel” it is up to the “3rd” party vendors to make their software conform to UI’s code changes.
And I would have to say that about 99.9% of people using RTSP streams and Unifi and/or Protect UI for surveillance are VERY pissed off.
Some are submitting support tickets as I have done.Here is the Ticket that I submitted:
“Using Monocle Gateway to stream RTSP for camera connectivity to TV’s. After Last Protect Update, ALL RTSP streams via Alexa and Firestick have Stopped working. Stream from Monocle over to evostream.com looks good but comes back with an error on the RTSP stream and will not display. Apparently, you (Ubiquiti), has BROKEN that feature and now you BLAME it on the 3rd party apps??? Fixing Something that BREAKS EVERYONE’s RTSP stream is 1. NOT good business, and 2. Poor Judgment on the release without giving users a way to revert if we so wanted. WE (THE COMMUNITY) EMPLORE UBIQUITI TO EITHER DISABLE THE NEW ADDED FEATURE THAT BREAKS RTSP OR GIVE THE USERS THE OPTION OF USING YOUR NEW BROKEN FEATURE IF THEY SO DESIRE. THERE ARE FAR TOO MANY USERS THAT DEPEND ON RTSP STREAMS TO JUST KILL IT AND GIVE THE “FEATURE” REASON.”
THANK YOU
Dave
Let’s see what they do, if anything. they are known for ignoring major issues, i.e. their topology map for bridges … etc…
Dave Nugent BS MS
Fiber Optics/Network Design Engineer -
Hi @Dave1137
It will be interesting to see how Ubiquiti Support responds and if they are willing to roll-back the recent change.
This is not my area of expertise but reading between the lines I think Ubiquiti is heading in a good direction with eventual migration from AAC to Opus. Along with the introduction of “low latency video”, this seems to be part of continuing improvements to stream quality, scalability, and overall user experience. It’s unfortunate that UI released the changes without warning and some 3rd party clients were affected, but I do believe they’re still operating within the RTSP protocol.
All that said, Monocle’s troubleshooting tips (https://monoclecam.com/troubleshoot/tips) state that Alexa devices only support AAC and G.711 encoded audio streams, and that AAC is preferred (at least at the time of writing). So if UI does eventually make a wholesale switch to Opus, some transcoding might be required for future Alexa integration by any means. Hopefully UI will make such a change optionable in the system settings.
As you’ve noted and your gateway logs indicate, the current problem seems to be with the connection handshake. Other 3rd party clients were either already working fine with Protect 2, or have been able to make the needed adjustment to support UI’s change.
We need to hear from Robert @Monocle on whether he can fix this in the gateway. It would be nice, but my expectations are guarded. Monocle Gateway has been in beta 4 years, does not seem to be progressing towards commercial launch, may be insufficiently supported through donations, and Robert’s activity on this forum seems to come only in monthly intervals.
-
@GreggC Excellent post and yes I agree with you in moving forward and getting away from old protocols. And yes, since UI protect (although most likely proprietary) and VLC using RTSP still pull the cams up, I agree that it is with-in the RTSP RFC. It just would have been nice to offer an option, like they do for “legacy” and “new” interfaces. It’s not a big DEAL for me, since I know how to pull them up when I want. However, it is a big deal for those running enterprise nets that use RTSP for surveillance. It was not right just slamming the door and expect the vendors to jump to fix their software.
Anyway at this point it’s wait and see. I also agree with you on Monocle. It would have been nice for him to jump in on this thread with a heads up in the issue, rather than let us sit here wondering who’s issue it is. And now we know 😁.
-
Hi Guys … I apologize for not seeing/responding this thread until now. Based on what I’m reading in this thread it certainly sounds like (at least at surface level) some issue with the audio stream. Many camera’s continue to include the AUDIO stream in the RTSP communication even if the microphone is disabled. So it does not surprise me that the Unifi cameras behave this way. When using the
@noaudiotag in conjunction with Monocle Gateway, monocle attempts to remove the audio stream from the SDP (stream descriptor) . Maybe this is why some claim that disabling audio may have gotten it working. Incompatible audio streams have definitely been a problem with other camera vendors.To try and shed a little light on how Monocle and Monocle Gateway handle streams … neither the Monocle server nor the local Monocle Gateway software actually read or decode the actual audio and video stream data. Monocle Gateway simply tunnels/proxies the stream on a secure port to meet the Amazon Alexa requirements. It’s the endpoint Alexa/Echo device that do all video/audio decoding. In addition to this Monocle Gateway can optionally attempt to transform (modify) the SDP (stream descriptor) as part of the DESCRIBE step in the RTSP negotiation. These modifications to the SDP are added using the tags such as
@noaudio. So its basically Monocle Gateway reading the SDP from the camera and then attempting certain modifications to make Amazon happy. However, none of this actually affects the raw stream or codecs being used. Amazon has to support the camera’s stream data and codecs or it will fail. And sadly when a camera fails to stream on Alexa, it fails silently … meaning no errors codes nor any insight is provided as to why it fails. It’s literally a black box which makes troubleshooting stream failures very difficult to near impossible.In the past, I had considered for Monocle Gateway to take a more active role and providing options for transcoding camera streams using something like FFMPEG under the hood. This could allow Monocle Gateway to accept a wider range of camera streams and then transcode the output stream to a known working Alexa/Amazon compatible format. When I played with this type of transcoding implementation in the past, the performance was not great and it significantly increased the stream latency. This also increased the complexity and system requirements for the host system that would need to run Monocle Gateway. Hardware supported H.264 video encoding and decoding would probably be needed to even come close to a usable camera stream. Maybe its worth trying to revisit this option and see what’s possible.
Lastly, I don’t have any Unifi cameras to test with. I should probably get one. What would you suggest is a good Unifi camera model to represent a good test platform to try and benefit the majority of users? I do have other Ubiquity network equipment including the UDM-PRO where I could run their NVR application.
I too am frustrated in general by Ubiquity’s lack of follow thru on some of their hardware/software promised features and frustrated with some of their lacking support for features one would expect in prosumer / small business networking equipment. (Mac-assigned DHCP and overriding hostnames come to mind). However, I understand where they are coming from if they are adhering to the RTSP specification and if they have not removed any existing working codecs. Amazon on the other hand I don’t have the same understanding/forgiveness for. In all my experience with Monocle there are just so many camera streams that are incompatible despite meeting the technical requirements that Amazon states and trying to get anything debugged is mostly pointless. The lack of any ability to debug problems with streams is also frustrating and defeating. The inconsistency of behavior between different hardware models and platforms that Amazon puts out is also a nightmare.
<RANT>
Monocle Gateway has been in beta 4 years, does not seem to be progressing towards commercial launch
This is due in part to the inconsistent behavior and support from Amazon and a lack of any meaningful improvements in their support for IP cameras. If anything its only gotten worse since the original launch. When we first started we did not even need the Monocle gateway for most cameras but with the release of new Echo devices this became an absolute requirement for some models but not others. As of the last time I checked there is no support for RTSPS or H.265 codecs which many camera’s now ship with by default. There was also a strong feeling (earlier on) that Amazon could and potentially would pull the rug out from us at any time and leave us with no viable means to continue support. So I think these things were discouraging factors that gave us pause in trying to monetize the solution as we did not want to accept monies and not be able to properly support the product with Amazon’s revolving door of product releases and inconsistent support. With all that said … I am still very interested in maintaining the solution and keeping it running and hopefully finding some time soon to roll out some further improvements. Monetization is just not a high priority unless we can deliver a better experience for the majority of users.
</RANT>
Thanks, Robert
-
@Monocle - Robert, thanks for your reply. I can appreciate the situation with Amazon. Glad to hear you still want to improve Monocle anyway. It’s a neat solution.
I also understand your thoughts regarding transcoding. That’s a tall order.
For proof of concept, supply chain issues aside, the G3-Flex is a relatively inexpensive 1080P POE model that represents the basic Protect feature set well. It will work with your UDM-Pro for live view and RTSP even without a hard-drive.
Please note that with UniFi, there are two ways to do RTSP. The first is where the cameras are stand-alone and have not been adopted to a Protect NVR. In that case, you log into each camera’s web UI to configure its RTSP capability.
The second is where you adopt the cameras to Protect, and then RTSP is delivered as a service of the NVR, not the cameras. That’s how most people use it, and is where we are running into a problem now as per this thread.
Again, what seems to have introduced the problem is that Ubiquiti has recently added a second (albeit empty) audio track to the stream coming from the NVR. I haven’t tested to see if that’s also the case with cameras in stand-along mode.
