Thank you for the contribution! I'm a little confused, since in v0.3.5, the librespot version we were using, was already at 0.4.2. So this should not actually change anything. (the version spec 0.4 includes semver compatible versions like 0.4.2).

See here for one of the Cargo.lock lines at that time.

Confirmation on this, this solves the issues

Thank you for the contribution! I'm a little confused, since in v0.3.5, the librespot version we were using, was already at 0.4.2. So this should not actually change anything. (the version spec 0.4 includes semver compatible versions like 0.4.2).

See here for one of the Cargo.lock lines at that time.

Librespot pulled version 0.4 perhaps there some fudging with cargo due to that

Thank you for the contribution! I'm a little confused, since in v0.3.5, the librespot version we were using, was already at 0.4.2. So this should not actually change anything. (the version spec 0.4 includes semver compatible versions like 0.4.2).

See here for one of the Cargo.lock lines at that time.

How strictly does cargo respect the Cargo.lock? Suppose librespot 0.4.0 was installed before the update to 0.4.2. Afterwards the Cargo.lock was updated to 0.4.2. Does cargo force an update to 0.4.2 or would the installed 0.4.0 suffice as it matches 0.4? If it does not it would explain why setting the dependency to 0.4.2 explicitly solves the issue.

Seeing as the librespot dependencies in Cargo.lock are already on 0.4.2 and running cargo update would increase the base rust version beyond what the CI supports I've dropped the Cargo.lock changes.

In my quick test this still solves the problem, but has a better chance of passing the CI.

Have you tried compiling the current master without the Cargo.toml changes? In this case, we could just do a new release and things would work?