Skip to content

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

About

Seek the music you may be missing by analyzing your collection

Topics

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Contributors 2

  •  
  •