Seems strange that these fields return true in the has_ methods when as
far as I can tell it's impossible to remove the shuffle/repeat state in
the client without explicitly toggling them with their dedicated buttons
The client's expected MAC will not match librespot's derived MAC
if the client used the wrong public key. This can happen if librespot
is restarted (and thus generated a new key) but the client is still
mistakingly using the old public key. When this happens we do not need
to panic, we can just abort the connection attempt.
This fixes an issue loading new tracks probably caused by an update on spotify's side. The fix was suggested by @worleydl, all glory to them for figuring it out.
* create Volume struct for use with Cache
* add "volume" file to Cache
* load cached volume on start, intial overrides cached overrides default
* amend volume_to_mixer function to cache the volume on every change
* pass cache to Spirc and SpircTask so volume_to_mixer has access
* rustfmt changes
* revert volume_to_mixer function and Spirc/SpircTask cache variable
* Volume implements Copy, pass by value instead of reference
* clamp volume to 100 if cached value exceeds limit
* convert Volume to u16 internally, use float and round to convert hex->dec
* convert initial_volume and ConnectConfig.volume to u16 as well
* add cache_volume function to SpircTask
* remove conversion to/from percentage on cached volume
* consolidate device.set_volume, mixer.set_volume, and caching
* streamline intial volume logic
