15 second wait per file _after_ each has transferred
jimmiedave opened this issue · comments
User, not a developer.
Describe the bug
Watching the progress bar, files whoosh to my phone very quickly, and then the UI sits and does apparently nothing for 15 seconds on each file. It appears OpenMTP can rapidly transfer all the files, but does not.
Additionally, I have to wait as much as 60 seconds before a file transfer begins, with no user feedback to tell me whether my input has been received at all - the UI just sits there like I haven't copied files. I sit like an idiot wondering whether or not to drag them in again.
Expected behaviour
OpenMTP Starts copying immediately and after a file is copied, moves immediately to copy the next file once this file is copied.
Current Behavior
After >45 seconds, OpenMTP begins copying the drag-and-dropped files.
OpenMTP quickly copies each file (says the progress bar, and the MB/Sec indicator which can go into the 40MB/S range) and sits doing nothing for 15 seconds before moving on to the next.
Possible Solution
- Is it waiting for something on the network? I've tried disabling my outbound firewall - no luck.
- Re-indexing the destination each copy? (yes, there are a lot of subdirectories in there, but shouldn't be a problem for a file copy app that's only looking at the parent).
- Is the progress bar indicating the time it takes to fill a buffer, not the time to actually copy the file?
Steps to Reproduce (for bugs)
-
Drag-copy a folder of 10 smallish (<15MB) files to a destination in the phone panel (a folder of MP3s ripped from a CD, for example).
-
Wait 45-60 seconds for anything to happen
-
Watch the progress bar quickly go across the screen, and once it hits 100%, just sit there for 15 sec. before the next copy begins.
Context
How has this issue affected you? What are you trying to accomplish?
Takes a VERY long time to do a simple folder copy.
Did you make any changes to the codes after cloning it?
No.
Your Environment
- MacOS Catalina 10.15.7
- OpenMTP 3.1.15 (I'd use latest, but it doesn't run on Catalina)
- Copying files via USB3 with a quality cable
- Galaxy S10e
- Android 12
- One UI 4.1
- Kernel 4.14.190-23725627-abG970USQ8IVK1
Attachments
Screenshots
A file is 100% copied.
Same file 12 sec later, still 100% copied.
Thanks for the detailed input @jimmiedave. this issue is currently being investigated. I shall update you asap.
Same here. Galaxy S22+, OpenMTP 3.2.0, MacOS 13.1 on M1, Kalam mode
Switched to another Android (not Samsung) phone, worked just fine. Legacy mode worked too with both phones
OpenMTP v3.2.10-beta.2 is now rolling out.
Note: This a pre-release version and it might be unstable.
Features
- Fixes - the app crash while downloading files
- Fixes - the app crash on older versions of macOS
- Fixes - the app crash caused while transferring files a large number of files.
If you are on an older version of OpenMTP and have frozen the auto-app update option for the sake of preventing the app crash, you may re-enable it from Settings > Updates > Automatically Check for Updates
Note: We have now officially retired the support for Kalam Kernel on macOS 10.13 (OS X El High Sierra) and lower. Though the "Legacy" MTP mode will continue working on these outdated machines.
Read more: https://github.com/ganeshrvel/openmtp/tree/release/3.2.10-beta.1#system-requirements-and-support
Download:
- Apple Silicon (mac M1/M2): openmtp-3.2.10-beta.2-mac-arm64.dmg
- Intel Silicon (Older mac): openmtp-3.2.10-beta.2-mac-x64.dmg
Fixed the issue in #314. Closing
Still acting the same way under 3.2.1 - maybe 20 sec+ with no feedback to start, 11-15 sec after each file is copied to wait.
Noting: switching to legacy kernel (not Kalam) gives no wait after files copied. Though copying is slower, the overall throughput is faster because there's no wait to start, no wait between files.
Tested both on phone internal storage and SD card on Kalam. No difference in timing.
I am investigating this issue. I closed this issue by mistake.
Seeing this as well. MacOS Ventura 13.1 (M1 chip), Pixel 7, OpenMTP 3.2.10.32. Kalam kernel, disabled auto-connection.
Screen recording of issue:
I am available to give debug logs or test fixes, if that'd be helpful.
Hello @ganeshrvel
I am also seeing this issue, exactly a described amobe.
Macbook Pro M1 MAX, no other apps running (killed everything via Activity Monitor). Ventura 13.5.2, tried a few reboots of both device and mac.
With Legacy mode transfer is slower but no wait between files.
A fix would be amazing.
Thanks!
Same here.
Macbook Pro M2, Ventura 13.6, v3.2.10.32.
+1 same issue on Mac Mini M1. Version 3.2.10 (3.2.10.32)
in new mode, long wait/sleep between file completion, even when file is small.
in legacy mode, no issue with transfer, but lacking the overall status view.
For anyone else encountering this -- I use syncthing nowadays, and it works flawlessly.
Hello everyone,
I'm planning a lightweight and modern rewrite of the app in the near future. This will be a complete overhaul from the ground up. In the meantime, I'll attempt to find a solution for this issue.