I was confused about why setting the level to something lower didn't
seem to work, so this attempts make it more clear that not all log
levels are actually available on release builds.
Fixes#155
I think this is what most folks would expect to happen if BT is
disconnected/disabled and the headphones are removed.
Also, I think(?) this fixes one situation where the device doesn't idle/
sleep when folks would expect it to (not connected to headphones or bt).
This replaces the previous system of a separate track and queue repeat, with a RepeatMode type with the following options and behaviours:
- OFF: No repeat, queue or track. When the current queue finishes, shuffled or otherwise, playback will stop.
- REPEAT_TRACK: The current track will loop indefinitely, unless next is explicitly called through some user action (ie using the next button in the now playing screen)
- REPEAT_QUEUE: The entire queue will repeat indefinitely. When shuffled is enabled this will repeat the queue with new combinations each cycle.
The repeat mode is persisted in non-volatile storage, so the behaviour will be consistent throughout restarts and queue replacements, and so the "queue repeat by default" use case can be met in this way.
In addition, I've made it work a little nicer when the queue runs out in the now playing screen, keeping the previously played track shown and playback can be continued by using the play button or by going to a previous song in the queue.
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/126
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
Previously we were doing it synchronously, which led to some odd looking
livelock stacktraces... we still don't have a consistent repro, but this
at least makes the stack when we mount a lot more predictable
It's currently quite limited (no stereo or sample rate conversion,
multiple messages clobber each other, only plays if music is playing),
but we're getting there!
Clayton Craft
ailurux
jacqueline
malcircuit