Android File Transfer
Roseanne Devon
Quitting Preview finally allowed me to connect to the device, thanks! It was extremely flaky, droppping the connection several times, but in the end I was able to transfer the files I needed. Not sure why Preview is involved with the problem, and not certain that it will work next time, but this helped.
Still no love for me. On my Macbook Pro (13.2.1) neither Drive nor Preview is running. Trying to connect a Pixel 6 (Android v13). Oddly, when I connect the phone to my 2012 Mac Mini with High Sierra, AFT comes right up. AFT version is the same on both Macs. I will note that I also tried a couple other transfer apps on the laptop, and none of them works, either. I get the same connection problems (app sees the phone but won't connect to it). Appears to be something with Ventura.
That was 100% exactly the issue. I tried creating a new profile and that worked. Then was thinking it something to do with local setup of the account. Simply quitting Google drive solved the issue. Just to confirm it was already in debug mode and file transfer setting and connecting to different mac worked instantly.
I use a usb cable to connect my M2 MacBook Air (Ventura) to my Android phone ... Downloaded the Android file transfer software to my computer ... Started the software and everything works ok ... Perhaps you need the latest version of the Android file transfer software.
It's taken a while but think by accident I found out what is happening. In settings is a place you are supposed to be able to designate what accessories have access to apple productsmissingshould be like this when they are plugged into eg-a USB connetion. For some reason this option is not available (missing) as a setting in Ventura. Am sure that this hopefully will get fixed on the new OS. But in the meantime there is no way to actually let your oculus get to Android file transfer. It actually is an Apple problem and I have reported it to them. Who knows if they will correct this.
Ok, who knows who is the author of Android File transfer? Someone needs to contact them to have them update their program. I've always used this in the past and it's worked fine. Maybe Meta needs to field this and get it done.
Hey there @gnoetik! We're stoked to hear that you were able to find a solution in regards to the Android file transfer issue. Hopefully this can help other users experiencing this same issue as well!
Edited to add: it finally worked! I kept trying all the things I'd tried before (though apparently I hadn't given Signal location permission on the new phone) a few more times and reset both phones again and the time after that the transfer code FINALLY came up!
I first tried the phone to phone transfer and both just spin for about 10 minutes until the old one brings up an error sfreen. I tried all the suggestions on there and still nothing. I've tried phone to phone transfer 2 or 3 times to this point.
Is Android to Android transferring just broken right now? Should I give up and be sad but move on? I've googled a bunch and there's no actual answer for when both options don't work. I was also able to submit a bug report only one of the times that screen popped up - all other times I tried it crashed.
There are no log files on either phone, but the proper folders are created in .../android/data/com.mb.android/files/sync. In one case, the recording is found in the folder. In the other case, the folder is empty.
Yes, there is definitely an issue with the Android app saving to external SD card. I have a Samsung S9 with 256gb SD card. When I set the download/sync to "external", nothing gets saved to the SD card even though the folders gets created. On the server it just says "ready to transfer". But when I switch it to "internal", everything syncs and downloads onto the phone.
Have you checked your Emby server dashboard to see if it's still converting the media? I've found that it won't update the app to tell it that the media is still converting, so the app saying "Waiting to transfer" is not very useful information.
I am using Ubuntu 21.10. I tried to transfer files from my Android phone (Redmi Note 4) to my laptop via USB cable by enabling the file transfer option on the phone. Ubuntu detects my phone, but when I tried to open files in my phone on the laptop, it shows:
I just had almost exactly this same problem with Ubuntu 20.04 and an Umidigi Android phone. I've never had trouble connecting my phone to the same computer under Windows 10, so I surmised that there was no problem on the phone's end. I was also able to switch the phone's connection to PTP and have it work in Ubuntu, but of course the phone would only transfer photos in that mode.
After editing /etc/udev/../rules/files setting my phone IDs (thru lsusb) I managed to workaround this only by selecting at the phone (when asked) to use it to "Transfer Images" not "USB transfer files", and that made the trick, any filetype I'm allowed to write/move/copy/paste from Nautilus...
On an Android Pixel 2 and Ubuntu 18.04.1, to allow file transfer via a USB cable from the phone to the computer, on the phone, go to Settings > 'Connected devices' > 'USB' > select 'File Transfer'. This worked immediately for me: the phone showed up in Device Notifier and allowed me to download photos with Gwenview. And it also allowed me to delete the photos on the phone from the computer after I had downloaded them.
Apologies if this has already been asked: I looked at the KP Help Center before posting but probably missed it (if it was listed). I want to 'transfer' or copy the KP database from my Android tablet & Keepass2Android (ver. 1.01-g) to KeePass database ver. 2.35 on my Win 10 PC. The database on my PC has KeePassLibC (1.x File Support) ver 1.32 (0x019B).
In response to Paul's above post about a problem with copying KP database files to a USB drive: I have no idea about why this should be so, but that was exactly the case for me. KeePass 2.44 on a home local network laptop would not open a .kdbx file transferred via USB drive from a desktop. Had no problem at all when database file was transferred via local network!
It takes more than 4.5 hours to complete the transfer, I have cancelled the operation, I can't wait 4.5 hours just for the move operation to complete, and even in the unlikely case I could, by the time the operation completes I wouldn't be able to access the computer, it is some "technical difficulty" I would not go into here.
The practically achievable USB Mass Storage data transfer speed in this mode is around 42 "MB"/s. Your phone is an MTP device, not a mass storage device, but the calculations would be similar. Waiting is still probably your best option (802.11ac Wi-Fi could in theory exceed that speed, but in practice not by much).
I found that using a FTP server on my phone and transfer the files via FTP worked much faster than USB (because it's USB 2.0 with horrible MTP). And all new files also showed up instantly which they often enough don't via USB. Not sure if this is all related to my P30 Pro, but my Axon 7 had similar issues.
There is overhead with each individual file that you write to a disk involving looking for space on the disk, updating the file tables, etc. (I'm sure someone will chime in with more details.) The more small files you transfer the more time it will take because the more general file system overhead you will incur.
What I do when faced with this situation is to transfer the files overnight over WiFi. There are some apps that specialise in this, but most are proprietary and kinda complicated. So I just have an app that speaks SMB (file protocol used for network folders) and move files to a network location on my home WiFi - you can make it as simple as share a folder on the network from your Windows PC or have a dedicated NAS set up. The app I am currently using is called Cx File Explorer and I can just select the files/folders I want to move, select "move", then navigate to the network location (needs to be added first in the app) and select "paste". It does things in the background and you can just have the phone next to your bed overnight instead of having to babysit it.
3a7c801d34