unexpected end of stream when downloading large file from Dropbox

FNC TMS FNC Cloud Pack
1

Using FNC Cloud Pack 3.0.1.0

Using TMSFNCCloudStorageServices

Getting this error when at the end of downloading a large (180MB) file from Dropbox:

Screenshot 2023-08-09 FNC Cloud Pack unexpected end of stream

2

Hi,

I have not been able to reproduce this issue when tested here.
Downloading files of +180 MB is working as expected on Android with DropBox.

Can you please provide the following information so I can further investigate this?

  • Which version of Delphi are you using?
  • Which version of Android are you using?
  • Does this happen with any file or only with a specific file?
  • Does this only happen with DropBox or also with other services?
  • Can you download the file as expected on Windows?
3

Delphi 11.3 patch 1
Android 13
It happens with larger files. I'm testing with 180MB files.
Smaller files download as expected.
The Windows version of the app, also using Cloud Pack 3.0.1.0, is successfully downloading large files from Dropbox.
Google Drive is downloading as expected.

4

It's not clear what is causing this error as I have not been able to reproduce it here.

Is the file downloaded correctly after the error happens?
Would it be possible to provide a ready to run sample project that demonstrates the issue so I can further investigate this?

5

Sample projects can be provided in a private message or by sending an email with attachment to help@tmssoftware.com

6

The file is never downloaded.

Other times the TMSFNCCloudStorageServices1DownloadFile() method is called after the download should be complete but the file does not appear on the Android device and ARequestResult.Success is True.

7

The exception is only shown when running with the debugger.
ARequestResult.Success is True.
ARequestResult.resulttotalBytes is 181,149,696 which matches the size of the file.
ARequestResult.ResultString is blank.

When run without the debugger, the exception does not appear.

The file is not downloaded in any case.

8

A sample project (my production project) has been emailed to help@tmssoftware.com.

9

The provided sample project is a complex project with a lot of unrelated functionality. We are unable to test this project here.
Can the issue also be reproduced in a simple test app that only includes the functionality to download a file from Dropbox?
If so, please provide the ready to run test app.

10

I've emailed a ready to run test app which fails to complete a download of a large file (>180MB) from Dropbox with Android 13.

It works as expected on Android 12 and with smaller files.

11

We are currently investigating this issue and will report back as soon as possible.

1 Like
12

Is there progress on this issue?

15

Our apologies for the delay, we are currently looking at this issue.

16

We have further investigated this here. The combination of RAD Studio 11.3 and Android 13 causes a mismatch in the SDK base version. By default, the Android 13 SDK is 33, but the XML template generates 32. Additionally, we have also checked RAD Studio 12 beta field test, and there the Android NDK/SDK is not properly configured, so we cannot test there what Android 13 devices do in combination with new NDK/SDK and the base SDK of 33. For RAD Studio 12, we will need to await the new beta update or the official release. Additionally, we cannot debug on Android 13 devices with RAD Studio 11.3. More information can be found here.

In order to properly test here what the issue is exactly with Android 13, we will need proper debugging, which is currently not the case due to the status of Android 13 in combination with RAD Studio 11.3. As soon as RAD Studio 12 receives an update in which we can debug properly, we'll reopen this issue and test again. As this issue is more complex that initially anticipated and the broken status for Android 13 devices on RAD Studio 11.3 unfortunately does not allow us to proceed finding a solution for this issue. Hoping for your understanding.

1 Like
17

Given the recent RAD Studio updates, is it time to reopen this issue and test again?

18

We'll investigate as soon as time permits

1 Like
19

I'm currently looking into this.

20

Hi,

Although we are are not immediately able to reproduce the exact error, we have made some improvements to the code that could potentially lead to this error.

  1. Downloading a file was first kept in memory, we have now replaced this with a direct TFileStream, which should a) increase download performance, b) no longer consume additional memory

  2. Changed the way the bytes and number of bytes are calculated and read.

We plan on releasing an update later this week.

1 Like
21

This issue appears to be fixed in the 3.0.2.1 release of FNC Cloud Pack. Thank you.

22

Thanks for notifying!