Hello XDA community!
I'm not quite sure if this is the right place to ask this, but I couldn't quite find a forum suited for this type of question. In any case here goes: is there any way to identify someone's email address or Google account from his/her Google Play Music ID?
Here is why I'm asking. Recently, my wife and I stayed in a hotel and at the end of our stay, my wife brought back a USB key which she assumed was mine. The USB key must have belonged to a prior patron as it was not mine. On the key, I saw that there were several family photos which seemed like they would be quite important to the owner. However, I could not find a single shred of identifying information on the key, with the exception of an "Android" folder with a "com.google.android.music" sub-folder containing a file named "._playmusicid" in it. This file contains a string of characters which appear to be a unique identifier for a Google Play Music account.
I would like to be able to identify the owner of the USB key so I can send him his data. From the photos on the card, I can only assume he is now quite far away from me (I am in Canada, he is likely in Asia somewhere), so I would send the information online. I've called the hotel, and they can't tell me who previous renters were (quite strange, given the nature of my request).
If anyone knows how to accomplish this, please let me know. Thank you!
What is this file ? Little Off Topic but my Sprint Sammy Note 4, Stock ROM, v5.1 LoLPoP with No Root, puts this file on any media I attach to it to include Micro SD Cards, USB Thumb Drives and small portable Hard drives.I will rap it up with the path oh yea, if the end file leaves the path it is auto replaced so it stays with you, would be perfect way to spread something. Any way the file is a hidden one so most people wouldn't even notice unless your looking for anything.
This is on any removable media. Google Play Music File that replaces itself if moved, removed, or renamed from initial location. Can be removed once disconnected from phone, does not remove itself.
( REMOVABLE MEDIA NAME HERE ) > Android > data > com.google.android. music > files ( Hidden In Here ) > ._playmusicid ( Hidden File )
Is it saying You Were Here, here is your invisable ink stamp saying you bumped uglies with my phone?
That is all.
Sent from my SM-N910P
Related
Hi all,
Newbie Archos 70 250Gb owner here - back with Archos after a long period in the iPod wilderness
I'm generally pleased with the A70 but there's one thing which is a bit of a showstopper for me at the moment. I specifically bought the A70 with the big disk because I'm a music junkie - I have 150Gb or so of mp3s, and I add 3-4 albums per month.
I've copied all my music to the A70's hard disk (something like 22,000 songs), but the media scanner has only found a small fraction of them. I can sit and watch it run, and it gets to about 3200 files before quitting. This is repeatable - if I rerun "update multimedia library" it never gets beyond this point.
Anyone got any clues as to how I can track down the problem? I'm wondering if I have one dodgy mp3 which is causing it to fail perhaps? Without knowing which one it is, it's going to be tough to fix this - I can't manually remove each one of 22,000 files and keep retrying! Are there some system logs somewhere I can check?
I beginning to wonder if I'm going to have to roll my own media scanner - I'm an experienced Java programmer but very light on Android skills so it might take me a while.. so I'd rather not if I don't have to - I'm not even sure if I get that level of access to the system.
Keith.
According to several folks over at the ArchosFans forums, the media scanner has a problem with tracks that have a "#" symbol in the name. Since I cannot post links yet, go to forum dot archosfans dot com, and search for "media scan hash pound #" and that should take you to the right thread.
That said, a custom media scanner might not be such a bad thing; it seems to be a source of unhappiness for a number of folks.
Hi,
Same problem here, i found that doing a 'rebuild media database from scratch' option in repair&fornatting menu did eventually (after about 1day of scanning) found all my files.
Be sure to keep your archos awake during the scan, use for example the pictureframe app so the device stays awake.
Hope this helps
Sent from my A70H using Tapatalk
Thanks guys - that's two things to try, I'll let you know how I get on.
Status update: clearing out the media library and re-running the scan didn't work - it still fails, and this time leaves me with an empty library.
So, i rolled a very simple scanning app, which I can point at a single directory (i.e. a single artist). It imports some things fine, but guess what - when importing files with a "#" in them the media scanner apparently falls over - silently, unfortunately, nothing gets reported to my little app when it happens. The thread referenced above also mentions issues where the "artist" tag doesn't match the "album artist" tag - I'll keep an eye open for those too.
This is the built-in Android media scanning service that is failing, as far as I can tell - it's not clear to me if Archos modified it or not, but it's pretty shoddy not being able to handle a valid filename.
So, I'm going to keep going with my little app (maybe this thread needs to move to the dev forum?) but right now the best I can make it do is to not scan files with a hash in them, or perhaps rename the files on disk (but that would really screw up my synch mechanism, as I don't want to have to rename a whole bunch of stuff in iTunes which I also use..)
This is all disappointing - I was an early adopter of Archos stuff with a JB6000 and JBR20 (still got it somewhere!) back in the day and they've always been pretty decent at the music side of things - this is not what I would expect from them and makes it difficult for me to know what to do next as this is my primary use of the device...
EDIT: for info: the # problem only occurs with the filename, not the tags - so renaming the file appears to solve the problem while leaving the tags intact - I'll go down that route for a bit, see if I can fix things that way.
Keith.
20,000 song limit(!)
So it turns out that the scanning problem is all about hash symbols in filenames - once I removed all the hash symbols from file names the scan got all the way to the end, but hung on "Finishing scan" indefinitely. I realised I still had playlist files referencing the original filenames with hashes. Once I got rid of those, the scan completed just fine, but presented me with this:
Maximum multimedia library size reached: Only the first 20000 audio files have been indexed​
Well that's a bit of a showstopper isn't it. I'm struggling to understand why someone would ship what is basically an enhanced media player with 250Gb of space, and then restrict the media library so you can't make use of it all. Even my iPod Classic 160Gb can take more songs than that!
I'll take this over into the developers forum to see if there's any way around this limit - I'm assuming it won't be anything simple. Argh!
Keith.
Hello XDA-Developers!
I had an idea this morning.
Current Transfer Tech:
Bluetooth - Requires the user of both devices to enable their bluetooth devices, then they have to go about pairing the devices to allow file tansfer (this is not always the case though). then the, shall we call him "sender" has to select a file and attempt to bluetooth the file to the, shall we say "reciever", who in turn has to accept the data and then the transfer starts.
Wifi - not used very often but files can be transferred through an app or through an ftp server etc from one device to another. this however requires a little, if not more, skill to complete and can be fustrating looking for ip addresses etc.
NFC - this is an emerging technology that is being implemented in more and more devices such as the Galaxy Nexus. This is a very efficient and fast way to transfer data from one NFC enabled device to another NFC enabled device, however like most of the android community, my phone does not have this capability.
My Idea:
This is just an idea and you may say what you like about it but i thought i would write it down here, the first place that came into my mind where i thought that someone could take this idea further.
Now my friend uses a blackberry, and i know that that word is almost taboo on this forum but hear me out. He uses his blackberry for a service called BBM (Blackberry Messenger), i am sure you are all familiar, and to add a friend of his so that he can contact them using the service, he simply uses his blackberrys camera to scan a 2D Barcode on his friends device and all his BBM Pin and other data is transfered through the phones camera so that they can communicate on the service.
I though that this could be used more on android devices. This could be used to transfer small files from one device to another such as contact information, websites (already a reality), even larger files such as word documents and other reletavely small documents. Now i know that these files cannot be displayed on a single 2D barcode but maybe they can be send using not one barode but a series, the barcodes could be in an animation on the device screen, showing one barcode after another all and the "reciever" could simply hold his device's camera over the animation and it could read the series of barcodes and then compile all of the data to create a single document.
Now i realise that this could be a silly idea as the ammount of data that can be transferred through a 2D barcode is not huge, al lot of barcodes would be needed to transfer a larger file than someones contact details.
Let me know what you think, and you are free to do what you want with my idea, i wont hold it against you
hazzahex
Hello
I know it's a little late (only 3 years lol), but I just wanted you to know that I've implemented a system similar to the one you describe
It was my college's final project
hazzahex said:
Hello XDA-Developers!
I had an idea this morning.
Current Transfer Tech:
Bluetooth - Requires the user of both devices to enable their bluetooth devices, then they have to go about pairing the devices to allow file tansfer (this is not always the case though). then the, shall we call him "sender" has to select a file and attempt to bluetooth the file to the, shall we say "reciever", who in turn has to accept the data and then the transfer starts.
Wifi - not used very often but files can be transferred through an app or through an ftp server etc from one device to another. this however requires a little, if not more, skill to complete and can be fustrating looking for ip addresses etc.
NFC - this is an emerging technology that is being implemented in more and more devices such as the Galaxy Nexus. This is a very efficient and fast way to transfer data from one NFC enabled device to another NFC enabled device, however like most of the android community, my phone does not have this capability.
My Idea:
This is just an idea and you may say what you like about it but i thought i would write it down here, the first place that came into my mind where i thought that someone could take this idea further.
Now my friend uses a blackberry, and i know that that word is almost taboo on this forum but hear me out. He uses his blackberry for a service called BBM (Blackberry Messenger), i am sure you are all familiar, and to add a friend of his so that he can contact them using the service, he simply uses his blackberrys camera to scan a 2D Barcode on his friends device and all his BBM Pin and other data is transfered through the phones camera so that they can communicate on the service.
I though that this could be used more on android devices. This could be used to transfer small files from one device to another such as contact information, websites (already a reality), even larger files such as word documents and other reletavely small documents. Now i know that these files cannot be displayed on a single 2D barcode but maybe they can be send using not one barode but a series, the barcodes could be in an animation on the device screen, showing one barcode after another all and the "reciever" could simply hold his device's camera over the animation and it could read the series of barcodes and then compile all of the data to create a single document.
Now i realise that this could be a silly idea as the ammount of data that can be transferred through a 2D barcode is not huge, al lot of barcodes would be needed to transfer a larger file than someones contact details.
Let me know what you think, and you are free to do what you want with my idea, i wont hold it against you
hazzahex
Click to expand...
Click to collapse
Hey !
I've searched the web as well as the forum but i didn't find any solution and it seems i'm not the only one wanting to do that.
Is it possible to see hidden folders of internal sdcard through MTP ?
I really talk about hidden folder like ".android_secure", not the photos that aren't yet scanned by the media scanner service.
In my windows environment i already set the view all hidden files/folders as well as view system files.
If i have to change folders permissions through terminal what are the correct permissions i should put ?
Thanks for the help !!
Am i the only having that problem ?
Do you guys see the hidden folders through mtp connexion ?
If you'd bother reading a bit before asking questions, you might have the answer already.
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
MTP and PTP specifically overcome this issue by making the unit of managed storage a local file rather than an entire (possibly very large) unit of mass storage at the block level. In this way, MTP works like a transactional file system - either the entire file is written/read or nothing.
More or less, it is designed to keep hidden what should be hidden stick to USB storage or FTP/SCP.
PS: can't believe we're using a transfer protocol designed by Microsoft in a Linux-based system mastered by Google. The horror, the pain... no wonder it doesn't work on my Mac!
VAXXi said:
If you'd bother reading a bit before asking questions, you might have the answer already.
http://en.wikipedia.org/wiki/Media_Transfer_Protocol
MTP and PTP specifically overcome this issue by making the unit of managed storage a local file rather than an entire (possibly very large) unit of mass storage at the block level. In this way, MTP works like a transactional file system - either the entire file is written/read or nothing.
More or less, it is designed to keep hidden what should be hidden stick to USB storage or FTP/SCP.
PS: can't believe we're using a transfer protocol designed by Microsoft in a Linux-based system mastered by Google. The horror, the pain... no wonder it doesn't work on my Mac!
Click to expand...
Click to collapse
Thx for the link ! I knew what mtp is but its always good to refresh things up
I read the whole article and unfortunately it doesn't answer my question.
I understood that its the same for all of us meaning that we are not able to see hidden folders.
But the main question is if there is a way to bypass this behavior ? Where is this defined exactly ?
It seems according to the article that its not on the file permission layer ? Should it be at partition level ? How can mtp know what to share with the host ?
It's not a "behaviour" per se, but more/less a database. Remember that media scanner program which wakes up every time you change something on your SD card, be it internal or external ? it simply keeps a "database" of files which are presented to the MTP client (your computer) and hides away the phone's internal folders which are not supposed to be seen by the end-user.
Theoretically, this is done in order to have the iPhone-like behaviour: seeing the entire device memory as one big unified storage which you can fill as you want (no more of those partition size limitations which brought us the app2sd hacks). In my opinion, it's more or less just a small step done in order to "secure" phones for DRM protected content.
Studios and media companies require devices to have such measures of protection in order to allow you to sell media content (like movies, books, etc) and since Google wants to push its business further with the Play Store, it needs to cave in to the studios' demands. In the future, it will probably even become illegal (DMCA-style) for me to give you the information below
Back to the technical part of our show now.
At the first boot in the life of the device, Media Scanner will look under /system/media and index everything there. After that, it will scan everything under /mnt/sdcard (hence your external SD card too, if you have one, as it's mounted under /mnt/sdcard/external_sd). On some devices, you have an "internal.db" file and one "external-123xyz.db" file; that's a unique ID of the SD card which was scanned. The idea here is you might have 2-3 SD cards which you swap often, and it's not nice to do a full rescan each time you change the SD card. These databases are in /dbdata/databases/com.android.providers.media (on my phone, there is only one "external.db" for example).
So what you're looking for is a way to populate this database with all the files found by the Media Scanner. But Media Scanner doesn't want you to see the hidden folders you mentioned above. So, you get an application which doesn't ignore them, like Rescan SD Card! or SDrescan.
Happy now ?
Thank you very much i really enjoyed reading the explanation as it answers completely my questions and it makes sense !
Ill give a try to the apps but i'm also curious to investigate on those files
Cheers
PS. Is this a disguised way to support non open source protocols ?
Well, you could poke around inside the database with sqlite if you want. But don't really see what's so interesting about them.
It is just another protocol which is supported, which happens to be designed by Microsoft (and probably licensed/paid by Google to be used in Android). I understand the technical explanation behind this decision, but I'm also wary that someday UMS will be disabled by default and enabling it will disable content purchasing for that device (just like having a rooted phone now disables some "sensitive" apps, like banking and online TV).
As a system admin its interesting to know whats happening on my system
As a hobby its interesting for my personal knowledge
And from a development point of view it gives me some ideas for maybe future apps
You say that its just another protocol which is supported but to my understanding there are not so many of them ! So i would say that Google was kind of forced to use the MTP method, first from a hardware point of view and second to be compliant with the rest of the world.
Is there any other protocol that could suite their needs ? Since USB mass storage is not usable on some devices and MTP is well spead.
.HiddenAndroid folders in Win - Here Yesterday, Gone Tomorrow
<Win 7 and GN2>
What's curious and a bit frustrating to me is that, yesterday, when I mounted my device ALL of the hidden (.folders and .files) were visible and searchable. Today, when I went to explore some more, all are gone. I understand that I can use a 3rd party app, just can't figure out why it was visible yesterday and not today.
Hmmph
Did you ever resolve this issue? I really hate MTP for several reasons but this is one of the reasons why! I need to back up all my directories on the SDCard because some apps store them as hidden files in hidden directories. Furthermore, I came across the Play Store bug that requires me to delete a "temp.asec" file in the ".android_secure" directory, but of course it is not visible.
In a post further up it was suggested to use a "Rescan" app to force the DB to include hidden files/directories, but I have tried no less than 4 of these apps, and all they do is trigger the built-in android media scan, which is the problem in the first place!
So has anyone ever been able to access hidden files and directories using MTP?
EDIT: I have an HTC phone that actually shows hidden files and directories, so they have obviously implemented their own media scan. The problem I am currently having is on a Samsung phone (Epic 4G touch)
It may depend on the implementation. For example, using stock rom for the phone doesn't show some files and folders, for example folders starting with dot. But if you use Neatrom Lite it will show all files and folders.
Flash forward about 6 years and Samsung still does not show hidden folders/files when viewing the phone contents in Windows File Explorer, but HTC does.
The reason this is still a problem for me, is that I want to backup the contents of a particular directory (WhatsApp) which contains some hidden folders, so I can restore it anytime on a new phone or the same phone.
I recently switched from HTC to Samsung and alas, it seems the problem with this implementation still exists. Anyone found a workaround to this to allow File Explorer to see the hidden folders?
Update: It appears that hidden .nomedia files (and probably others) appear under regular folders, so the problem is limited to hidden folders themselves
When I download a DRM free mp3 like from openbsdorg/lyricshtml, using a browser, it arrives in the Download folder. I can then see it with the included ap "Downloads". If I click on it, it plays just great.
When I sftp the same file into the Download folder with Turbo Client it shows up fine in the in the "local" view provided by that ap. I can also see other files that I previously downloaded normally (using a browser) sitting beside it.
However, when I exit the Turbo Client, and try to view the file name with the built in Downloads ap, the file name is invisible, and obviously I can't play it either.
What is the difference between the files in the two cases? Is there an additional info file parallel the mp3 data file when I use the standard download process? If I go back into Turbo Client, I can still see the file that was sftp'd into the folder. It is still there. That's why I suspect additional information needs to be stored somewhere.
Can I avoid learning a whole new operating system for what is supposed to be a consumer friendly device?
How can I create the additional information that is needed?
AustinHook said:
When I download a DRM free mp3 like from openbsdorg/lyricshtml, using a browser, it arrives in the Download folder. I can then see it with the included ap "Downloads". If I click on it, it plays just great.
When I sftp the same file into the Download folder with Turbo Client it shows up fine in the in the "local" view provided by that ap. I can also see other files that I previously downloaded normally (using a browser) sitting beside it.
However, when I exit the Turbo Client, and try to view the file name with the built in Downloads ap, the file name is invisible, and obviously I can't play it either.
What is the difference between the files in the two cases? Is there an additional info file parallel the mp3 data file when I use the standard download process? If I go back into Turbo Client, I can still see the file that was sftp'd into the folder. It is still there. That's why I suspect additional information needs to be stored somewhere.
Can I avoid learning a whole new operating system for what is supposed to be a consumer friendly device?
How can I create the additional information that is needed?
Click to expand...
Click to collapse
Have you tried seeking help from the developer of Turbo Client? He seems very open to support requests according to his thread on xda (http://forum.xda-developers.com/showthread.php?t=2023646). I feel like this issue you are having is more closely related to the app you are using and not so much the device, so this forum probably is not the ideal place to pose your question.
Download vs SFTP file visibility question
NasaGeek said:
Have you tried seeking help from the developer of Turbo Client? He seems very open to support requests according to his thread on xda (http://forum.xda-developers.com/showthread.php?t=2023646). I feel like this issue you are having is more closely related to the app you are using and not so much the device, so this forum probably is not the ideal place to pose your question.
Click to expand...
Click to collapse
Thanks. I have now posted on his forum as well, however, I have the feeling it is a generic issue, relating to the move to more Apple like total control of use of the device. My HTC ONE X+ is Android 4.1.1 (I should have mentioned earlier). I only resorted to sftp because I couldn't mount it as an SD drive. I am coming from an HTC Desire running Android 2.2 where I could just mount the device like a memory stick. That was nice. Now under Jelly Bean it seems there is an intent to take away user control. This is rotten. I'm not a cell phone guru. I don't want to have to learn about "rooting" the device, reflashing the ROM or whatever, I just want to use what should be a consumer friendly device, but I suspect an attempt to redefine the meaning of consumer friendly, to make us jump all kinds of hoops to get straight forward access to the data it deals with.
I'm sorry you've been having such trouble, but your skepticism regarding MTP (this has been Android's internal storage standard since ICS) is quite unfounded. An Android engineer talks about it a little more in this reddit post, but the general idea is MTP was done to make things easier, not harder, and you should most certainly still be able to access your device's storage by plugging it into your computer. You should be able to do this "out-of-the-box" so to speak, without rooting or unlocking the device. You might, however, need to install the necessary drivers for your phone. Android is all about giving the user a healthy amount of control over their device and what files come and go from it (to a certain degree), though I'm not sure I can say the same thing for HTC Sense...
edit: upon reading your post in the other thread, I think I understand your issue. The developer's response was unfortunately not terribly informative for someone who is not well-versed with Android. In order to access your mp3 files you will need to download a file browser app from the Play Store (like this one ) and navigate to your sdcard/Downloads folder.
I probably should have read your post a little more clearly, particularly where you mentioned you were trying to view the files with the Downloads app
Hello all, I have received a TON of false positives in my search for whether this is even possible.
In windows, a shortcut to a file or folder can be stored in any folder.
So far in Android, a shortcut can only be placed on the home screen, and AFAIK does not have a corresponding file that can be found in the root browser.
I am trying to trick Handshaker into giving me access to my EXTERNAL SD, and the only way I can think of is to create a shortcut somewhere on the internal SD that zips on over to the card where all my media (100Gb+) is stored.
I'm on a OPX, so internal storage BARELY COVERS apps. No switcheroo action is reasonably doable.
As an aside, is this whole Mac incompatibility thing a vestigial grudge? It must take a lot of effort to KEEP usb from working as it should. Are there other apps besides the "works when it feels like it" Android File Transfer or "installs weird **** on your phone" HandShaker that allow you to move around YOUR OWN FILES without using the cloud? The amount of web silence and lack of development is stunning to me. Maybe I need to refine my search terms?? Unlikely. I've tried many tens of iterations.
The search for answers here results in a mountain of false-positives as well.
Thanks for taking the time to at least read this.
Cheers.