Progress not working with mime type "application/octet-stream" about onedrive-sdk-ios

[James24]

Yes @aclev progress not working.

Progress value printing like this

2015-09-07 12:32:57.678 iOSExplorer[3138:40826] progress completed : 0.060407
2015-09-07 12:32:57.685 iOSExplorer[3138:40826] progress completed : 0.030204
2015-09-07 12:32:57.768 iOSExplorer[3138:40826] progress completed : 0.030200
2015-09-07 12:32:57.776 iOSExplorer[3138:40826] progress completed : 0.030207
2015-09-07 12:32:57.784 iOSExplorer[3138:40826] progress completed : 0.030204
2015-09-07 12:32:57.876 iOSExplorer[3138:40826] progress completed : 0.030200
2015-09-07 12:32:57.884 iOSExplorer[3138:40826] progress completed : 0.030207
2015-09-07 12:32:57.893 iOSExplorer[3138:40826] progress completed : 0.030200
2015-09-07 12:32:57.899 iOSExplorer[3138:40826] progress completed : 0.030207
2015-09-07 12:32:57.901 iOSExplorer[3138:40826] progress completed : 0.007090

please test it with all type of file formats. For large size text file also i am not getting exact progress

[aclev]

Hi @MuscleRumble and @James24 Thanks for reporting the bug, I'm looking into it now.

[James24]

Welcome 👍

[aclev]

Hi @James24 and @MuscleRumble I just created a pull request to fix this bug. If you want to try the fix before I merge it you can change your podspec to have pod 'OneDriveSDK', git : => https://github.com/aclev/onedrive-sdk-ios, branch : => dev Let me know if this resolves issue.

[James24]

ok @aclev

[James24]

Superb @aclev Progress working like a charm

2015-09-12 16:39:07.260 iOSExplorer[8916:130156] progress completed : 0.007892
2015-09-12 16:39:07.261 iOSExplorer[8916:130156] progress completed : 0.007892
2015-09-12 16:39:07.270 iOSExplorer[8916:130156] progress completed : 0.030664
2015-09-12 16:39:07.304 iOSExplorer[8916:130156] progress completed : 0.133882
2015-09-12 16:39:07.311 iOSExplorer[8916:130156] progress completed : 0.156654
2015-09-12 16:39:07.326 iOSExplorer[8916:130156] progress completed : 0.179426
2015-09-12 16:39:07.327 iOSExplorer[8916:130156] progress completed : 0.202198
2015-09-12 16:39:07.334 iOSExplorer[8916:130156] progress completed : 0.224970
2015-09-12 16:39:07.341 iOSExplorer[8916:130156] progress completed : 0.247741
2015-09-12 16:39:07.350 iOSExplorer[8916:130156] progress completed : 0.270513
2015-09-12 16:39:07.356 iOSExplorer[8916:130156] progress completed : 0.293285
2015-09-12 16:39:07.365 iOSExplorer[8916:130156] progress completed : 0.316057
2015-09-12 16:39:07.520 iOSExplorer[8916:130156] progress completed : 0.338829
2015-09-12 16:39:07.525 iOSExplorer[8916:130156] progress completed : 0.361598
2015-09-12 16:39:07.534 iOSExplorer[8916:130156] progress completed : 0.384373
2015-09-12 16:39:07.541 iOSExplorer[8916:130156] progress completed : 0.407145
2015-09-12 16:39:07.549 iOSExplorer[8916:130156] progress completed : 0.429916
2015-09-12 16:39:07.584 iOSExplorer[8916:130156] progress completed : 0.521004
2015-09-12 16:39:07.588 iOSExplorer[8916:130156] progress completed : 0.543773
2015-09-12 16:39:07.610 iOSExplorer[8916:130156] progress completed : 0.612091
2015-09-12 16:39:07.619 iOSExplorer[8916:130156] progress completed : 0.634863
2015-09-12 16:39:07.777 iOSExplorer[8916:130156] progress completed : 0.703179
2015-09-12 16:39:07.786 iOSExplorer[8916:130156] progress completed : 0.725951
2015-09-12 16:39:07.816 iOSExplorer[8916:130156] progress completed : 0.817036
2015-09-12 16:39:07.842 iOSExplorer[8916:130156] progress completed : 0.885354
2015-09-12 16:39:07.846 iOSExplorer[8916:130156] progress completed : 0.908123
2015-09-12 16:39:07.856 iOSExplorer[8916:130156] progress completed : 0.930898
2015-09-12 16:39:07.861 iOSExplorer[8916:130156] progress completed : 0.953667
2015-09-12 16:39:07.869 iOSExplorer[8916:130156] progress completed : 0.976441
2015-09-12 16:39:07.877 iOSExplorer[8916:130156] progress completed : 0.999211
2015-09-12 16:39:07.879 iOSExplorer[8916:130156] progress completed : 1.000000

