Trouble with gateway [SOLVED]



  • I’ve been trying for some time now to get this working but no joy.
    NVR is a Seculink (a generic box)
    it does do rtsp streams. I have it working just fine with iSpy & iVideon. I have tested with VLC, also AOK.
    VLC reports:
    Codec: H264 - MPEG-4 AVC (part 10) (h264)
    Resolution: 704x482 <<< this is stream=1, stream=0 showed 1280x720 & neither works.
    Decoded format: Planar 4:2:0 YUV

    I have the gateway running and it starts with no errors. Further I have confirmed there are no port conflicts (443, 8554, 8555).
    I have downloaded the properties file & set the IP to be the correct one (10.63.78.125, statically assigned).

    I am able to ping the proxy address defined.

    I’ve tried with my FireTV cube & am now trying with a Show 8. Same results on both.

    URL in cam config is rtsp://10.63.78.101:554/channel=1&stream=1.sdp (101 being the IP of my Seculink box).
    I’ve tried basic and digest log in but from the logs, it doesn’t appear that authentication is the issue.

    I’ve tried both resolutions. I have audio codec set to none as these cams don’t have any.
    I have tags @noaudio, @tunnel. I’ve tried it with & without @noaudio
    Tried @proxy and that fails immediately with a 404 error.
    @tunnel tries like 3 times and my Show kinda blinks/flashes but I get nothing & she eventually says the camera isn’t responding.

    I tried to upload my monocle log (upload file) [0_1577934933029_monocle-gateway.log](Uploading 100%) but your system but your system balked saying it only likes jpeg, jpg, png & gif which seems odd since you have other tool buttons specifically for uploading images.

    Any suggestions or guidance would be highly appreciated.





  • added a Google drive link to a copy of my monocle-gateway.log.

    also, from the camera feed history, it does appear that it’s trying to work normally.

    {
    “timestamp”: “2020-01-02T00:52:37.901Z”,
    “request”: “InitializeCameraStreams”,
    “response”: [
    {
    “uri”: “rtsp://%USER%:%PWD%@10.63.78.101:554/user=guest&password=test&channel=1&stream=1.sdp”,
    “proxy”: “rtsp://6fa4afa3-ce18-4dd8-a908-9da110876d88.mproxy.io:443/STREAM:dfed7bc2-e524-4797-af61-b7a1592c5ad9?session=600ba54c-ebf1-4779-a214-a9e29260d278”,
    “resolution”: {
    “width”: “704”,
    “height”: “480”
    },
    “authorizationType”: “BASIC”,
    “videoCodec”: “H264”,
    “audioCodec”: “NONE”,
    “protocol”: “RTSP”
    }



  • Not sure why there has been no response whatsoever. Even a “huh, I got nothing” would be better than no response at all.
    Fortunately, another person’s post did get a response and in that I found a solution.

    The suggestion by the moderator to test with @fakefmtp or @ntpnow did the trick.

    In my case, @proxy, @noaudio with @fakemtp got things working.

    While this is great & makes me happy, I could have figured this our some weeks ago had the documentation had any reference to this optional tag “@fakemtp”. It does reference @ntpnow but nothing about @fakemtp.

    You might update the doc with that tag and any other hidden gems in order to save us all a lot of time & trouble and probably make less effort for you responding to a lot of unnecessary posts.

    Just my two cents. Having said that, I appreciate the software & the work you’ve put into it now that I’ve got it actually working.



  • @bigtxnutz ,

    Apologies for the delayed response. I’ve unfortunately had to take a few weeks off from Monocle to deal with other priorities in life. I’ll be trying to play catch up over the next couple of weeks.

    Glad to hear you were able to get it working using the tag: @fakefmtp.

    You are correct in that its not documented at all as this is an experimental tag and may not be supported by all distros of the gateway software. My hope in future versions is to be able to auto-detect this type of condition and not have a reason for this tag to exist. But we are not there yet and it’s a work in progress. So in part it’s not documented because we don’t want it to exist permanently and in part because its very experimental. It’s basically lying to Alexa about the stream encoding just to get her to accept the stream and attempt to play it.

    Thanks, Robert


Log in to reply