My FP4 arrived 2 days ago. Everything works smoothly, but the USB connection to my Win 10 PC operates extremely slowly. I can see the Phone in Win Explorer, can open folders withput problems. Right after I plug it in, I can also move files, but not for very long.
After that initial period, i can’t even move very small (e.g. 30 kb) files or view pictures.
Thing I have tried but didnt work:
use another USB cable
use different USB port (including USB-C)
uninstalling and reinstalling the FP from the Windows device manager
it gets unbearably slow, but the phone never disconnects. The Win explorer does seem to be affected by it too, I had it nearly crash a couple of times
i tried to use the SD card as internal storage, so the PC didnt distinguish between the memory of the phone and the SD card (no separate folders). But i just physically remoced the card and there was no change
the SD card worked just fine in my last phone too, up until a few das ago. so I think we can rule it out as the source of the problem
Ok, so at least the SD card doesn’t get unmounted suddenly. I can’t help you with the explorer behaviour, somebody who’s running Windows will have to answer that.
I would strongly advise against formatting the SD card as internal storage, the risks far outweigh the benefits. Have a look at the SD card guide for FP3/FP4.
I wouldn’t rule it out as a potential problem, the FP4 is a bit picky regarding microSD cards, especially if they are made by SanDisk. There’s a long thread about it here and a ✏ List of compatible micro SD / SDXC cards for FP4
Maybe try formatting the card as external storage and see if the transfer problems persist when writing directly to it. If you have other microSDs lying around, it would be also very interesting to know if they exhibit the same problem
I’ve joined this forum, because I also have this issue. I have a Fairphone 4 (8/256GB) on the latest Software Version (but the previous version had the issue, too). On the other side of the connections sits a Lenovo T470s Thinkpad with Kubuntu Linux.
I tried to copy music (MP3 and FLAC files) to the phone. It is slow from the beginning (5-20MiB/s) - so less than USB2.0 speed. After copying 1-2GiB of files at this rate, the transfer will suddenly crash. (The file manager says that whichever file it was transferring last cannot be copied.) At that point no reading/writing to the phone is possible at all, until the phone is physically disconnected and connected again, including activating file transfer mode on the phone screen.
I do not use an SD-card, so that is definitely not the issue.
I used different USB cables (USB-C to USB-C(10GBit) and USB-C to USB-A-3.0) and different USB-ports so this is also very unlikely to be the issue.
The issue appears, even when the phone and PC are sitting on a desk and are not moved or touched at all.
Doing file transfers to another Android phone (a Samsung XCover 4) works fine (limited to the USB2.0 speed the XCovers USB-connector provides), so I’d rule out my laptop/laptop-SW to be the cause.
If there is further Information I could provide (e.g. coyping some logfiles or running some systemd status queries) to help further debug this, I’d gladly help.
As an additional Info (I’m using this thread to publicly collect the information for the support team and to document my experience with them), I tried the following USB Cables:
PremiumCord USB-C auf USB 3.0 Verbindungskabel 1m, Datenkabel SuperSpeed bis zu 10Gbit/S, Schnellladung bis zu 3A, USB 3.1 Generation 2 Typ C Stecker, Farbe Schwarz, Länge 1m (Amazon Link)
USB-C auf USB-C Kabel 60W PD JSAUX Ladekabel Typ C auf Typ C Schnellladekabel Kompatibel mit Samsung Galaxy S22 S21/S20/A53/A52S/A50 iPad Pro 2021 12.9 11" Air 5 4 Mac Google Pixel Rot (Amazon Link)
The USB-C cable that came with my Lenovo ThinkPad USB-C Dock Gen 2 (Lenovo Link)
The Lenovo USB-C cable is in regular use with the docking Station, driving two FullHD screens, Gigabit Ethernet + all peripherals flawlessly. So the USB-port and -cable are definitely not faulty.
Other users had suggested, that copying larger files is less troublesome, so I tried copying a 700MB movie file. That worked, and the average speed was at around 90MiB/s (so definitely more than USB2.0 speed. This is probably an indicator that the issue lies with the soft- and not the hardware.
The issue still stands: It should be possible to copy a couple gigabytes of music to a 600€ phone with 256GB of storage.
So I have another follow up, after doing some further investigations:
The Fairphone will not accept any files with a ‘:’ symbol in the filename. Trying to copy these, will crash the copy process. (This will not affect Windows users, as Windows doesn’t allow such files.)
Even with proper filenames, copying a large number (~1000 files) of small files (maybe generally a large number of files - but I don’t have the time to test copying many large files) doesn’t work reliably.
→ On Windows the copy process will crash at random.
→ On Linux, the copy process stops at random points, stating that it cannot copy a certain file. If you skip copying that file, the process resumes, until the next random file cannot be copied. I made a list of these files, but didn’t notice any pattern. I then tried to copy these files again. It worked.
I then tried copying the same set of files with Linux, two more times: Random interruptions kept happening, but at different files. → I conclude that this is not an issue with the files. I tried it again with Windows, and it crashed again at a random point. My guess is, that it’s the same issue, but Linux handles it a bit more gracefully than Windows.
I noticed, that the Fairphone is using a Google Vendor, and a Nexus device ID:
Bus 002 Device 005: ID 18d1:4ee1 Google Inc. Nexus Device (MTP)
Just for reference: This isn’t normal, other Android devices use proper Vendor/Device IDs. E.g. my old Samsung identifies itself as:
Bus 001 Device 008: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy series, misc. (MTP mode)
So my guess is, the Fairphone dev team hastily copy pasted some Google example code. For testing, they copied a handful of files, and when that worked once, they called it good enough.
(Please note: I do not recommend buying Samsung devices. They cripple their hardware by forcing loads of unwanted, data extracting software on you. But their USB/MTP implementation just works as expected.)
I completely agree with you, there is something seriously wrong with the FP4s MTP stack (there are some other, smaller problems as well).
A folder with ~17,000 pictures / 23.5 GB reaches 1% / 25 files copied after a few minutes, then the process just hangs there for a while before throwing an error and continuing. That’s with the official USB-C 3.2 Long Life Cable plugged in the USB 3 port of a Linux PC.
Meanwhile I can adb push that same folder with the same cable in just under 10 minutes, no issue whatsoever…
Same thing with a bunch of .flac files, videos, anything really.
I have long given up on using the MTP connection to transfer files to the FP4, just too unreliable.
Those only throw an error for me (on Linux / KDE Plasma), but don’t crash the transfer.
I’ve got ID 18d1:4ee2 Google Inc. Nexus/Pixel Device (MTP + debug), so at least they apparently used different IDs for the different models (or maybe that’s just with adb enabled)
Nope, its just the settings. When I scan with USB-debugging enabled I get 18d1:4ee7, and when I have USB-debugging + MTP-files enabled, I too get 18d1:4ee2.
Now thinking about this: This means, that the Fairphone is not officially USB certified. It cannot be because they would have to use their own vendor ID. (And sub-licensing of somebody elses ID, if I’m not mistaken, would only be allowed if they planned on selling less than 10k devices.)
I have no idea how this works, but they somehow released the FP1 under a HTC vendor ID (0bb4:0c03), the FP2 under their own (2ae5) and Qualcomm’s (05c6:90dc).
Didn’t find any specific mention for the FP3 or FP4 in any of the USB ID databases, the Google one does contain a few random non Google devices (18d1)
You might have to ask support if they can explain that. But I wouldn’t count on an answer anytime soon, that probably has to be relayed to the dev team and that takes forever…
