Working But with Multiple Debilitating Issues about merkury720

[guino]

@richaardvark for VLC you need to make sure you're using RTSP over TCP in the settings otherwise it will drop off after awhile.

Telnet lets you copy/modify files when needed -- basically gives you full access to the device.

When mjpeg/snap don't show anything the reason is usually: 1-the address is incorrect in mjpeg/snap.cgi OR 2-there are missing/wrong files in the SD card.

Feel free to post a zip of your SD card contents (without the SDT folder) and I can review it).

[richaardvark]

@guino Thank you so very much for offering me your helpful guidance here (and for putting this all together in the first place!). I thought it might be easiest to just respond in-line below to your last message.

@richaardvark for VLC you need to make sure you're using RTSP over TCP in the settings otherwise it will drop off after awhile.

I do indeed start VLC from the terminal with the RTSP over TCP launch command. I tried to configure VLC's preferences directly but I guess the Linux version of VLC player (currently 3.0.16 on Debian/Linux) is a bit different and I can't find the 'RTP over RTSP (TCP)' or any comparable setting anywhere. I spent some time looking through VLC literature/Googling/looking at their help forum but still couldn't find this setting. RTSP is indeed mentioned in the preferences dialog but there's no checkbox to enable this (that I can find anyway... 🤷🏻‍♂️). So, I've been sticking with launching it via the terminal command. It works but as I mentioned in my fist post above it isn't very stable. :-/ I don't know if it really makes any helpful difference but just now I assigned the camera a static IP address in my router's firmware, hoping maybe that would help make the connection more stable. Right now, the video is turning solid green and flickering about once every second and then after a little while VLC errors out and I'm booted from the app with error messages. At that point I am unable to reconnect ("connection refused") and then a little while later I'll hear the start-up chime again, and then once more as the camera seems to freak out and then just reboots itself. I believe I followed the directions exactly as instructed but maybe I did miss something/mess something up at some point in the process. Or, perhaps my signal from my router is just too weak? The app (I'm using "Smart Life" instead of "Geeni" or "Tuya" but I'm sure it's all more or less the same thing, right?) at best always says "Signal: 50%".

Here's what my terminal output looks like when launching VLC (sometimes there are many more errors, usually about the timestamp being too far behind for it to keep up with any longer):

richard@HomeServer:~
$ vlc --rtsp-tcp rtsp://192.168.1.240:8554
VLC media player 3.0.16 Vetinari (revision 3.0.13-8-g41878ff4f2)
[000055faea424570] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
qt5ct: D-Bus system tray: yes
Created new TCP socket 37 for connection
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_9
libva info: va_openDriver() returns 0
[00007fe1e808b7e0] avcodec decoder: Using Intel iHD driver for Intel(R) Gen Graphics - 21.1.0 () for hardware decoding
Created new TCP socket 37 for connection
QObject::~QObject: Timers cannot be stopped from another thread
[00007f20ec001310] live555 demux error: Failed to connect with rtsp://192.168.1.240:8554
[00007f20ec002eb0] main stream error: connection failed: Connection refused
[00007f20ec002eb0] satip stream error: Failed to connect to RTSP server 192.168.1.240:8554
[00007f20ec002eb0] main stream error: connection failed: Connection refused
[00007f20ec002eb0] access_realrtsp stream error: cannot connect to 192.168.1.240:8554
QObject::~QObject: Timers cannot be stopped from another thread

Telnet lets you copy/modify files when needed -- basically gives you full access to the device.

Thanks! The Telnet connection is now working. I'll have to refresh my familiarity with the proper syntax/commands for using and accessing files via Telnet... it's definitely been awhile! (suddenly finding myself reminiscing on the days of Windows 95 / 98... haha)

When mjpeg/snap don't show anything the reason is usually: 1-the address is incorrect in mjpeg/snap.cgi OR 2-there are missing/wrong files in the SD card.

Feel free to post a zip of your SD card contents (without the SDT folder) and I can review it).

