@Robert Paasche
I see.
Does your FTP server use Linux or Windows?
Something must have been stuck in RAM because after a PC reboot the success
rate (still in binary mode) with your very first tip (">=0" instead of ">0") is
a lot higher. It's still not even close to acceptable though:
With a buffer size (byte[]) of 1000 about 1-2 out of 20 downloaded files are
missing 1-2 bytes.
With a buffer size of 100k about 5-10 in 20 downloaded files are missing 1-4
bytes (sometimes more). I get images with a black bar/image artifacts again and
text files are also affected (missing 1-5 bytes).
With a buffer size of 100 the success rate is about has high as with 1000 and
the download obviously takes a lot longer.
The files with 1 missing bytes will still open fine and it doesn't look like
there's a problem (won't find any problems with that until I try to display the
images in my actual app) but it's nothing I can just ignore.
Thanks for correcting the bit, I tested it with `buffer.toByteArray()` instead:
The files will open now but about 2/3 of them are missing bytes (txt and
images) and there are image artifacts.
After receiving Erwin's e-mail I tested ASCII mode again: It looks like the
success rate with only txt files is 100% and it properly converts the original
files' "\r\n" (created with Windows) to Android's/Unix' "\n".
Binary mode is set properly, at least according to the return value of
`setFileType()`, but after all this testing the only explanation I can come up
with for this problem is that the library simply doesn't like FTP servers with
Windows in binary mode.
The only thing left to test now is using FTP commands instead of `retrieve` and
streams.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
