Previously, creating the list meant that all database rows would be
loaded and objected even if you had a limit in place on your page
query, which was a huge waste.
I am trying to cut down the API cost of refreshing all channels.
I hoped to find and endpoint that would give me videos from
multiple playlists at once, but Youtube doesn't seem to support
that. Next best option is to at least store the ID of the uploads
playlist, saving 2 api points each.
Some of these are ones I've experienced first-hand, others are
defensive because I realized I don't know what kind of weird
things might be out there. Can do more if necessary.
The "New videos are" dropdown and the sorting options are both
horizontal, so this one being vertical stuck out badly visually.
This is a little better.
Not actually used by the application at the moment, but in the
interest of making this particular file a better representation
of the API, this felt like an easy change that I can take advantage
of later now that I have it.
In order to improve the configurability of the queuefile creation,
which I can't really do when relegating that to a possibly third-party
function with only the video id as argument, I've decided I want to
go all in on the queuefile as the output of ycdl. Actually downloading
the video is best left to another tool designed for the task.
Any third-party downloading function would always introduce the
possibility of network errors and crashes, ruining the call stack
of ycdldb.download_video for no good reason.
Previously, the "add channel" box was just calling refresh, which
implicitly adds the channel. This adds a separate endpoint for
add_channel, and as a bonus the web ui will navigate you to the
channel after it has been loaded.
