V380 Pro For Pc
Doretta Castoe
the support answered me with the patch, it differ a lot from the other posted in this thread. I tried one time and just get the rtsp port opened, but i tried inserting some commands to bring up telnet and the patch does not even run again
later i will email the support team again asking for a way to open telnet.
the upgrade for my cam is just this mentioned in this forum Cannot connect Chinese 360 IP cam through ONVIF IP Cam Talk
To set this up, you need to get the patchv380 linux executable from the github link above. At the bottom of the readme he has a link to his blog post where he describes the update process in more detail, if you are interested. The create two files: exshell_bfu.sh and exshell_afu.sh.
This runs at the start of the update and makes a copy of the local_update.conf file because the update process deletes it (in my experience). Then it makes sure a script named run.sh exists and is executable and runs it.
This runs after the update completes (but before the update process changes the files) and waits for 30 seconds, then puts the local_update.conf back in place and deletes the update_record file that the camera creates to know the update happened. Basically, it puts things back the way they were so the camera will process the update again the next time it starts.
Also create a run.sh script on the sd card that contains your code you want to run for the update. Anything in the run.sh script that will take a while to execute should be backgrounded, otherwise the update will never complete, the camera will never connect, the files will never be put back to start the update again, etc. For my run.sh script to get a root telnet session, I used busybox telnetd instead of just telnetd because the plain telnetd did not seem to connect properly. The below just starts telnetd on port 23 with an sh shell as root (because thats what the update runs as).
Hi there. I just made an account here because i just purchase one of this v380 camera. I wonder if there is a mean to disable the auto night mode so it always shows color. I already tried taking off 2 wires inside. The one for ir led and the one for the lens filter. But it still get black and white whenever it senses lack of light. Which i think the sensor is too sensitive. Its not even dark in my room and still it switches to night mode. I really want to disable it. Can anybody here help me? Thank you.
And oh yeah, in the v380 app there are no settings or no option to manually disable night mode. And this is my firmware version.
Screenshot_2022-01-25-15-33-39-630_com.macrovideo.v380pro10801920 79.8 KB
i have one more issue with this
when i am using my home PC and give nick name to connected camera and use same login details with another pc for same Application v380 on windows PC then i can find camera but nick name become empty. Any suggestion how to hold nick name for same login details and different devices.
I have baught two different pan tilt V380 cameras from e-bay.
I can watch both on my smartphone
However on my pc (win 10 app MVCMS) I can watch only one of the them. The second one, while it seems to be connected it appears no immage. Instead it shows the indication (-2).
Any help?
Is there something I can do?
Good morning, since I updated the versions of the internal software of the cameras, the quality of the video was very low, did someone happen to it and could I solve it?
the image has a lot of noise, and the night vision impossible to walk. nothing is seen
I got a reply just after 10 seconds and after sending a screencapture of firmware versions I received upgrade files that you put on a SD card in the camera. He wrote that different versions needed different upgrades, we know that from earlier experiances, so ask for support for V300-V380 based cameras at v380te...@gmail.com
This did not work for me. The camera does say something in Chinese during boot twice. Bu still do not see any open ports for rtsp after reboot. What rtsp stream are you using now when it is working for you?
A while ago I wrote a few articles describing how to use the Flueron, V380 Pro as well as the Raspberry Pi Zero (with the camera module) as cheap wireless CCTV cameras for home usage. A couple of months has passed and my setup is still running flawlessly with very few issues observed.
Among the cameras, the Floureon CCTV units can be considered to be the best. These cameras are self-sufficient and requires very little intervention from the end user. Over a period of a couple of months, I observed only four incidents among the Flueron units. In the first incident, the camera continued to be accessible wirelessly, just that all RTSP streams only produced the following static picture:
The picture looks as if the camera sensor was covered with something, which was obviously not the case. The timestamp and camera name (not shown in the above picture) were still displayed, which indicated that the CCTV was otherwise still functioning properly. The failure was detected by my server which constantly analyzed the CCTV snapshot via imagemagick, and looked for any unusual changes in its standard deviation (stdev) factor. The following is a typical output of imagemagick running on Raspbian on a similarly corrupted image:
The standard deviation in the above output is 0.098153. Standing alone, this number is not useful. However, you can run the same command on the snapshots taken over a typical day, look for the minimum and maximum values, and have your monitor script generate a warning if the stdev of one or more snapshots falls outside the expected range. A typical range would be something like [0.15, 0.25]. This is how I managed to detect this failure shortly after it happened.
In the second incident, the camera still produced a recognizable picture, albeit with some red artifacts. As the artifacts do not significantly alter the characteristics of the image, the failure was not detected by my monitor script using imagemagick. Below is a portion of that image:
In the third incident, despite losing wireless connection and failing to recover after that (I waited for more than two hours), the camera still worked normally and produced recordings on the SD card.
I worked around the issue by manually moving the lenses to the desired position, switching off the camera, opening the case manually and finally cutting power to the PTZ motor. On my unit, the PTZ mechanism is open-loop. There are only two wires to the motor to provide power and there is no feedback signal to tell the micro controller whether the PTZ rotation has been performed. With this, cutting the power to the PTZ motor does no harm and the camera with the faulty PTZ mechanism can be used again as a normal camera pointing a fixed location. If your camera PTZ motor has a feedback path, then cutting the power might not work as the micro-controller might know that the motor no longer works and refuse to power on. If this is the case, you might need to keep the wires to the PTZ motor and simply remove the mechanical parts connecting the motor to the lenses so that the camera will not return to an awkward position after a reboot. Obviously a better way would be to modify the firmware to disable the PTZ self-check, which is a tall order without the source code.
It is worth mentioning that the Flueron units that have issues are all semi-outdoor units located further away from the main router; one of them is also subject to occasional rain drops.This indicates that the issues were mostly due to intermittent wireless reception and outdoor conditions. For example, tiny water drops could have come into contact with the circuit board and temporarily shorted out the camera sensor or wireless chips. On the other hand, those units which are located indoor are still working fine after several months without any issues observed.
For the V380 Pro camera, no major issues were observed, except for once, the camera lost wireless connection and required a manual reboot. In my setup, as the V380 Pro does not have an option to upload the footage remotely, I have an ffmpeg process running on another server to periodically (e.g. every 60 second) take a snapshot from the camera RTSP stream. While almost all snapshots are satisfactory, once in a while I received the following corrupted snapshot which contained nothing but repeated patterns:
As the color patterns on the corrupted image somewhat resembled the expected image, I suspect the corrupted image was created when connection was suddenly lost in the middle of taking snapshot, and ffmpeg was forced to use whatever data was available in its buffer to generate the output. The remote MP4 recording taken by ffmpeg at the same time did not have such issue. The issue was therefore most likely not caused by the V380 Pro camera itself.
As for the CCTV units running on Raspberry Pi with camera modules, no strange behavior was observed. As a fallback, I have a script running on each unit which automatically reboots the machine if it cannot ping my main router. Fewer than five reboots were observed, which all came from the units located further from the main router. If time permits, I will study how to add an external antenna to these units, but as of now, this is not an issue for me.
All things considered, I think the setup suits my needs well, both in terms of functionalities and costs. I also purchased a few more v380 Pro, Flueron as well as Raspberry Pi Zero as backup units but so far no replacements have been needed yet. Needless to say, you should configure your router to disable Internet access for the V380 Pro and the Flueron cameras to rule out any security concerns. Remember to replace the SD cards on the cameras every 1-2 years to avoid flash memory wearout, and the setup will be almost as good as any professional setup, at a much lower cost
575cccbfa5