Queue now has a separate 'ready' property to indicate it's ready to be used, which is independent from whether it's still loading tracks in. This also improves the response time for shuffling all tracks (we will initially pick a random track in the first 100 tracks whilst the rest of the tracks are loading). This should also fix issues where one song will start playing and then repeat itself when the queue finishes loading, and hopefully solve #160 as well (though I couldn't actually repro this myself).
Co-authored-by: jacqueline <me@jacqueline.id.au>
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/170
Reviewed-by: cooljqln <cooljqln@noreply.codeberg.org>
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
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>
- fix a use-after-free involving the alerts container that was
happening when showing the first screen
- fix some issues where the splash screen wouldn't come up as early as
it needs to when another bootup task was making heavy use of the spi
bus
- Blank the display when locking to prevent burn-in
- Delay turning the display on until *exactly* after the first lvgl flush
- Init the display in the ui task to avoid blocking the rest of boot
this gives us a way to give each screen nice little hooks, like
'onShown' and 'onHidden'. later we can use these hooks to disable
bindings for screens that aren't in-use.
ailurux
jacqueline
Robin Howard