Playground/MediaPlayer

From KDE Community Wiki
Revision as of 10:32, 5 January 2016 by Ochurlaud (talk | contribs) (Created page with "Discussion here is easier than on the etherpad. Please ''follow'' the page to now when it is updated. == Description of the interactions == We keep one collection that can m...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Discussion here is easier than on the etherpad. Please follow the page to now when it is updated.

Description of the interactions

We keep one collection that can morphed into different views (possibly a tree view, list, grid, whatever) 3 modules: database manager, collection manager, ui


Artists

Left panel: click on artists Middle Pannel > ??? collection view sorts by artists(highest rated or alphabetically)

Albums

Left panel: click on albums Middle Pannel > ?? show album covers grid view

                               double clicking an album cover replaces Now Playing with all the tracks from that album
                               
                               

Genre

Left Panel click on Genre Middle Panel > collection view sorts by Genre


Year

Left Panel click on Year Middle Panel > collection view sorts by Year ....

Database

    • do we really need so much metadata, most of it is not directly editable by end users => yes but they might want to see it, and it's faster to read the database than compute something on the file each time we want to show it.

foreign key relationships need to be defined properly before we implement in code

=> True for the foreing key relationship


Tracks

  • id
  • title
  • id_rootpath
  • complementary_path why do we need 2 path colums?? I based myself on Amarok: you have several folder, so you have a * relative path and a root path selected by the user. ok
  • duration
  • album_id
  • ? artist_id ? it could be recovered with track->album->artist by that logic track_artist_id can be recovered, so let's choose one _artist_id and recover the others as necessary
  • track_artist_id
  • composer
  • sample_rate**
  • bitrate**
  • bpm**
  • creation_date**
  • modification_date**
  • file_size**
  • file_type = format**
  • user_rate

Do we do 3 tables Artist/Album artist/Composer or do we add a int in it to tell which type it is? For instance track artist = 1, album artist = 2, composer = 4 so that 3 means the two first (and so on)

Artists

  • id
  • name
  • type (int: Composer/album artist/track artist) prefer the integer enum, no need to duplicate data

Albums

  • id
  • name
  • artist_id
  • year
  • cover_path this should be filepath to a local cache dir << Why cache? isn't .local/share/MusicPlayer/covers good ? that's a fine