Thanks for offering to look at this! So here's where things apparently get strange... I went just now to copy/zip the contents of my SD card (minus the SDT folder contents and also I redacted my WiFi SSID and password info from the "ppsFactoryTool.txt" file if that's ok as well) and there are now several > 100 MB "program crash data" files that have appeared, totaling more than 500 MB. Weird. Also weird: after throwing everything from the SD card into a ZIP file just now the size of the entire ZIP file is only 17 MB... 🧐🤷🏻‍♂️🤷🏻‍♂️

One other last quick question if I may... I am totally new to the world of streaming/WiFi security cameras but one other word/feature/protocol I see frequently mentioned is "ONVIF." Do these cameras support ONVIF? If not, what type of functionality are we lacking by not having ONVIF WiFi/IP cameras? Thank you again!!!
--deleted--

[guino]

@richaardvark the fact that you're getting crash data files could be an indication that there's a hardware issue or that you're running out of memory. Many of these devices run on the limit of free available RAM and adding any extra processes (ie busybox running telnet/httpd servers) could be the tipping point to cause processes to crash (out of memory). You may also want to verify that you're able to keep the video stream open 'longer' using the phone app than using RTSP. You should also check if the video stream works in the phone app AFTER it stops working using RTSP. My cheap 'Merkyry 720P' often has issues freezing up the video where everything (including phone app) stops receiving video but seems like it does better with one power supply compared to others but when the video freezes up I also have to power cycle it to get it working again (while the software portion appears to work normally) -- this could just be the cheap hardware+old driver on these devices. In my case I added a cheap tuya wifi wall outlet switch so I can power off and power on the camera remotely when the video freezes (just so you know how often it happens).

On your SD card, you can most definitely delete the core-* files to prevent issues with the ppsapp emptying the SD card.

Your mjpeg/snap.cgi isn't working because you did not set the address for the JPEG as described in step 10 of https://github.com/guino/Merkury720 -- for your patch the address is: 2c17b0

You don't seem to have a play.cgi in your cgi-bin directory either (only required if you want to use the feature) -- you also have to set the address: 2c1fbc on that file before/if using the feature.

You also did not set the SERIAL number of your device in the cleanup.cgi script so you are at risk of the SD card filling up and you'll have to copy+configure all the files again.

You CAN turn off telnet and http servers on your custom.sh file by just removing/comenting the busybox commands to see if it helps with the RTSP crashing -- if it still crashes without the busybox commands you'll know it's not a memory issue (and likely is just a hardware issue). For a hardware issue all I can suggest is trying a different USB power supply and/or a different USB cable -- some of my USB power supplies cause the device to freeze every few minutes (even without viewing the stream). I must also add I am not constantly 'streaming' video from the camera -- I just use the motion detection and motion recording (native from the device) and occasionally open the video stream and/or mjpeg -- still I do not have ANY core-* files in my SD card despite the video freeze ups.

[richaardvark]

@guino Thanks for your help and for all of this information! I think I have everything working now. However the only thing I cannot figure out is the play.cgi file - where it came from originally?

[guino]

@richaardvark you can download it here: https://github.com/guino/BazzDoorbell/tree/master/mmc/cgi-bin I guess I forgot to include it in the Merkury720 repo -- I'll add it when I have a chance.

[richaardvark]

@richaardvark you can download it here: https://github.com/guino/BazzDoorbell/tree/master/mmc/cgi-bin I guess I forgot to include it in the Merkury720 repo -- I'll add it when I have a chance.

Thanks! Was just replying now to say I found it. Thank you again!!!

[richaardvark]

@guino One last quick question if I may and all close out this issue... is there any way to change the port for the mjpeg/snap.cgi from 8080 to something different?

[guino]

@richaardvark you can pick the port in the command in custom.sh: /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080 just be sure to not use a port already in use for something else (i.e 80, 8554, 23)

[richaardvark]

@richaardvark you can pick the port in the command in custom.sh: /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080 just be sure to not use a port already in use for something else (i.e 80, 8554, 23)

Thank you very much! This worked perfectly!

So far my camera seems much happier/isn't crashing and dumping giant files onto the SD card any longer! I had also noticed when I put the SD card in my Linux computer that there seemed to be weird file-permission issues so I formatted the SD card using the actual Tuya/Smart Life app this time instead of my computer and then put the SD card files back onto the drive and it seems much happier now.

