Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "mtp"
Google, why the fuck did you make the Android default USB connection type be "charging," and NOT "MTP"?! And leave no way to EVER set default to MTP!!!
EVERY SINGLE FUCKING TIME I plug my phone into my pc to transfer files, I have to open my notifications shade, scroll to the bottom to the fixed notifications, and change the mode to MTP, at which point the phone has to re-establish its connection to the pc!
This has been an issue from Android M and onwards. Nonetheless, Google still left in the settings app under developer options on rooted devices, the setting to choose which default USB connection mode you want to use. Even though it doesn't stay on what you choose!! It's like they left that there to purposely toy with us and get a good fucking laugh from our needless suffering.
Google, I love so much of what you do and your approaches, but honestly, some of the things you do, like this and for disabling Chrome extensions on Chrome internal pages, makes me want to strangle you and then throw you in a river of molten lava.34
Google: buys Android
Makes tons of $ from Ads
Meanwhile 7 year old bugs
Are still not fixed
A bug reported in 2012: recently created files are not visible when using MTP protocol.
Guess what? I still have this bug on my 2017 phone, like many other people.
Probably has something to do with file cache.
Because obviously 7 years is not enough to fix a stupid bug. Especially when Google is busy implementing all the other features nobody asked for except marketing department4
MTP is utter garbage and belongs to the technological hall of shame.
MTP (media transfer protocol, or, more accurately, MOST TERRIBLE PROTOCOL) sometimes spontaneously stops responding, causing Windows Explorer to show its green placebo progress bar inside the file path bar which never reaches the end, and sometimes to whiningly show "(not responding)" with that white layer of mist fading in. Sometimes lists files' dates as 1970-01-01 (which is the Unix epoch), sometimes shows former names of folders prior to being renamed, even after refreshing. I refer to them as "ghost folders". As well known, large directories load extremely slowly in MTP. A directory listing with one thousand files could take well over a minute to load. On mass storage and FTP? Three seconds at most. Sometimes, new files are not even listed until rebooting the smartphone!
Arguably, MTP "has" no bugs. It IS a bug. There is so much more wrong with it that it does not even fit into one post. Therefore it has to be expanded into the comments.
When moving files within an MTP device, MTP does not directly move the selected files, but creates a copy and then deletes the source file, causing both needless wear on the mobile device' flash memory and the loss of files' original date and time attribute. Sometimes, the simple act of renaming a file causes Windows Explorer to stop responding until unplugging the MTP device. It actually once unfreezed after more than half an hour where I did something else in the meantime, but come on, who likes to wait that long? Thankfully, this has not happened to me on Linux file managers such as Nemo yet.
When moving files out using MTP, Windows Explorer does not move and delete each selected file individually, but only deletes the whole selection after finishing the transfer. This means that if the process crashes, no space has been freed on the MTP device (usually a smartphone), and one will have to carefully sort out a mess of duplicates. Linux file managers thankfully delete the source files individually.
Also, for each file transferred from an MTP device onto a mass storage device, Windows has the strange behaviour of briefly creating a file on the target device with the size of the entire selection. It does not actually write that amount of data for each file, since it couldn't do so in this short time, but the current file is listed with that size in Windows Explorer. You can test this by refreshing the target directory shortly after starting a file transfer of multiple selected files originating from an MTP device. For example, when copying or moving out 01.MP4 to 10.MP4, while 01.MP4 is being written, it is listed with the file size of all 01.MP4 to 10.MP4 combined, on the target device, and the file actually exists with that size on the file system for a brief moment. The same happens with each file of the selection. This means that the target device needs almost twice the free space as the selection of files on the source MTP device to be able to accept the incoming files, since the last file, 10.MP4 in this example, temporarily has the total size of 01.MP4 to 10.MP4. This strange behaviour has been on Windows since at least Windows 7, presumably since Microsoft implemented MTP, and has still not been changed. Perhaps the goal is to reserve space on the target device? However, it reserves far too much space.
When transfering from MTP to a UDF file system, sometimes it fails to transfer ZIP files, and only copies the first few bytes. 208 or 74 bytes in my testing.
When transfering several thousand files, Windows Explorer also sometimes decides to quit and restart in midst of the transfer. Also, I sometimes move files out by loading a part of the directory listing in Windows Explorer and then hitting "Esc" because it would take too long to load the entire directory listing. It actually once assigned the wrong file names, which I noticed since file naming conflicts would occur where the source and target files with the same names would have different sizes and time stamps. Both files were intact, but the target file had the name of a different file. You'd think they would figure something like this out after two decades, but no. On Linux, the MTP directory listing is only shown after it is loaded in entirety. However, if the directory has too many files, it fails with an "libmtp: couldn't get object handles" error without listing anything.
Sometimes, a folder appears empty until refreshing one more time. Sometimes, copying a folder out causes a blank folder to be copied to the target. This is why on MTP, only a selection of files and never folders should be moved out, due to the risk of the folder being deleted without everything having been transferred completely.
MTP is complete garbage. I want mass storage back.
The media transfer protocol (MTP) occasionally discovers new creative ways of failure. Frequently, directory listings take minutes to load or fail to load at all, and it freezes up infinitely (until disconnected) when renaming an item, and I can not even do two things simultaneously.
While files are being moved, I can not browse pictures or watch videos from the smartphone.
Sometimes, files are listed with the date 1970-01-01 (Unix epoch) instead of their correct date. Sometimes, files do not appear at all, which makes it unsafe to move directories from the device.
MTP lacks random access. If I want to play a two-gigabyte 4K 2160p video and seek in the video, guess what: I need to copy it to my computer's local mass storage first because MTP lacks random access.
When transferring high numbers of files, MTP has to slooooowly enumerate (or "prepare" or "calculate the time of") them all, which might even take longer than mass storage would need for the entire process. This means MTP might start copying or moving the actual files when mass storage is already finished.
Today, the "preparing to move" process was especially slow: five minutes for around 150 files! How am I supposed to find out what caused this random malfunction?
MTP sometimes drives me insane. I want mass storage back, at least for the MicroSD memory card, which uses a widely supported file system.
Imagine a 2010 $100 Android phone is better at file transfer than a 2022 $1000 Android phone (or iPhone, for that matter).3
When file managers copy and delete files within the same partition instead of moving or renaming them…
When Google's Storage Access Framework was introduced, it did not feature a move command, so file managers just resorted to copying and deleting files within the same storage. Not only does this cause needless wear and is much slower, but it also destroys the date/time attribute (it gets changed to current).
When moving files through MTP (miserable transfer protocol, used for connecting smartphones to PC), they are also copy-deleted. This makes moving a 20-Gigabyte DCIM folder impractical. Also, if one cancels the operation, it might end up whoopsie-daisy deleting some files from the source before they have been transferred.
MTP is so bogus that it is incapable of a simple operation that would JustWork™ on mass storage devices. Not to mention, MTP lacks parallelism and its directory listing loading it S-L-O-W. Upwards of a minute for just 1000 files. Sometimes, it fails loading at all.
Also, trying to rename a file through MTP using the terminal through GVFS, even if just within the same folder, it copy-deletes it. If I want to rename a 1 GB 2160p 4K video in a highly populated DCIM folder, I can not do so through the terminal. At least, the 4K video has a time stamp in its internal metadata, but it still renames slowly and adds needless wear to the smartphone's flash memory.16
i want to find the person who proposed to force mtp in android for file transfers, and bash them in the head with a plush android toy till they're knocked unconscious.
all i want is to make a file transfer between my phone and my computer, and rather than plugging my phone's usb, i find it easier to set up an ftp server over local network. and when that doesn't work, i might as well hexdump the file, and copy it char-by-char manually, than use mtp.6
SMB/CIFS support on Linux distros is a nightmare! Switching from wired to wireless will cause ALL mounts to freeze, and they all become impossible to dismount normally. You can't even ls the root folder anymore if there are frozen mount folders inside. It's f#&%ing retarded to have to reboot your PC twice a day because you lost WiFi signal for one second, and the underlying processes don't understand SIGTERM. And I could go on about MTP! Standard file transfer protocol for Android but boy it is hellish. Trying to copy a structure with subfolders will take forever because every ls call to the phone is like an API call to some free webhosting company in Australia, takes forever, if it even succeeds. I won't even get started on WebDAV and SSHFS (the latter is even worse than CIFS). Those make me want to do unpleasant things to my computer. So frustrating! I can't be the only one who has experienced this, right?1
android devs/linux users, a quick help is needed.
My Ubuntu is not detecting my phone for debugging , but rather its just charging it.
(My phone should show a notification of being connected as a MTP device, but nops, it is not detecting laptop at all, it connects as if I have connected it to a charger)
This problem just started today, idk how or why...10
Is it just me or is it annoyingly finnicky to get an android device connected to Linux? I want to transfer files but its not getting mounted (unlike all my other devices like USB sticks/HDDs). And yes mtp is turned on on my device. How do you guys do that? Any convenient way? In this case I would actually appreciate a non CLI method7