zaknesler / modulate Goto Github PK

lol

Also the input switch color, make it lighter on dark mode.

Despite the many pleas lol:

• spotify/web-api#118
• spotify/web-api#413
• spotipy-dev/spotipy#601
• spotify/web-api#444

This isn't a thing on the API directly, so I'm guessing fetch the entire list of tracks from the target playlist (ugh) and remove duplicates from the list of saved tracks.

Add ability to change sync interval per watcher, still default 60 minutes. Store interval_mins and next_sync_at (or last_sync_at) on the watcher and update after every sync.

Interval options can be like 30 mins, 1 hour, 6 hours, 12 hours, 1 day, 1 week, 1 month?

Update sync thread to look up all watchers every minute to check which ones need to run.

e.g. for transfer errors, db errors, spotify errors, etc. then combine into one error for displaying on web.

Make a thread per user? Per watcher? Job queue with X workers? I dunno

Send an empty update request or something in POST /watchers?

The app is now in review and I swear the Spotify staff is flooding the test site with requests 😭

Maybe handle 429 responses from Spotify API calls in some nicer way?

If one watcher fails for some reason (no permission to remove, rate limiting, playlist doesn't exist, etc.), it'll throw an error and kill the process of trying to sync everything...

Not sure what the best solution is here, it could be discarding errors when syncing (e.g. not ? on the result), but I still want a log of job attempts and their result state (success, error, etc).

This could also include job retrying or preventing a watcher from running again (if playlist is removed, the watcher should be moved to a disabled state or something.

All of these things should be visible to the user (job history, errors, successes, etc.), so I think adding an activity_log table would be a good start.

It doesn't make sense, just keep it separate. Also means no INNER JOIN (and an extra DB call but it makes more sense).

Somewhat related to activity logs mentioned #23, it'd be nice to utilize the snapshot_id attribute returned when updating a Spotify playlist.

Snapshots act as version control for playlists, so when adding/removing tracks from playlists, it'd be nice to keep track of these. Both saving the snapshot_id after (and maybe before) a change, and also making updates to the same snapshot as described in the Spotify docs.

I transferred my Spotify tracks out of the playlist, leaving it empty. Now, since it doesn't have a preview image, it falls through the match and displays the heart as if it were the liked playlist:

For linux, windows, and mac.

Will need to update the config loading to read from ~/.config/modulate/.env as a fallback.

It's unnecessary, and the fields thing with get_playlist is annoying

POSTing a form is annoying to handle errors, and I don't care to update error messages from JSON (nice) to flash/session-based messages (eh).

Kinda want to be able to transfer my Shazam tracks too! Let's allow playlist to playlist transferring, and as part of that, allow multiple watchers to be created.

Given an enum like this that represents a playlist type:

pub enum Playlist<'a> {
    Saved,
    WithId(PlaylistId<'a>), // or Public? Generic? idk of a good name for a regular playlist
}

Match on a from and to variable to transfer between saved -> with id (current) and with id -> with id (playlist to playlist).

pub async fn transfer(&self, from: Playlist<'_>, to: Playlist<'_>) -> crate::Result<bool> {
    Ok(match (from, to) {
        (Playlist::Saved, Playlist::WithId(playlist_id)) => todo!(),
        (Playlist::WithId(from_id), Playlist::WithId(to_id)) => todo!(),
        _ => unimplemented!(),
    })
}

It's annoying

Tracks are read from the original playlist ordered newest to oldest, and so they are inserted into the target playlist in the wrong order.

Maybe? Would be pretty sweet.

Obviously wouldn't allow for transferring (i.e. copying and them removing from source), but being able to keep your own public/private playlist in-sync with a Spotify official playlist or a random playlist would be useful.

Maybe a combo box for the playlist input? Select one of your own or paste a URL/ID? Stretching askama thin here.

• Do not allow should_remove to be true when creating watcher where playlist_from is is not owned by the user
• Do not allow creating watcher where playlist_to is not owned by user

This should still allow for copying (not transferring) from a playlist not owned by the user.

The SimplifiedPlaylist items that are returned from current_user_playlists do not have any kinda info about whether the user can edit the playlist... hmmm.

Only way I can think of is when a user selects a playlist, hit a new endpoint that checks whether the user can edit it? Another way would be to get full details of each playlist but that doesn't seem like a good idea.

For any transfers (but it makes the most sense for playlist-to-playlist), I'd like to be able to add a filter (e.g. where year >= 2023) to move to another playlist.

A more detailed example would be transferring "My Shazam Tracks" to a "2023" playlist, where you disable removing from the Shazam playlist, and instead just copy all tracks Shazamed since 2023.

Can probably just store these as JSON on the watchers table.

Unless should_remove is false!