tsani / apollo Goto Github PK
View Code? Open in Web Editor NEWHTTP MPD integration for Labcoders Radio
License: MIT License
HTTP MPD integration for Labcoders Radio
License: MIT License
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).
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.