SimonSimCity / Xamarin-CrossDownloadManager

A cross platform download manager for Xamarin
MIT License
149 stars 68 forks source link

[Android] Some downloads have 0b size #102

Closed RuddyOne closed 5 years ago

RuddyOne commented 5 years ago

I am downloading a fair amount of images from a CMS. For Android I have to download to external storage (as read from this git page) and move it to internal storage.

For some reason after a download is complete and I attempt to move the file I randomly can get "File not found" when attempting the move. After looking into this the files that cannot be moved seem to have 0b size in downloads. I turned off the moving method to test how they look without attempting the move but have the same results.

Oddly its not the files types etc as if I try the download again it will succeed on images that had failed before. I am still investigating but would like to see if anyone is able to help?

Steps to reproduce

  1. Add 100+ image (jpgs and pngs) URLs for download and start.

  2. Images download to Android "Downloads" folder.

  3. Browse the files in downloads to see many of them having 0b in size.

Expected behavior

Whole images should download.

Actual behavior

I get a temp file that is 0b in size.

Configuration

Platform:

Device:

RuddyOne commented 5 years ago

Tested this by adding all files at once and letting it download. This as fast but I have a lot of 0b size files in downloads.

Then tested downloading one at a time. This was slow but no files were 0b size. Any ideas?

SimonSimCity commented 5 years ago

Not really ... Do you have the chance to test it on different versions of Android? Have you verified that it doesn't happen in the simulator?

Could very well also be something vendor-specific, that it only happens on Android ... Could also be another candidate forcing us to push for #34.

Let me know if you see something suspicious which could bring us on here. I currently don't have time to dive into this problem, but will support you as I can. As I also see your dedication towards this plugin, I'd also be more than willing to grant you permission to commit changes to this repository yourself.

RuddyOne commented 5 years ago

I will continue to test like you said.

Just an FYI I have created my own Android downloader (quickly) and added the same list of files for download. It gave the same result (0b size files).

So we can rule out most of your plugin. Pretty much down to the Android DownloadManager from what I can see.

RuddyOne commented 5 years ago

Back to reality... Tested on the a simulator and can see the same issue but this time the files are able to be opened with the correct images showing. Not sure why it says 0b in size for them... Maybe this whole issue is now invalid? And could now be a case of why can I sometimes not move the files after they are downloaded?

Excuse the "spam" comments, I just want to keep track of what I'm doing.

SimonSimCity commented 5 years ago

Keep it going, no spam-level reached yet.

If Android would be the one to blame, #34 would become more valid, since I want this lib to be stable in all use-cases. But since you also report having it in the simulator, I almost search the blame on your server now ...

Please check that your server provides the correct files after all. Track the network traffic - e.g. this helps: https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark

It would also make it visible if the transition of the files went as expected or if there's a communication-mismatch.

RuddyOne commented 5 years ago

So after looking into this more... I have found the downloader appears to be working fine. I still have no idea as to why the files appear as 0b in the downloads folder but I do not think this is the issue as I can open them still.

I think my problem is now more towards moving the files from the downloads folder to internal storage. Using your code from #27 I am randomly getting "FileNotFound" java exception when trying to open the file via a stream (this following line of code throws the exception.

using (Stream stream = ApplicationContext.ContentResolver.OpenInputStream (source))

Note: I am trying to move them to Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);. 99% of the images move and sometimes all of them but more often then not I run into FileNotFound completely at random. I look in the downloads and can see the file present, so Im not sure how this is happening.

Would you like me to open another issue as I think this could now be off topic from the original issue.

RuddyOne commented 5 years ago

I am going to close this for now (as it seems this may not be a problem related to the downloader) and move onto the new issue I have submitted.

RuddyOne commented 5 years ago

Reopening this issue as it appears to be a problem with files downloading with 0 size. I have confirmed this within my other issue #103.

var openFile = Android.App.Application.Context.ContentResolver.OpenFileDescriptor(source, "rw"); Debug.WriteLine("Size:" + openFile.StatSize);

This line is displaying 0 size for some downloads (seems at random) before I try to move them. Any ideas?

RuddyOne commented 5 years ago

Not sure if this is just the OS doing this? All images seem to be present and not corrupted. Up to the owner of this plugin to close this issue based on the above.

SimonSimCity commented 5 years ago

Since I leave this part fully off to Android itself (see https://github.com/SimonSimCity/Xamarin-CrossDownloadManager/blob/develop/DownloadManager/Plugin.DownloadManager.Android/DownloadFileImplementation.cs#L132) I can self-confidently close this issue as the problem is sorely related to internal Android behavior.

The native download manager of Android only provides me a place to notify him of the final destination of the file before the download starts. I give him the address, tell him to start downloading and he manages the rest.

If anything goes wrong in the meanwhile, I blame it on the native download manager of Android.

This said, the only way of getting anywhere close to solving this issue (or any other related to internal Android behavior) is to implement our own download manager, as requested in #34.