tsani / apollo Goto Github PK

We need an endpoint to allow clients to query the state of the playlist. Currently, the only supported operation is enqueuing tracks.

An interesting flow could be: 1. fetch playlist; 2. use interactive editor clientside to produce a subset of the tracks on it; 3. send transcode requests for each identified track; 4. send archival request for all transcoded tracks by this process; 5. download archive. This would be a nice workflow for music export (see #6).

• get playlist
• move track(s) in playlist
• delete track(s) in playlist

Because youtube-dls are done synchronously (in apollo-dl) nginx sometimes kills the connection because it thinks upstream is dead.

See #1. With the refactor of /tracks proposed therein, we could implement a query-string parameter enqueue_at specifying that the acquired tracks should be enqueued at the given position. The position specifier would be the same as the position query-string parameter for PUT /playlist. Because we can't distinguish between a parameter being present but failing to parse and a parameter being absent, we will assume that that if enqueue_at is Nothing, then no enqueuing is to be performed. We can implement an additional query-string flag enqueue (no _at) whose value is ignored, but that serves to indicate that the default behaviour for PUT /playlist of enqueuing after the currently playing track in the playlist is desired.

First, the zip archive constructed from the audio files doesn't need to be compressed, since the audio files themselves are compressed. Compressing each file is slow, whereas simply storing it would be faster.

Second, the construction of the zip archive does not operate in a nicely bounded amount of space. Ideally, we would want the space usage of the archival process to be constant. I think that we can get it to operate in constant space, since the CRC32 checksum of the files can be computed in constant space by streaming the file into the checksum function, and the file can be read again when it is to be written into the archive, uncompressed. Both of those operations run in constant space, so overall it should run in constant space. This probably means that the zip-archive library is doing something silly.

To prevent unauthorized access to the server. Not really urgent, but it's worth noting that we do get hit by automated vulnerability scanners.

This turns apollo itself into the server for the HTTP music stream, instead of leveraging MPD. This means we have more flexibility in the way we integrate the HTTP API with the music stream.

We currently use command-line arguments, but these aren't as self-explanatory as environment variables which have names. (Read: I keep forgetting the argument order because I never bother to write it down, so I have to reread Main.hs again and again.)

Music export now issues one transcode request per track. This wastes a lot of time on HTTP round-trips in the (current) best-case scenario where most (or all) of the tracks already have transcodes.

Implementing a bulk transcode mechanism would mean sending only one (large) request containing the complete list of tracks to transcode. Then checking that they exist can be done in one large loop.

Currently, a trivial value [] is returned after a POST to /download. Instead, we should return the list of paths created by the download. Thereafter, the client could send a request to append those paths to the current playlist.

Issue #6 contains a discussion of improving the /transcode endpoint, in particular allowing for lookup of transcodes by track path, looking up all available transcodes of a given track, etc.

To reproduce: download something (new) with the apollo-dl; the enqueue will fail (I believe with a 4xx error, which is odd). Run apollo-dl again with the exact same arguments and the download will occur a second time and the enqueue will succeed.

As discussed on the mailing list, Apollo should support some kind of export feature, for offline listening.

We currently only support youtube-dl downloading, but if a user has a link directly to an audio file, we should be able to download that. Also, links to zip files or other archives?