Nice.

How much should I believe this site will stay around? I'm currently using an ugly, manually-updated Google Spreadsheet as a backup for my largest playlist project, Bachify [1] -- it's got 1075 tracks, one for each Bach BWV number with an available recording.

I dread what I'd have to do if I ever accidentally lost the playlist. Is it reasonable to consider TuneMachine as the backup instead?

[1] http://rspeer.github.io/blog/2014/09/25/bachify/

That's a good question.

Right now, the biggest worry is whether we'll run out of space. We're running on a free tier MongoLab database. If we get spammed or it really takes off, that's going to disappear. Luckily it's super straightforward to spin one up on Heroku or elsewhere, and if it's important to you you could pay for a larger database.

You could set up your own instance on a free heroku dyno, assuming it doesn't do anything that requires it to run 24/7.

This is ironic because Spotify's playlist backend ("playlist4") is actually implemented as a distributed version control system with automatic conflict resolution. This is what lets you edit the same playlist on multiple devices, some of which might be offline, and then have a consistent view once everything is synced. It's also what lets our CS staff revert and restore user playlists if there are any accidental or catastrophic changes.

We've just never found the demand or a reasonable UI for exposing the underlying complexity to users.

We saw that note about how it's version controlled internally; we were actually planning to tap into it as we planned out the hack but realized it wasn't exposed in the API. We would have really loved a way to list all internal snapshots as wall as revert to one given a snapshot ID. Even if it's not exposed in the UI it'd be pretty cool if it was in the API.

Also while we're at it, we would have loved to be able to listen to user-generated events (a la GitHub Webhooks).

I've always wanted a local script that would back up all the playlists automatically (instead of having to copy-paste things manually like you can do now), and be able to run it whenever you want to back it up. I don't even care about restoring, I just want to keep my playlist info in any plaintext format so that if Spotify disappears or I leave, I can still have the playlist info and rebuild them elsewhere.

Does this exist, or would I have to hack my own script together?

You could probably use this project as a starting point if you were going to make one! Look at

- api.coffee[1] for what internal API we're using

- spotify.coffee[2] for what Spotify end points we're using

[1]: https://github.com/jez/tunemachine/blob/master/routes/api.co... [2]: https://github.com/jez/tunemachine/blob/master/spotify.coffe...

I used this recently when exporting my Spotify playlists for my switch to Apple Music. It worked pretty well. You still need to copy and paste but it grabs all the correct information for each track.

https://github.com/jlund/spotify-export/

I have a (really quite crufty) project that exports Spotify playlists (but not STARRED) to XSPF file format.

https://github.com/rjp/spotify-playlists

WFM, YMMV, Caveat Emptor, etc.

I know this isn't a terribly helpful reply without more detail, but if you're going to hack your own script together, and you're using the Linux native version of the Spotify client, you ought to be able to get all of your playlist information out using dmesg. (The Linux client is quite nice!)

This looks nice!

On a slightly related note, has anyone already run into a Spotify to Apple Music playlist converter? I'm curious to see if Apple Music has all the music available that Spotify has. I'm thinking about switching after all the changes that Spotify has implemented over the years.

Thanks for the compliment XD anyone interested should check out the portfolio of Min Zhou[1], who can take full responsibility for the design.

[1]: http://www.min-zhou.com/

very cool — nice running to you in SF last week, Jake :)

Yeah, that was a crazy coincidence. And thanks!