-
-
Notifications
You must be signed in to change notification settings - Fork 272
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
Comments
This is the same issue I'm facing with a 4 GB video file. I have tried a couple of combinations:
|
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. |
Are you suggesting using a different app? @Tokobotenkai |
Nope, just trying to provide other information and hopefully it might be helpful for the developer. |
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! :) |
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. |
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.
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 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. |
The connection on the freshly released version Please try again whether this is still an issue for you @Tokobotenkai |
I'll close this as stale as we are now at |
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. |
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 |
I have rewritten the transfer logic which fixes this among other things and will be released as v2.0 (#267). Known issue: File names incorrect on mobile when using the share menu |
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:
Expected behavior
The file transfer should complete.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Self-Hosted
No
The text was updated successfully, but these errors were encountered: