Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Transferring large files keeps disconnecting/ending prematurely #120

Open
Tokobotenkai opened this issue Jun 4, 2023 · 12 comments
Open
Labels

Comments

@Tokobotenkai
Copy link

Describe the bug
I am trying to transfer a video file of more than 500MB via a wireless access point on the same network as my desktop is connected via Ethernet. The transfer proceeds to like 1/3 of the way and just ends prematurely. Smaller file sizes work.

To Reproduce
Steps to reproduce the behavior:

  1. Open Pairdrop app
  2. Click on on the Destination PC
  3. Select Video File
  4. Transfer starts but end even though the screen is turned on. There is no error message.

Expected behavior
The file transfer should complete.

Desktop (please complete the following information):

  • OS: Ubuntu 22.04 LTS
  • Browser: Microsoft Edge
  • Version: 114.0.1823.30 (Official build) beta (64-bit)

Smartphone (please complete the following information):

  • Device: Pixel 4A
  • OS: Android 13
  • Snapdrop App
  • Version 2.2.2

Self-Hosted
No

@0xdsaini
Copy link

0xdsaini commented Jun 8, 2023

This is the same issue I'm facing with a 4 GB video file. I have tried a couple of combinations:

  1. Chrome to chrome(very bad, stops at almost 500 MB)
  2. Chrome to Firefox(stops at around 1GB)
  3. Safari to Firefox: Completes downloading but it doesn't save it anywhere. I can't see it in my Firefox downloads, or in the Downloads folder.

@Tokobotenkai
Copy link
Author

Just for reference, Warpinator between laptops work fine so I don't think it is a network issue. Connecting my Pixel 4A to ethernet or Wifi isn't detected on Warpinator (but seems like a common issue for many phones).

That being said, I do notice when I transfer using the app or browser, it transfers really slowly. However, using the same Wifi network, uploading to Dropbox seems loads faster, but I have no idea why.

@0xdsaini
Copy link

Are you suggesting using a different app? @Tokobotenkai

@Tokobotenkai
Copy link
Author

Nope, just trying to provide other information and hopefully it might be helpful for the developer.

@schlagmichdoch schlagmichdoch added the bug Something isn't working label Jun 23, 2023
@schlagmichdoch
Copy link
Owner

Thanks for reporting @Tokobotenkai and @devesh525s !

This issue is due to the fact that PairDrop is browser based. When the browser runs out of RAM the site crashes and is often simply reloaded. I do not have a problem with a 4gb file on my 32gb ram windows machine but there must be a limit too.

On iOS Safari webpages only get around 200 MB of RAM before crashing therefore PairDrop warns the user that no files bigger than 200 MB can be sent to iOS devices.

Obviously, this is only a provisional solution.

It might be possible to implement the file receival in a way that the file is not saved to RAM first but written directly to disk. That should make it possible to send files bigger than the available RAM of the browser thread.

https://github.com/jimmywarting/StreamSaver.js

https://github.com/jimmywarting/native-file-system-adapter

https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API

I will look into it and try to come up with a solution. If anyone has experience with this kind of problem, feel free to come forward! :)

@Tokobotenkai
Copy link
Author

Hey @schlagmichdoch, thanks for the response!

Does it mean that Edge limits it to 500MB on my end or would that be an android app restriction?

I am running 64GB of RAM.

It is interesting that iOS Safari flags it out.

I found an old interesting post here about browser limits: https://nodachisoft.com/common/en/article/en000005/

I wonder if we can manually increase it.

@schlagmichdoch
Copy link
Owner

I guess that would be a restriction of that android browser. I just transferred the same 4GB file using Edge and it worked fine. Probably that is not just specific to the RAM size but also the number of open tabs, open threads etc.

The code of your webpage maxes out at 1.4GB on Firefox for me so its propably not concices enough.

It is interesting that iOS Safari flags it out.

Not natively. Its just the same for all iOS Browsers and that can be checked easily so I decided for preventing users from running into that error: https://github.com/schlagmichdoch/PairDrop/blob/master/public/scripts/network.js#L445

I wonder if we can manually increase it.

I don't think so. It may be possible to check the available memory via javascript but we would than have to approximate how much memory we need in advance too. Before we find a solution to automatically detect the max transfer size, we should rather move to a solution where almost no memory is needed for the actual file transfer at all by writing directly to disk.

@schlagmichdoch
Copy link
Owner

The connection on the freshly released version v1.8.0 is much more stable.

Please try again whether this is still an issue for you @Tokobotenkai

@schlagmichdoch
Copy link
Owner

I'll close this as stale as we are now at v1.10.0

@bt4ibwem8
Copy link

Does new version already write directly to disk? Because it is still the issue for me. It allways disconnect (1.5GB file) and refresh page on both Firefox-based and Chromium-based Android browsers. I am on Android 13.

@RjEcho217
Copy link

Can confirm this is stil happening. Tryingto send 100mb+ video files on my home network just gets about 1/8th the way done and stops. Smaller files seem to work fine....sub 20mb

@schlagmichdoch
Copy link
Owner

I have rewritten the transfer logic which fixes this among other things and will be released as v2.0 (#267).
Feel free to test the new version on:
https://pairdrop-dev.onrender.com/

Known issue: File names incorrect on mobile when using the share menu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants