In order to make the playlist editor more useful without having to use an external tool, we need to display the track start time (generated from the running total of lengths) as well as the track length in the playlist editor.

currently, we just limit any access to a group. in the future, we may want users to be able to only edit their own playlists. a "traffic admin" user might be able to edit any non-prerecorded playlist, "traffic-staff" can only create non-prerecorded, "librarians" can create and edit anything, and "fmdjs" can create any playlist.

because of our split view dns, web proxies, and other stuff, we need a way to translate "internal" names to "external" names. this isn't just a matter of chaning the hostname; it may also include changing protocol or path. we need a sophisticated way to do this.

iOS 13.x Safari: cannot use hamburger menu.

hamburger implies there are actions that can be taken: a circled info button seems better

dunno if this is an elasticsearch knob, but Artist: and artist: should return the same results

add a toggle to allow DJ to view "approximate start time" instead of "offset" for tracks. This would be a huge boon for half-hour-offset shows (daytime new music slots, mostly).

If Elasticsearch breaks, pload should still operate with reduced functionality. We should make sure to test this, as a DJ was running into issues this morning when Elasticsearch ran out of memory and got OOMkilled.

it would be really nice if I could make the playlist list bigger, or the search bigger, depending on what I'm doing, so a draggable divider would be awesome.

use em or some other font-relative size instead

Currently Pload is liscensed under a 3-clause BSD liscence. Ignoring my personal distaste for it (I think ISC is better suited for those intentions), pload has grown beyond its' original scope. Should we reliscense under AGPL-3 or MPL-2, to be more consistent with other projects?

We should extract this metadata and display it in the playlist editor to make playlist generation more pleasant. I don't think label is necessary for this view although it's probably desirable for search.

This was a feature request from a user. Obviously, we should forward that tag as label= to johnny-six.

This creates some overhead for development (i.e. we need to document how to use it), but it reduces the repo size and makes github language stats a little more reasonable.

It would be nice to export a M3U of the current playlist from the playlist editor interface. We should be able to do this entirely on the client side.

Currently in the playlist editor, you have to click the "View track information" button to get the URL of the audio file that's going to be played. It'd be neat if there were an option to display this somewhere near the track without having to click that button (I was thinking just an extra "row" of space where the URL would go, but mm suggested a tooltip/mouseover, which might be nicer).

This would make it easier to check that a playlist is sorted (e.g. Doncasts where all of his audio is 01, 02, 03... .mp3) without having to perform a bunch of extra mouse clicks.

Occurred with a wuvtLinx preview link.

we currently rely on an external postgres instance, which requires familiarity with docker networking to get working right.

this would open the link to the track in a new tab (and thus start playing with in-browser player), and be easier than clicking on the hamburger and "open in new tab" on the link.

When viewing a playlist that has at least one track marked as played in the database, there a different view is displayed that shows a URL and a "played" column. This "played" column is not really accurate; it means that a track has been queued by Liquidsoap but not necessarily played. We should use different language here.

dragging only allows appending, so a track cannot be moved to the first position: instead, one must drag it to the second position and move the track in the first position. It's not clear why to the user.

I like "show type".

see:

I also don't think it should be next to the "add link" button, but that's just me.

the playlist editor is hard to use because it is not dense. we should either make it more dense, or make a checkbox to set the density to high.

If a playlist is created, but no tracks are added. It does not appear in scheduled playlists but another playlist cannot be made during that slot.

because we toss the entire elasticsearch index and replace it to update, it's effectively not possible to create or edit playlists when replacing records. we should figure out how to make updates faster or less disruptive.

https://github.com/wuvt/pload/blob/master/pload/templates/playlist_editor.html

These should be consistent, as it will make styling easier.

For playlist creation, we've decided to use elasticsearch. The exact formats of records will change over time, but will include basic metadata, album, artist, and label.

• search elasticsearch with query language
• use record to add track to playlist
• use basic auth for elasticsearch interface; proxy user queries

it's very easy to get confused by the add track modal if it takes time. either poping up a rotating icon, clearing the field, and allowing the user to add another track, or just locking out the "add track" button will make it harder to accidentally add tracks multiple times

On wide screens (like, browser full-screen on a 1920x1080 monitor), it would make more sense if I had the playlist on the left and the search on the right, so that I get more rows of both.

currently it's fixed size. It should dynamically resize, to make the UX a little cleaner

the search api only shows the first 10 results. we should say "showing 10 of XXX" (which is reported by the API), and remind users to refine their queries.

The site doesn't scale well to mobile. We should fix that.

it is possible to upload files that do not include core fields. throw errors and fail quickly before doing this.

at least it doesn't work when a playlist is playing out (which is a feature, but it shouldn't throw a 500).

Pload sends a JSON blob of track status when tracks fail to validate. display this to the user.

It confuses users (for example, Len confused it as "overwriting" automation traffic)

c.f. https://github.com/elastic/elasticsearch-py/blob/master/examples/bulk-ingest/bulk-ingest.py

should we steal most of the trackman interface for that, and modify johnny-six to log all those things?

m4a can't be played by johnny-six (see wuvt/johnny-six#18). We should not validate such tracks.

e.g. I try to upload a 94-line playlist, and I assume in the process of checking all of the tracks, I get a timeout error. the playlist was still uploaded completely.

prerecorded shows are being played; automation playlists are not.

only paths in wuvt.vt.edu, ending in ogg, flac, or mp3 should be allowed. currently we only check for a 200 response

it should be possible to reschedule a playlist in the "edit playlist" view.

Sometimes I know I want a track by a specific artist, but either don't know what albums we have or don't know what tracks are on an album. So we should implement a pseudo-file-browser view where I search for artist, and can see album groupings.

Open questions: should we have an index generated from elasticsearch to create this view? Should this be a toggle on the search card or a seperate tab?

we should show the position of tracks on the playlist editor, since it's not super obvious without that indicator how long a playlist is.

currently, users can just follow links: our auth proxy makes this not suck. but ideally users would have a better interface in the future.

In order to make playlist planning easier, we should display the track length in the search view.