Posts made by joseph_1979

@faasio82_480971996033257 4.28.0.8 is the most stable. Depends what cameras you have. If you git Argus then stay on 4.28 version.

Can you let us know when we shall have a stable Android application since the failed updates 4.49.0.X? Hope that this time you have learnt a lesson that before launching a product you need to have adequate testing and passed the necessary quality? Your rating has been fallen on the day with increasing complaints. You are taking too long to solve bugs. You are not consumer oriented at all. We consumer expect a good product for which we have paid.

@reolink-fiona There are issues of push notifications on Argus 2 with the 4.29.0.X updates and still not yet solved. Support tells you to restore the camera and set the PIR and don't touch it again as the problem will crop up again. This answer should be for a few days until a new release is created but not prolonged for over 4 months and the problem is still there. And this is not the only problem. Why it takes too long to preview a recorded video? Sometimes it will load after 10 attempts. I have no issue of bandwidth on neither the Wifi (1GB/300M) nor on the smartphone (165M/48M). There is something wrong in the protocol. And why when I change to clear the sound chops and the video freezes? It is definitely a camera issue either the algorithm or processing power. This is evident on both Argus 2 and RLC511WA.

@reolink-fiona What customers expect is immediate bugs resolution and improved functionalities. Why the support team takes so long to sort out issues? Have a look at the myriads of complaints raised in play store. The same complaints are raised after each update. Other competitors act immediately and so customers confide in them.

Can you let us know when the new stable android client shall be available? Hope that this is rigorously tested before being released and won't bring additional issues as has been the case with most updates. It is frustrating to have security cameras which will no longer be fully functional following a client update. This is unacceptable in security area. A colleague has the TAPO from TP-Link and rarely he complains of an application issue following an upgrade. It is totally seamless as it should be. Giving a cumbersome workaround is not the way forward like restoring the camera and don't deactivate the PIR. If you need to compete you need to hear your customers and improve the entities which are not at the expected level of satisfaction. You are not alone in this market.

@reolink-fiona Issue is still there with 4.29.06. Solution is to rollback to 4.28 version. Whenever the PIR is activated from the application, the schedule is disabled and so nothing is triggered. Default should be activated at all times for all days. Moreover the recording is disabled and so nothing is stored on the SD. This really shows that testing is minimal. You need to invest in more testing as otherwise customers seek other suppliers. In the website please include all previous applications so that customer can rollback.

Note that email notification works. So the issue is with push notification and maybe there need to be changes in your server handling the push notifications.

@reolink-fiona Surely that the team has to prioritize and evaluate their implementation. This is what I do at work. But at least there is the list with the time lines and updates. Listening is not enough. Customers seek action.

Hello,

In this chat there are a lot of fantastic ideas and it would be great that these are somehow collected in a table and Reolink support give a follow up say every week. Customers wish to know what is being done on each proposed suggestion or issue. Informing customers that your suggestion will be forwarded to the engineering team is not enough. Customers have to be constantly updated. And one must give some proposed dates of implementation. Reolink engineering team has to be aggressive in implementing new functions and sorting out bugs. Other suppliers takes this seriously and sort out issues quicker. We are here not just to complain but to improve your products and support.

@reolink-fiona I opened a ticket with support and have no issue to have direct communication with him. I am an engineer too.

@philippe this is not the right place to tackle the issue. Will take it up through support. Just do the same.

@reolink-lorenz all you need is to increase the cache and once connectivity is established then transmit the packets.....but the ftp transmission rate from camera side has to be increased and not leaving at St merely 1.2Mbps.

@crimp-on_62210811129 that's the trend with most suppliers. No rigorous testing and most important to be first in the market. Time is money and support costs amd that's a burden.

@bevgaskin_499300720500895 ... Just pull it out. I suggest you to insert the SIM in your smartphone to check that you have the data service. You need to add the APN if your SIM provider doesn't provide the auto setup through an SMS.

Hi Reolink Team,

I did capture some traces at both the RLC511WA and the Client sides and noticed that the all the packets transmitted by the camera have reached the clients. You have a byte denoting the packet number. When the playback was set to low, the video preview was smooth and the sound was continuous. This means that at low resolution setting the camera was able to transmit the packets at a CBR with no packet loss or delays between packets.

Then I changed the resolution to CLEAR and despite that there were no missing packets, the video can be seen sometimes freezing and the sound chopped. This is apparent when there is movement in both live and previews. There was no issue of bandwidth at all and both the source and the target were on the same subnet. Thence the issue is at source. It could be inefficient H264 encoding (I guess software encoding is used) at high resolution or hardware issue. I also noticed that the max downloading speed for FTP is 1.2Mbps. This is low especially when you are on the same subnet.

I even changed the bit rate for 5Mbps with the recommended value of 1536kbps but didn't observe any improvements.

I checked another model, the Argus 2 and the same issue has been observed at high resolution. Appreciate if the engineering team check and get back to us with their findings.

Regards,
Joseph

@philippe France Orange I used to deal with them on transit traffic but no longer. Connectivity is right and you are using a simple switch. See if you see any transmission issue on the egress side using Wireshark. For streaming Reolink are using UDP as most suppliers do for P2P. UDP is a much faster, simpler, and efficient protocol, however, retransmission of lost data packets is only possible with TCP. In my previous reply I have asked if Reolink can change the transport on our profile and we test. Moreover it could be that the decryption and H264 decoding routines at the client side are not efficient at high speed and Reolink need to optimize it. Reolink should change the H264 to H265, something which has been implemented by the competitors for quite some time.

Nevertheless a delay if 3 to 4 seconds is expected to play the first video but subsequent videos should play immediately. The protocol is encrypted and not so easy to decrypt.

I also noticed that the Reolonk camera is sending the RTSP with DSCP DF (CS0). This is best effort. I would recommend Reolink to increase this to CS4 (higher priority). Indeed the Internet is a jungle and nobody follows the rule and so there are a number of operators which treat all traffic as best effort. For instance VOIP is assigned DSCP 46 (EF) which has the highest priority over any other traffic.

@philippe This only holds when the peer and the camera are on the same subnet. A 5M camera requires 15Mbps bandwidth and you can check it out using the Reolink client and Win task manager. I did change the network and used LTE and here I noticed that sometimes the video freezes and the soun is chopped when setting the playback at high resolution. I didn't notice any errors in transport. Perhaps not all the packets are arriving at the destination. One can check this if Reolink Administrator changes the transport from UDP to TCP and we check it out through wireshark trace. I had no issue on the UL/DL speeds as I changed the configuration from the HLR. I think that Reolink engineering team has to delve through this using distinct networks (Wifi and LTE). The application needs a lot of improvements (and stability) and they need to have rigorous testing before releasing the application to the general public. On the other hand it is not that easy too as the appl has to execute on numerous devices with different OS and configuration. Anyhow we are here to assist Reolink Team to improve their products.

BTW where your WAN connected to? ISP? And what is the UL/DL speeds?

@faasio82_480971996033257 Issue is more upload bandwidth related (camera side). If you are on the same wifi network the loading and viewing of recorded videos is very fast.