Feature request: tag successfully uploaded mp3s

[a575606]

Hi, I just installed a docker container which is basically a wrapper for your api. (jaymoulin/google-music-manager) The issue I had was a lot of duplicate tracks getting uploaded which google music seemed to miss. From what I gather, this seems a common problem.

I was just wondering if it would be an idea to add an option to tag the mp3 files on successful upload or keep a list, so they're skipped on future upload calls? I'd love to get this working, but as it stands, it's unusable for me. Let me know your thoughts. Thanks!

[simon-weber]

I'd prefer to leave those kinds of decisions to client code and keep gmusicapi focused on Google Music interactions. Musicmanager.upload returns the status of each requested file, so it should provide all the information needed to implement this.

[a575606]

understand... and mostly agree with you. Just the dev of the google music manager package is not real responsive.

My only consideration is this... Should the upload method allow the uploading of tracks already in the music library? I can't see the benefit in being able to do that. At least it seems it should be an override action rather than the default.

I just notice that using the windows music manage app, it builds a database of the local library and seems to compare before uploading each file. I didn't get a single duplicate uploaded in 10k+ tracks. Using the api, 2 out of 3 tracks were duplicates.

Anyway, just wanted to make my case. Thanks for your time.

[simon-weber]

Should the upload method allow the uploading of tracks already in the music library?

From what I remember duplicates are mostly detected with client-provided hashes of files. We make a best effort to match the Music Manager but don't guarantee it; mismatches will result in the server not detecting a duplicate if uploaded once with each client.

[thebigmunch]

FYI: mutagen doesn't actually provide the necessary information to generate a client ID for any format besides FLAC that will match Google. And, due to our not knowing exactly how these were generated previously, gmusicapi's generation won't match for FLAC files, either. I've looked at this quite a bit. The client ID for FLAC is generated from the MD5 hash stored in its header, which is actually the hash of the unencoded audio data, rather than hashing the encoded audio data (as is done now). This is one of the reasons I created my own audio metadata library. But I still need to add at least a few more major formats to support all that Google Music supports.

The kicker is the fact that generating a different client ID is part of how gmusicapi is able to spoof Google's scan and match feature. It's impossible to do this 100% even with different client IDs and sample spoofing as there is metadata-only matching as well.