When started at boot as a service discovery may fail due to it
trying to bind to interfaces before the network is actually up.
This could be prevented in systemd by starting the service after
network-online.target but it requires that a wait-online.service is
also enabled which is not always the case since a wait-online.service
can potentially hang the boot process until it times out in certain situations.
This allows for discovery to retry every 10 secs in the 1st 60 secs of uptime
before giving up thus papering over the issue and not holding up the boot process.
- Use variables directly in format strings.
As reported by clippy, variables can be used directly in the
`format!` string.
- Use rewind() instead of seeking to 0.
- Remove superfluous & and ref.
Signed-off-by: Petr Tesarik <petr@tesarici.cz>
* added an option to specify ip addresses to which mDNS should bind (ignored by `DNS-SD`)
* changed command line option to `zeroconf-interface` to be consistent with `zeroconf-port`
use builder pattern to DRY up the code
used macro to print warning message
* fixing register error
* renamed `bind_ip` variables to match the option to `zeroconf_ip`, to be more consistent
* Changed user help
Modified comments
Added block for condition to clean the code
Added new modification to the change log
Co-authored-by: setime <timeframe1@gmx.de>
Special thanks to @eladyn for all of their help and suggestions.
* Add all player events to `player_event_handler.rs`
* Move event handler code to `player_event_handler.rs`
* Add session events
* Clean up and de-noise events and event firing
* Added metadata support via a TrackChanged event
* Add `event_handler_example.py`
* Handle invalid track start positions by just starting the track from the beginning
* Add repeat support to `spirc.rs`
* Add `disconnect`, `set_position_ms` and `set_volume` to `spirc.rs`
* Set `PlayStatus` to the correct value when Player is loading to avoid blanking out the controls when `self.play_status` is `LoadingPlay` or `LoadingPause` in `spirc.rs`
* Handle attempts to play local files better by basically ignoring attempts to load them in `handle_remote_update` in `spirc.rs`
* Add an event worker thread that runs async to the main thread(s) but sync to itself to prevent potential data races for event consumers.
* Get rid of (probably harmless) `.unwrap()` in `main.rs`
* Ensure that events are emited in a logical order and at logical times
* Handle invalid and disappearing devices better
* Ignore SpircCommands unless we're active with the exception of ShutDown
- Fixed resolve function panicking when resolving endpoint type with no
AP in the list
- Fixed fallback APs not being applied when only some of the AP types
were missing
- Switch container type from `Vec` to `VecDeque` for the `AccessPoints`
- Remove the note about fallback AP being used even if the port is not
matching the configured `ap_port`
When librespot is built with Avahi turned on, it will crash if Avahi is
later not available at runtime.
This change avoids it crashing hard when Avahi is not available;
librespot will merely warn of the issue.
This affects some distribution packages too, where the maintainer might
prefer leaving Avahi support enabled, but many setups don't (or can't)
run Avahi.
Co-authored-by: Nick Steel <nick@nsteel.co.uk>
This sets the name displayed by PulseAudio to Librespot - Instance Name if a name is given otherwise Librespot (the default name).
This also sets the correct "role" as per the docs:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/ApplicationProperties/
PA_PROP_MEDIA_ROLE
"This is a property of the actual streamed data, not so much the application"
Roles are used for policies, things like automatically muting a music player when a call comes in and whatnot.
For bonus points this also sets PULSE_PROP_application.icon_name to audio-x-generic so that we get a nice icon in the PulseAudio settings by our name instead of a missing icon placeholder.
When there's a value that corresponds to an argument name used in the same command line, the logging of the arguments gets confused and logs the matching argument, but without the leading dash:
```
% target/debug/librespot -n c --verbose -c /path/to/my/cache
[2022-02-07T22:32:25Z INFO librespot] librespot 0.3.1 55ced49 (Built on 2022-02-07, Build ID: qaEB8kEW, Profile: debug)
[2022-02-07T22:32:25Z TRACE librespot] Command line argument(s):
[2022-02-07T22:32:25Z TRACE librespot] -n "c"
[2022-02-07T22:32:25Z TRACE librespot] c "/path/to/my/cache"
[2022-02-07T22:32:25Z TRACE librespot] --verbose
[2022-02-07T22:32:25Z TRACE librespot] -c "/path/to/my/cache"
```
Here we're using the literal `c` as the device name, and the `-c` argument. Thus the `c /path/to/my/cache` is logged in addition to `-c /path...`.
After checking whether the key has a leading dash, this issue is gone:
```
% target/debug/librespot -n c --verbose -c /path/to/my/cache
[2022-02-07T22:32:41Z INFO librespot] librespot 0.3.1 55ced49 (Built on 2022-02-07, Build ID: qaEB8kEW, Profile: debug)
[2022-02-07T22:32:41Z TRACE librespot] Command line argument(s):
[2022-02-07T22:32:41Z TRACE librespot] -n "c"
[2022-02-07T22:32:41Z TRACE librespot] --verbose
[2022-02-07T22:32:41Z TRACE librespot] -c "/path/to/my/cache"
```
