Alexa Suddenly Stopped with Unifi
-
yes I know about that issue, I am the one that posted 5 months ago on the UI website about that update and WHY they did not tell anyone about it. You can read it here:
UniFi Protect RTSPS feeds & omxplayer
UniFi Protect
For those looking the REAL port is 7447, NOT 7441 as shown… Also Remove the S at the end of RTSP And remove everything past and including the ?.No this is something else all together - as the logs show, something is not right. Not sure if it was a UI protect update or a Monocle server issue.
View in Topic
-
@pineapplebigshot Here is the UI bitchout post
UniFi Protect Application
UniFi
UniFi Protect
Security
Nice guys Just spent almost 4 hours trying to get RTSP to work on your fake port. Don’t ya think this just might be a bit important information to put out. Or better yet have a pull down or ? Button to explain it. For those looking the REAL port is 7447, NOT 7441 as shown… Also Remove the S at the end of RTSP And remove everything past and inuding the ?.View in Release
5 months ago -
@Dave1137 whoops, didn’t realize that you made the post on the UI forums.
My logs look pretty much the same. I’m running monocle gateway on a rpi that has scrypted installed (in a container) as well. Scrypted is still pumping out video to HKSV, and I can open the RTSP stream in VLC, so the issue seems to be something particular to Monocle & Unifi.
-
trying to post my logs, it keeps getting flagged as spam…
-
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