I am getting the message "file does not exist!" when I attempt to navigate to the play.cgi link but perhaps I am just not querying it properly? Do you need to put a file name of some sort into the URL?

This is the contents of my play.cgi file, using the play.cgi request address: 0x02c1fbc

#!/bin/sh
echo -e "Content-type: text/plain\r"
echo -e "\r"
# Set here the request address for ppsapp
REQADDR=$((0x02c1fbc))
# Get ppsapp PID
PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}')
# Get file (from command line or query)
if [ "$1" != "" ]; then
 FNAME=$1
else
 FNAME=$QUERY_STRING
fi
# Check file
if [ ! -e "$FNAME" ]; then
 echo $FNAME does not exist!
 exit 0
fi
# Check if it's already playing something
PLAYING=$(/mnt/mmc01/busybox dd if=/proc/$PPSID/mem bs=1 skip=$REQADDR count=4| /mnt/mmc01/busybox od -t x4 | /mnt/mmc01/busybox head -1 | awk '{print $2}')
if [ "$PLAYING" == "00000000" ]; then
 # Write filename
 echo -en "$FNAME\x00" | /mnt/mmc01/busybox dd of=/proc/$PPSID/mem bs=1 seek=$((REQADDR+8))
 # Request playback
 echo -en "\x01" | /mnt/mmc01/busybox dd of=/proc/$PPSID/mem bs=1 seek=$REQADDR
 echo Playing $FNAME
else
 echo "Can't play right now as something is already playing!"
fi

