Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[djvitamind]

Everything seems to be working ok but for some reason all images that are uploaded are 0 bytes in size.

FTP is working and images are getting uploaded.
I was using firmware 1.02 and no luck so I upgraded to 1.04 and still having problems.

I tried restarting the camera as well.

Any suggestions?

Thanks,
Derrick

[ryyyr]

Same problem with my camera. It happens when upload to FTP is triggered by motion detection. Almost 80% of frames are 0 bytes. Test upload performs well.

The camera is DCS-930L . Firmware 1.03 .

[Allen]

the latest DCS-930L firmware is v1.08.
Maybe you should try to upgrade this.

[acellier]

    We were having a ton of these zero-byte files last year, and finally discovered that we had a cable shield intermittency that caused periods of low SNR on the cable (internet) signal. After fixing that, there were none for a long time. You may want to take a look at the cable modem signal-to-noise ratio, and the logs; also the router log, for any interruptions.
    Recently, we've been getting these again; but it's been a long time since the firmware upgrade,
I don't think it's the firmware per se. We have 1-DCS-932L and 3-DCS-930L in use, set to ftp upon motion detection. All with latest firmware. I've tried both "passive" and "active settings" for ftp mode; no difference noted.
    My stored-image viewing is done via web browser, using a php/html/javascript program that chokes on these things. So I modified the viewing script to find them, and move them to a holding folder for examination.
    Here is a sample of a recent group, in this case only on the DCS-932L -
http://img.photobucket.com/albums/v321/acellier/zero-bytes/zerobytes2013-06-03.jpg
    I do wish the ftp interchange was more robust!

[acellier]

I have added another screen shot of zero-byte jpgs for several days.
I notice that some tend to happen right at the hour, e.g. 2:00 PM, sometimes on both cameras.
I wonder if the camera tries to update from the time server on the hour, and maybe there's a conflict?

http://img.photobucket.com/albums/v321/acellier/zero-bytes/zerobytes2013-06-07a.jpg

On the other hand, there may well be more than one cause (complex problems often work that way!) as today I got one while manually ftp'ing a photo (not from a D-link) - never saw that before.

[acellier]

     We added another screen shot of zero-byte jpgs for several days to the photobucket page ...
http://img.photobucket.com/albums/v321/acellier/zero-bytes/zerobytes2013-06-10-14a.jpg
    NOTE: my server is rather nonchalant about changing the apparent time zone between our PDST, EDST, and GMT - so refere to the time in the filename rather than the server's time.

     We had TURNED OFF the NTP time server for one of the cameras (drat, now I forgot which) yesterday, yet still got some simultaneous zero-byte files today at 1100 and 1300, in addition to some more random ones.
    We have been running ftp as "active" rather than "passive" for several days.

    So neither of those factors seems to explain it.
    Inquiries to the server folks have been fruitless.
    I'd be interested to know how many other people experience this phenomenon?
   

[acellier]

I guess not very many people having this issue
In the past month I've had about 150.
    see at  http://smg.photobucket.com/user/acellier/library/zero-bytes
* independent of wired or Ethernet (currently one of each here).
* independent of camera tyoe (one DCS-930L, one DCS-932L here at present).
* independent of FTP mode (passive/active)
***They seem to happen on 20-minute multiples, e.g. 0720, 0940, 1420, 1520, 1900 ***
... at least that was exactly true in the latest week and most of last month except for June 20 when there must have been something else going on at 0853, 0905-07 as I fiddled with additional cameras

[RYAT3]

I guess not very many people having this issue
In the past month I've had about 150.
    see at  http://smg.photobucket.com/user/acellier/library/zero-bytes
* independent of wired or Ethernet (currently one of each here).
* independent of camera tyoe (one DCS-930L, one DCS-932L here at present).
* independent of FTP mode (passive/active)
***They seem to happen on 20-minute multiples, e.g. 0720, 0940, 1420, 1520, 1900 ***
... at least that was exactly true in the latest week and most of last month except for June 20 when there must have been something else going on at 0853, 0905-07 as I fiddled with additional cameras

What is the FTP service?  Is it local or in some cloud or internet FTP site?

I turned off FTP local... as it was appeared to be flooding my ftp server and gumming it up... it looked like each ftp image was a new connection from what I could tell... this was from a dcs2230.

[acellier]

my 1and1 server is in Pennsylvania.
frame rate to the distant server is about 2 fps (on "motion")

I don't recall ever getting a zerobyte when we ftp to local machine (but then get 15 fps on "motion", way too much).

My conclusion is that something in the camera causes it - maybe, at each 20-minute time mark, the camera must be too busy to process the ftp return ack - I posted many months ago about signs that the little oprocessor seemed overloaded - many of those symptoms have gone as firmware improved.

[acellier]

@ javalawyer -
    Do you have a communication path to D-Link ENGINEERING so we could discuss my findings with them? The usual tech support path is extremely unsatisfying for lack of technical depth.
    I really think that the camera processor tends to get bogged at the even 20-minute epochs, and can't respond properly to the ftp responses from the distant server - but, if we were to choose a closer server, probably we would be swamped by the (unadjustable) higher frame rate.
    We have been tasked by our community association to set up some ip cameras and server - but this is a dilemma for use of D-Link products, which we would like to be able to use as we have developed compatible software for viewing the stored image history.

[acellier]

The vast majority of these zero-byte jpgs occur at times of exactly hh:00, hh:20, and hh:40.
We have experienced 299 of these events in the past 7 weeks, as shown in screenshots of the zero-byte files posted at:
http://smg.photobucket.com/user/acellier/library/zero-bytes

During that 7-week period we ftp'd a total of approximately 80,000 jpgs; so the error rate is close to 0.5 percent - this is really poor performance.

Clearly, the DCS-930L (and 932) processor is sometimes too busy at those specific times to complete the ftp packet exchange with the server.

[acellier]

Strangely, in the final 12 days of July, we saw only 2 of these events - and none so far in August!
No changes to the system. Cameras have not been powered off, to the best of my knowledge. ...

[acellier]

Spoke too soon about August - they started in again on the 13th, and there have been a ton almost daily since.
Almost always on 20-minute multiples, e.g. 0720, 0940, 1420, 1520, 1900
Currently from 2-930s and 1-932.

Images at
<url>     http://smg.photobucket.com/user/acellier/library/zero-bytes     </url>

[Notworried]

I just set up an FTP server and I am experiencing the same 0 byte files, and more. The more part is that the camera is flooding the FTP server with images that are not even a second apart. There are at least 50 of them with the 1:47 time stamp. They are about 8K each.

[Bushman]

I have this issue and I'm running 6 gbps WiMax.  Turns out that the FTP server is unable to accept this sort of rapid fire pic upload.  NO idea how to fix it other than reduce the frequency of uploads.