Skip to content

Seek the music you may be missing by analyzing your collection

License

Notifications You must be signed in to change notification settings

w0rd-driven/beatseek

Repository files navigation

Beatseek

Beatseek uncovers the gaps in your music collection by verifying your local files against the Spotify API.

Table of Contents

Documentation

KNOWN ISSUES:

  • The scan upsert is a little too eager
    • Every scan acts like an insert or update, overwriting updates that happen during the verify stage.
    • Scans should be indempotent, the date placeholders changing makes this untrue.
    • I failed to test multiple workflows until the UI was wired up. Scans and verify steps work perfectly fine in isolation.

Troubleshooting

  • To connect to the database via TablePlus, run the command fly proxy 15432:5432 -a beatseek-db in a dedicated terminal to keep the proxy active.

  • "Only valid bearer authentication supported"

    • This is shown in the oban_jobs table or displayed when using the UI for an individual artist
    • The full error is:
    ** (MatchError) no match of right hand side value: {:ok, %{"error" => %{"message" => "Only valid bearer authentication supported", "status" => 400}}}
        (beatseek 0.1.0) lib/beatseek/verification/spotify.ex:17: Beatseek.Verification.Spotify.get_artist/1
    • The secrets SPOTIFY_USER_ID, SPOTIFY_CLIENT_ID, and SPOTIFY_CLIENT_SECRET were not set or not migrated to v2.
    • To fix, use fly secrets set <copied line from .env> and repeated until all variables have been set.
    • Other secrets not in our local environment are DATABASE_URL, RELEASE_COOKIE, and SECRET_KEY_BASE.
  • "Constraint error when attempting to insert struct: * albums_pkey (unique_constraint)"

    • The full error is:
    ** (Ecto.ConstraintError) constraint error when attempting to insert struct:
    * albums_pkey (unique_constraint)
    If you would like to stop this constraint violation from raising an
    exception and instead add it as an error to your changeset, please
    call `unique_constraint/3` on your changeset with the constraint
    `:name` as an option.
    The changeset has not defined any constraint.
    
    • The migration created create unique_index(:albums, [:artist_id, :name]) so it should be a unique artist_id AND name here.
    • The changeset doesn't include this and the docs specify to reverse the order as "name" would be the error key we want.
    • This oddly isn't a problem locally and I wonder if it's due to importing the table data directly
    • To view the current values in a sequence, use the SQL SELECT last_value FROM albums_id_seq; or SELECT pg_sequence_last_value('public.albums_id_seq'); also works
    • The fix is SELECT setval('albums_id_seq', (SELECT MAX(id) FROM albums)); for each table affected, artists and albums.

Phoenix Framework

To start your Phoenix server:

  • Run mix setup to install and setup dependencies
  • Start Phoenix endpoint with mix phx.server or inside IEx with iex -S mix phx.server

Now you can visit localhost:4000 from your browser.

Ready to run in production? Please check our deployment guides.

Learn more