Also, (sorry I thought I was good to go, but I'm almost there!!) for Telnet, the directory structure I'm seeing is different from the SD card directory structure (probably because I'm seeing the structure of the actual camera hardware itself). I've gone through all of the sub folders but can't find the SD card contents anywhere. Is it possible to modify for example the custom.sh file remotely using telnet?

This is what I see:

[18:23:16] root@HomeServer:~# telnet 192.168.1.240
Trying 192.168.1.240...
Connected to 192.168.1.240.
Escape character is '^]'.

BusyBox v1.20.2 (2020-12-05 17:05:42 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/ # ls
proc     sbin     tmp      sys      dev      mnt      nfsroot  root     usr      devinfo
init     lib      etc      bin      var      linuxrc  boot     opt      home

/ # grep -l "custom" *
/ # grep -l "custom.sh" *

[guino]

There are some examples on how to use play.cgi in the bazzdoorbell repo (issues) - I am on my phone but can look it up later. You can modify custom.sh using vi in telnet (if you know how to use it), but it’s easier to just download , modify and upload it with upload.html . The sd card will be under ‘cd /mnt/mmc01’ — what you listed is in the firmware/memory mount.

[guino]

Here's how to use play.cgi: guino/BazzDoorbell#10 (comment)
Here's how to upload files (or overwrite existing ones): https://github.com/guino/BazzDoorbell/wiki/%5BHow-to%5D-Upload-files-on-your-camera-remotely-using-your-Web-Browser.

[richaardvark]

Something still just isn't right. Every couple of days I have to pull the SD card and delete gigabytes worth of crash dumps. :(

The RTSP feed is more or less unusable/useless :( It will work if I restart the camera a couple of times but often won't load or if it does flickers with the entire screen being solid green for 60% of the frames. If it does finally fully load than it will only work for a short amount of time before it starts skipping frames and the timestamp counter becomes more and more sporadic and then eventually the feed goes totally dead. It seems to work much more smoothly at night however, when night vision is on. Perhaps the black and white video is less data to process and doesn't require as much bandwidth to stream?

The mjpeg.cgi stream is smoother and more dependable however a good 1/3 of the bottom part of the video is cut off and is missing though occasionally will flicker and very briefly show.

How can I determine what is causing all of these issues? Can I find any details in these crash files? I will try to reset the camera and start from scratch again but I think I setup everything correctly.

[guino]

@richaardvark

Crash dumps are usually a sign of hardware issues, but that can also happen due to faulty or insufficient power supply. My suggestion is to switch the power supply (possibly for a bigger one) along with the USB cable (with a shorter one if possible) and see if it becomes more stable, otherwise you should just return or claim warranty on the device as that is not normal and likely would happen even without any changes to it.

I have never seen or heard of the RTSP issue you described (green screen). You should make sure you're using RTSP over TCP as the RTSP over UDP (default for most clients) is quite CPU intensive and causes the device to reboot after awhile. The green screen issue sounds like a client side thing combined with poor signal or wifi congestion issues (causing skipping frames). Night videos usually take less bandwidth, so if that's more stable it could indicate wifi congestion, poor signal or hardware issues (wifi module).

The mjpeg issue you're describing (part cut off) indicates that your video feed is highly detailed and requires more than average memory storage. You can fix this by modifying mjpeg.cgi and snap.cgi to increase the number 57336 -- you can try 90000 to hopefully get a full image consistently but keep in mind these devices have little memory and any increase of this value can affect stability (due to less memory available) which can lead to more crashes/failures which are already happening on your device.

You should most definitely NOT be using multiple video sources at once (i.e. phone app streaming, RTSP streamning and mjpeg should not be used combined to avoid memory/cpu issues) - just make sure you test/use them one at a time. If you don't use telnet you can comment out (or remove) the command that starts it in custom.sh to keep memory usage low but it won't change much.

[richaardvark]

@guino

Thank you again for the invaluable feedback - everything is working nicely now! I'm sorry it's taken me 20 days to reply but I have had a lot on my plate recently that I had to tend to and only just now found time to look at this again. Everything is working perfectly and I'll close this issue now!

Implementing your suggestions worked perfectly but I did discover a couple of things that I just wanted to share with you that you may or may not feel are helpful for helping others as they setup their own cameras.

Changing the memory to mjpeg.cgi and snap.cgi to 90000 definitely seemed to help. So far no crashes. I had used the power supply and USB cable that came with the device but at the moment am using a different power supply and different USB cable and it seems to be happier so I will stick with this different one.

Per the main instructions:

• It has also been reported that the default VLC playback is over UDP and causes the camera to use a lot of CPU/resources and causes it to reboot in about 13 minutes of viewing the RTSP feed. You can fix this by starting VLC like this vlc --rtsp-tcp rtsp://ip:8554 OR you can go into VLC settings and selecting RTP over RTSP (TCP) : Click 'Tools > Preferences > Input / Codecs and select 'RTP over RTSP (TCP)' at the bottom, them click 'Save'.

I had been playing the rtsp stream in VLC player over TCP by starting VLC from the command line in a terminal window because I could never find the "RTP over RTSP (TCP)" option in VLC Player's 'Preferences' no matter how many times I looked for it but finally found it just now. I don't know if perhaps it's organized differently on Windows but I am using Linux and there was one missing sub-location in the drop-down tree that was missing from your original directions. I was finally able to find this option here:

'Tools > Preferences > Input / Codecs > Demuxers > RTP/RTSP and select 'RTP over RTSP (TCP)'

This example screenshot that I found via Google matches the way my version of VLC player's Preferences menu is organized. I think it might be helpful for others if you edit the original instruction page to add those two additional sub-menu-tree locations. Just a suggestion.

The other thing I wanted to share that might be helpful for anyone else using Linux is that the "ffplay" command/built-in application seems to provide a much better/smoother rtsp stream playback experience over VLC player and uses less memory. The command that I am now using to view my camera with zero lag/no display issues is:

ffplay -rtsp_transport tcp rtsp://ipaddress:port -fs

• the "-fs" flag is optional but starts the video stream in full-screen/with no title bar or window frame.
  Just wanted to share this stream player client option that is available for Linux users.

Thank you again for your help! I will close this issue now.

[guino]

@richaardvark glad you got it working to your needs.

I also use linux but this is what I have on my VLC (3.0.16) in the 'Simple' view which is default:

I also have played with ffplay and it does work well but not every linux has it available (may need to be compiled manually).

I do appreciate the feedback and information.