Page 3 of 117

Re: 8910w hanging / rebooting based on image data?

PostPosted: Mon Jun 17, 2013 10:28 pm
by jreberry
Telboy, that is too bad you are having reboot problems with your 8910. However, I think the problems you are experiencing may be different than the encoder problem reported in this thread. It is possible the problems are related in some way, but I have not personally noticed any reboot problems. I suggest contacting support. If enough people report problems then maybe Foscam will be more inclined to acknowledge a problem with these models. The encoder problem reported in the thread is summarized below.

Problem: As image detail increases, the video stream fails permanently until the encoder is manually reset (switch to 320x240 then back to 640x480).
Trigger Point: The trigger point for failure is a function of the complexity of the image. Inputs to this function include (but are not limited to) the scene itself, the intensity of the sunlight, and the software image adjustment settings.
Scope: This is reproducible 100% of the time on my 18906. Other users in the forums report this same behavior on 18904, 18905 and 18910 cameras. A current assumption is that the scope of this problem may be all MJPEG cameras.
The Problem Is Not: The problem is not the power adapter, two have been tested. The problem is not the network, both wired and wireless have been tested. The problem is not the web interface, the stream also fails on VLC and other streaming apps.

Re: 8910w hanging / rebooting based on image data?

PostPosted: Tue Jun 18, 2013 8:50 am
by TheUberOverLord
jreberry wrote:Telboy, that is too bad you are having reboot problems with your 8910. However, I think the problems you are experiencing may be different than the encoder problem reported in this thread. It is possible the problems are related in some way, but I have not personally noticed any reboot problems. I suggest contacting support. If enough people report problems then maybe Foscam will be more inclined to acknowledge a problem with these models. The encoder problem reported in the thread is summarized below.

Problem: As image detail increases, the video stream fails permanently until the encoder is manually reset (switch to 320x240 then back to 640x480).
Trigger Point: The trigger point for failure is a function of the complexity of the image. Inputs to this function include (but are not limited to) the scene itself, the intensity of the sunlight, and the software image adjustment settings.
Scope: This is reproducible 100% of the time on my 18906. Other users in the forums report this same behavior on 18904, 18905 and 18910 cameras. A current assumption is that the scope of this problem may be all MJPEG cameras.
The Problem Is Not: The problem is not the power adapter, two have been tested. The problem is not the network, both wired and wireless have been tested. The problem is not the web interface, the stream also fails on VLC and other streaming apps.

Before we start turning this issue into to some across the board issue.

If in fact this is failing with VLC and a MJPEG based IP Camera you have. You can and should be able to review the VLC log. What does it say?

Note: When doing this test, please make sure NO other 3rd party applications for the camera are running during testing. In order to make sure nothing else is contributing to the problem, during the test.

If you don't have VLC installed. You can download it here:

http://www.videolan.org/vlc/download-windows.html

All you need to do after starting VLC to get log data in real-time, is to use the VLC window Menu options:

Tools -> Messages

Minimize the VLC Message window and start your video stream.

IF there are any warnings ("See below about .asf warnings") and errors, you should see them. Please post them back here with the Model of your IP Camera as well as the System Firmware version, installed currently in your IP Camera. Please also include if your camera is in wired or wireless mode, when the test and the test results was logged.

You can use VLC for MJPEG based IP Camera video streams by doing the following.

Replace IpOfYourCamera with the IP Address of your camera. Replace PortForYourCamera with the Port for your camera. You will be prompted by VLC to logon to the camera, before you will see the video stream.

Video Only:

http://IpOfYourCamera:PortForYourCamera/videostream.cgi

Video and Audio:

http://IpOfYourCamera:PortForYourCamera/videostream.asf

Note: You can also change the verbosity level to warnings, errors or debug if you wish. The .asf video stream has always had warnings. Those warnings are not new.

It's suggested, to use the warning verbosity level for these tests. This is because the error verbosity level may not include enough log detail and the debug verbosity may include too much log detail.

The issue is not about VLC warning messages. It's about proving this claim to be true "The problem is not the web interface, the stream also fails on VLC and other streaming apps".

