[WIP] Resilience against API limits and 10k playlist limits, among others

[akatrevorjay]

I need to clean this up a bit, but it might take a while before I have time.
Either way, I wanted to get this out there in the interim.

I plan on removing the pickle stuff, that was left in for debugging by accident (it takes a very, very long time to iterate on my large amount of playlists and songs without it).

I ran into a bunch of APIs I needed to use that were not in this library, and these aren't exactly dead simple REST endpoints, so I currently have this stupidly hacked to use gmusicapi in place.

The more I thought about it, the more I wondered what the benefits are in even rewriting these when there's such a good API client written (gmusicapi) anyway?

I began converting gmusicapi to utilize aiohttp, but that's where I've left off currently.

[rckclmbr]

Looks good, there's a lot of code there I'll take a look when I have some time as well :)

I began converting gmusicapi to utilize aiohttp, but that's where I've left off currently.

I originally used gmusicapi actually, but ended up ditching it because I ran into a couple bugs, didn't need all the functionality from it, and it has a bunch of compiled dependencies that were causing me frustration in Windows builds (if I remember correctly, it was around some crypto stuff). I don't think I want to go back to it.

[akatrevorjay]

Ahh, I see. Odd that it has compiled dependencies, definitely.

[akatrevorjay]

As for the mapping into new 10k playlists, I thought about it a bit more, and I think a more sync-based approach would be much better, ie to take the current left (spotify) and just apply it as is to right (gmusic).

On that note though, I started thinking of how to do a proper two way sync instead of trampling over each other ala above.

Currently I try to maintain some kind of order from the left, but it's not guaranteed as the right may already exist. Need to think on that some more to say the least.