"Hmmm, the camera isn't responding"
-
@jg00d3 Same situation. My issue occurred after unifi software update, whereas they introduced a second audio codec into the stream.
I always ran my setup with @noaudio flag, but that only gets rid of the fist audio stream, leaving the second, new, one intact. My current theory is that “rtpmap:96 opus/48000/2” audio option is throwing Alexa off, and causing her to abort. As soon as info about that option is sent to Alexa, the stream closes from her end.
Seems the fastest / most reliable solution would be to update the monocle code to better handle filtering out multiple audio streams using @noaudio flag, or provide an option to filter out specific streams, such as @noopus. Ideally both.Gene
-
@admin @Monocle Any way to block the second audio stream to get this to work? I am totally unable to use monocle now and I was using it on a daily basis prior to this 2nd audio stream update rolled out through Unifi Protect.
Thank you!
-
same issue here. following for any fixes
-
I’m also having the same problem
-
I think I’ve found a (fairly convoluted) solution.
I managed to stumble across RTSP Simple Server which I set up on the same machine running monocle-gateway. I effectively set up RTSP Simple Server as a RTSP server in between Unifi Protect and Monocle Gateway which drops the second audio track from the Unifi Protect RTSP feed.
There were two things to change in the standard rtsp-simple-server.yml file. One was the rtspAddress (to avoid a port conflict with Monocle Gateway):
rtspAddress: :8654The second was to set up the Unifi Protect feed and a second feed which removed the problematic audio track:
cam: source: rtsp://[UDM Pro IP]:7447/[redacted] runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$RTSP_PATH -map 0:0 -map 0:2 -f rtsp rtsp://localhost:$RTSP_PORT/camupdatedI then set the Monocle RTSP path as rtsp://[local address of the computer running rtsp-simple-server]:8654/camupdated, and set the @proxy tag.
It’s a little slow, but seems to work well.
-
@nicholasng nice, though running ffmpeg would introduce an added overhead / delay. How does your setup handle unifi reboot? Would the stream simply need to be restarted, or the whole RTSP SimSrv?
Thanks to @bally12345, I’ve discovered Scrypted, which is another workaround which I’m currently using. Delay seems minimal and as an added benefit I can view the stream on the nest hub in my office, as well as Alexa in the kitchen.
-
@monome that’s a really good point on UniFi reboot - must admit I haven’t tried it but suspect I might need to then refresh the separate relay server. There is some delay but given my use case I hadn’t really noticed it.
I did have an initial try of Scrypted but seem to be coming up against some weird Alexa permissions issue (though given others have had success it might be something specific to my setup) - will give it another go!
-
@monome thanks for the tip on Scrypted. Just installed and it’s working. Good bye Monocle.
-
@choerizo Be sure to use RTSP plugin, rather then unifi. RTSP provies more features (such as no audio), and seems more responsive.
-
@jg00d3 said in "Hmmm, the camera isn't responding":
@admin @Monocle Any way to block the second audio stream to get this to work? I am totally unable to use monocle now and I was using it on a daily basis prior to this 2nd audio stream update rolled out through Unifi Protect.
Thank you!
I just received my new Unifi cameras and will be setting them up and try to resolve this issue within the next week. Removing a second audio channel should be fairly simply … I think.
Please stay tuned …