The minimized VLC Message window can be started or normalized at anytime to review current VLC messages based on the verbosity level. The verbosity level can also be changed at anytime.

If your IP Camera model is failing when using 3rd party applications other than VLC, yet when those 3rd party applications are stopped the camera runs normally. It's suggested to visit that 3rd party software applications user support areas, such as forums, FAQ's and see if that application has error logs, so that you can produce the same kind of data.

All IP Camera models have low level interfaces that these 3rd party applications use to interface to these cameras. If that protocol is violated, badly enough. The camera will auto-reboot or can/could freeze. This low level protocol varies based on camera model and can be different for different cameras.

This is why it's important to be able to distinguish where the issue is located. In some cases, some 3rd party applications have created parameters that can be used with their applications. This is another good reason to visit their user support areas to see if anyone else is experiencing the same issues, with the same software. While also seeing if there are published workarounds or new versions to deal with those issues.

Don

Re: 8910w hanging / rebooting based on image data?

PostPosted: Wed Jun 19, 2013 3:44 pm
by jojocat
TheUberOverLord wrote:
jreberry wrote:IF there are any warnings ("See below about .asf warnings") and errors, you should see them. Please post them back here with the Model of your IP Camera as well as the System Firmware version, installed currently in your IP Camera. Please also include if your camera is in wired or wireless mode, when the test and the test results was logged.
Don


I got an 8910 a couple of months ago that seems to be exhibiting this problem. I just tried connecting with just VLC video stream, and it worked just fine when the camera was not pointed outside. I then pointed it outside with the built in webUI, at which point the webUI lost contact. After closing the webUI, I try again with VLC using just the video stream, and it fails:
main error: cannot pre fill buffer
access_http error: cannot connect to 96.47.XXX.XX:XXXX
access_mms error: cannot connect to 96.47.XXX.XX:XXXX
main error: open of `http:// 96.47.XXX.XX:XXXX/videostream.cgi' failed

I'm on fw .49 version and it's connected wirelessly via a very strong, unimpeded wireless signal.

Re: 8910w hanging / rebooting based on image data?

PostPosted: Wed Jun 19, 2013 6:10 pm
by TheUberOverLord
jojocat wrote:
TheUberOverLord wrote:
jreberry wrote:IF there are any warnings ("See below about .asf warnings") and errors, you should see them. Please post them back here with the Model of your IP Camera as well as the System Firmware version, installed currently in your IP Camera. Please also include if your camera is in wired or wireless mode, when the test and the test results was logged.
Don


I got an 8910 a couple of months ago that seems to be exhibiting this problem. I just tried connecting with just VLC video stream, and it worked just fine when the camera was not pointed outside. I then pointed it outside with the built in webUI, at which point the webUI lost contact. After closing the webUI, I try again with VLC using just the video stream, and it fails:
main error: cannot pre fill buffer
access_http error: cannot connect to 96.47.XXX.XX:XXXX
access_mms error: cannot connect to 96.47.XXX.XX:XXXX
main error: open of `http:// 96.47.XXX.XX:XXXX/videostream.cgi' failed

I'm on fw .49 version and it's connected wirelessly via a very strong, unimpeded wireless signal.

Please try lowering the brightness/contrast where it's still acceptable to you, to see if that makes any difference.

Additionally. The latest firmware version is .51 for this camera model:

http://www.foscam.com/down3.aspx

Don

Re: 8910w hanging / rebooting based on image data?

PostPosted: Wed Jun 19, 2013 7:37 pm
by jojocat
TheUberOverLord wrote:Please try lowering the brightness/contrast where it's still acceptable to you, to see if that makes any difference.

Additionally. The latest firmware version is .51 for this camera model:

http://www.foscam.com/down3.aspx

Don


Lowering the brightness helps somewhat, but only at a point where I'm losing image detail. So it's not an acceptable option for me.

Unfortunately, I won't be able to update the firmware until I get back to where the camera is. Another user having this issue mentions here fi8910w-woes-t5640-10.html#p28393 that the .51 firmware does not fix this problem, so I'm not optimistic that would help.