Great Work 👍

[tobihagemann]

Alright, the "not accumulating" bug is fixed, but my main issue still remains:

2015-09-12 13:17:24.562 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 0 of -1  
2015-09-12 13:17:24.563 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 2497 of -1  
2015-09-12 13:17:24.563 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 10689 of -1  
2015-09-12 13:17:24.564 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 15275 of -1  
2015-09-12 13:17:24.566 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 23462 of -1  

...

2015-09-12 13:17:24.944 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 1857910 of -1  
2015-09-12 13:17:24.945 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 1866102 of -1  
2015-09-12 13:17:24.948 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 1874289 of -1  
2015-09-12 13:17:24.949 [...] <NSProgress: 0x7f9ff4bc4320> : Parent: 0x0 / Fraction completed: 0.0000 / Completed: 1879526 of -1 

fractionCompleted is always 0.0 with files of MIME type application/octet-stream, because the totalUnitCount is -1. As I mentioned, the root of cause should lie within ODURLSessionManager.m, beginning at line 160.

- (void)URLSession:(NSURLSession *)session downloadTask:(NSURLSessionDownloadTask *)downloadTask
                                           didWriteData:(int64_t)bytesWritten
                                      totalBytesWritten:(int64_t)totalBytesWritten
                              totalBytesExpectedToWrite:(int64_t)totalBytesExpectedToWrite

This NSURLSession delegate is being called and totalBytesExpectedToWrite is -1. If you look at the documentation of this delegate method, it says:

The expected length of the file, as provided by the Content-Length header. If this header was not provided, the value is NSURLSessionTransferSizeUnknown.

So yeah... it's probably a backend problem, maybe this can't be fixed with this SDK?

[aclev]

Hi @MuscleRumble I haven't actually been able to reproduce this issue. I have tested with different mime types of various sizes. Our service is returning a content-length header. Does this happen for a specific file or any file of type application/octet-stream?

[tobihagemann]

It's kind of a special case, I must say I have only tested it with a "custom" type (but if I look into file.mimeType of the ODItem it says application/octet-stream). I'm working on an app for file encryption/decryption.

Here is one example: http://1drv.ms/1LcKSrK

It's an encrypted file, so you wouldn't see any content, but at least you could try and download it!

[aclev]

Hi @MuscleRumble That file you have is actually being gzipped when you download it. We aren't returning a content length because we don't know the length of the compressed file. For now if you want to make sure the file isn't compressed you can add gzip;q=0 to the Accept-Encoding header of the request. To do you this you can create an ODHeaderOptions object and pass it in when constructing the content request`

ODHeaderOptions *acceptEncoding = [[ODHeaderOptions alloc] initWithKey@"Accept-Encoding" value:@"gzip;q=0"];
[[[[client drive] items:itemId] conentRequestWithOptions:@[acceptEncoding]] downloadWithCompletion:...];

This will make sure the file will be downloaded without being compressed and will have a content-length header.

[tobihagemann]

Thanks @aclev! Everything works as intended now. It "feels" like a workaround, because who knows if this is something that will be changed in the future. But it works for now, many thanks! :)