[Bug] Unable to send certain file

[christaikobo]

Describe the bug
I cannot send this file, every time I send it, the other device just disappears.

To Reproduce
1.zip
Please uncompress this zip file, and try sending the png file within.

Desktop (please complete the following information):

• OS: [Windows]
• Browser [chrome]
• Version [Windows 10 22H2]

Smartphone (please complete the following information):

• Device: [Android]
• OS: [Android 12]
• Browser [Kiwi browser, Pairdrop Android client]
• Version [chromium 124]

Bug occurs on official PairDrop instance https://pairdrop.net/
Yes, and on dev.pairdrop.net

Bug occurs on self-hosted PairDrop instance
Yes

Self-Hosted Setup
Proxy: Caddy
Deployment:

docker run -d \
  --restart unless-stopped \
  --name=pairdrop \
  --hostname pairdrop \
  --net custom --ip ****** \
  -e PUID=1026 \
  -e PGID=101 \
  -e TZ=******* \
  -e RATE_LIMIT=true \
  -e WS_FALLBACK=true \
  -e RTC_CONFIG="/home/node/app/rtc_config.json" \
  -v /*****/docker/pairdrop/rtc_config.json:/home/node/app/rtc_config.json  \
  ghcr.io/schlagmichdoch/pairdrop

Version: v1.10.10

[schlagmichdoch]

I can reproduce this with the file when sending from iOS. Does this happen for you on Android only or also when sending the file from Windows?

The preview code needs to be rewritten and errors need to be catched properly. Sorry for the inconvenience.

[christaikobo]

I tried Windows to Windows and Windows to Android, both failed.

My rudimentary guess is that when sending pictures, pairdrop seems to render a preview/thumbnail, but my picture's aspect ratio is too extreme so it didn't work.

[schlagmichdoch]

That’s probably indeed what’s going on as it is going through fine when we bypass the thumbnail creation by changing the extension of the file from .png to .txt.

Anyways, I thought such errors would be catched and the file would then simply be sent without any thumbnail. I have to look into it to know more

[schlagmichdoch]

Interestingly, it was not a matter of the thumbnail creation itself as that would have been catched. Instead, the created thumbnail in your specific case was too big to get transferred via one webrtc message which was expected. I tried to solve it by changing the thumbnail creation and checking the thumbnail bytesize after its creation.

Please test whether this is resolved for you as well on this test instance: https://pairdrop-next.onrender.com/

[christaikobo]

Glad to report that it is fixed!

I will leave it to you to close this once you merge the PR.

[christaikobo]

Also happy to know that you got some time to come back and work on paridrop.

Is 2.0 expected to come out in the near future?

[schlagmichdoch]

Glad to report that it is fixed!

Great! I’ll close this, when this is merged into the master branch.

Is 2.0 expected to come out in the near future?

I guess so. There is a backlog of issues that need to come first in a minor update and everything for 2.0 needs to be strapped together but I think I will get there soonish