I've written to support asking about the problem. Seems pretty obvious from the posts here that this is a real issue. Unless I can get some sort of guarantee that I won't just be throwing money into a shipping hole, I don't think I would want to bother shipping this back yet. Unless the problem is acknowledged and diagnosed, it would just be a crapshoot as to whether or not a replacement camera would have the same issue.

Re: 8910w hanging / rebooting based on image data?

PostPosted: Wed Jun 19, 2013 7:40 pm
by TheUberOverLord
Yes. my suggestion on changing brightness/contrast settings is not a fix.

My other suggestion about upgrading to .51 was also not a resolution to this specifc issue. There are security issues fixed with the .51 version that you want to have, when possible.

Don

Re: 8910w hanging / rebooting based on image data?

PostPosted: Thu Jun 20, 2013 5:18 pm
by jojocat
My first contact with support claimed this had been addressed in later firmware, although they did not mention which version. I was able to get it updated to 11.37.2.51 anyway, and it did not fix the issue.

I'm awaiting a response back. I encouraged the support contact to participate here.

I'll post back if I hear anything.

Anyone else experiencing this issue, please contact support about it. If they get enough information on the problem simultaneously, it may help them to isolate the problem and fix it.

Re: 8910w hanging / rebooting based on image data?

PostPosted: Thu Jun 20, 2013 10:53 pm
by jreberry
Jojocat, thanks for adding your info and contacting support. Like you mentioned, the more people that contact support, the more likely they will be able to isolate and fix the problem.

Don, thanks for the troubleshooting suggestions. Sorry it has taken me awhile to respond, we just had a baby and life got busy fast. I’ll say that I am surprised by the troubleshooting results.

Info:
Model: 8906
System Firmware: 11.35.2.51
Embeded Web UI Version 2.4.20.6
Network: Wired

I opened VLC and monitored the message window (warning verbosity). As the contrast increased (through the WebUI) the stream failed in the WebUI, but the VLC stream remained stable. This in NOT the behavior that was seen over the last two+ weeks; in previous testing both VLC on Windows 7 and tinyCam on Android have failed as the image detail increased.

This was not in-line with my previous testing, but it made me suspect of the WebUI on Chrome. I reset the video stream, closed Chrome, and then opened the WebUI using ActiveX mode in IE. I was then able to bump the contrast and brightness up to 6 and the stream remained stable in the WebUI. I then tried opening the WebUI in Chrome alongside IE, and the whole camera froze and became unresponsive. The VLC stream and the tinyCam stream were also dead (I didn't have the message window open). Rebooting the camera did not resolve the problem, I could access the login screen, but all other pages were dead. I power cycled unsuccessfully several times over the next 45 minutes. When the camera froze the contrast and the brightness were both at 6.

I waited until it was dark outside and then tried another power cycle of the camera. This time the camera booted correctly. I believe there was too much sunlight and the camera was locking up; waiting until dark allowed the camera to boot and then I could return the brightness and contrast to lower values.

Summary: The testing showed the stream to initially fail in the Chrome WebUI, but not in the IE WebUI or VLC or tinyCam. I don’t have a solid answer for this behavior as previous testing showed otherwise. It was overcast during my testing, so maybe the low intensity of the sunlight had some play on these results. It may be possible that the sunlight placed the image complexity at the cusp of failing, thus the unpredictable results. I’ll need to do further testing on a sunnier day.

--Jon

Re: 8910w hanging / rebooting based on image data?

PostPosted: Fri Jun 21, 2013 10:28 am
by richardu
I have exactly the same problem with an FI8910W that I just purchased.

My camera is initially pointed to a dark area out of a window. I pan and tilt the camera to the desired position and I lose contact with the Web viewer each time it gets to the brighter, more detailed area.

I came to the conclusion it was related to the detail in the image and this thread seems to confirm that.

If I lower the resolution to the lower of the two settings it no longer resets but then the detail is so low it's almost useless for my purpose.

Richard

Re: 8910w hanging / rebooting based on image data?

PostPosted: Fri Jun 21, 2013 10:32 am
by richardu
I should add:

- it happens in both the Web interface in push and mobile modes and also using the tinyCam Android app

- it happens both wired and wirelessly

It definitely appears to be the fault of the camera firmware.

Richard