| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
10/10 odds this is going to cause some merge conflict soon oh god
|
|
|
|
this makes it so that the value of timeData at any point will always be
associated with the track which is currently playing. i thought this was
already how timeData worked -- that assumption is what makes a lot of
the math in updateQueueLengthLabel work!
|
|
|
|
|
|
|
|
$ mtui --player sox --player-options bass +25 \;
|
|
|
|
...to play. This is useful when you have non-playables interweaved with
tracks, e.g. a file for each track's art.
|
|
This fixes mtui crashing whenever you process the metadata of any group
including a non-track too.
|
|
|
|
The download code doesn't actually really depend on state, besides
having access to the record for the track, which we can pass in from
anywhere.
|
|
Currently uses meta+(c, x, n, p, up, down) keys as the only interaction
method, but that'll change soon!
|
|
Currently bug-free and doesn't change anything about existing mtui
behavior! Meta N to create a new player, meta up/down to switch between
which one you're interacting with. Each player has its own queue.
Eventually (soon(TM)) there'll be much better UI to go with all this!
|
|
|
|
Now /that/ was hard to fit in the commit line length. (:
|
|
I.e, fix a reference to the now nonexistant playNextTrack. This fixes a
crash that happens when "Play later" is selected on the currently
playing track (since doing so is meant to skip to the next song in queue
before moving the play-later'd track).
|
|
...into its own function. To be used to get the total duration string of
a grouplike.
(This is stored on the backend instead of a more general playlist-utils
function because it requires access to the metadata code specific to
mtui.)
|
|
|
|
|
|
|
