Libmdns v0.6 can't handle 'type 47'. Upgrade to v0.7

[delneet]

Describe the bug
When running a snapclient on a different subnet as the snapserver, the log is spammed with the following message.
[Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid

It only happens with clients on a different subnet. Clients on the same subnet are fine.

👉🏻 This should be resolved in libmdns v0.7 as described here librespot-org/libmdns#19

Steps to Reproduce

1. Run snapserver on 10.0.1.x subnet (via Docker https://github.com/lukashass/snapcast)
2. Run snapclient on 10.0.3.x subnet
3. Firewall ports - 1704, 1705,1780 allowed

Environment details

• OS: snapserver via Docker, snapclient on Android
• Snapcast version [e.g. 0.25.0]

Attach logfile if applicable
Generate logs with snapclient --logfilter debug or snapserver --logging.filter debug if possible and paste them in the following codeblock

server_1  | 2022-05-28 08-09-32.254 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 08-41-05.871 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-34.088 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-35.026 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-35.126 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-36.030 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-37.128 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-41.132 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-45.216 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-46.216 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-48.219 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-27-52.221 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 09-37-21.131 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 10-02-02.177 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 10-33-36.433 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 10-58-17.389 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 11-29-51.666 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 11-54-32.295 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid
server_1  | 2022-05-28 12-26-06.820 [Warn] (libmdns::fsm) couldn't parse packet from 10.0.1.1:5353: type 47 is invalid

etc.

[kingosticks]

Aren't these log messages coming from librespot? What should snapcast do about a bug in librespot?

[delneet]

Well, yes.
But since librespot fixed this by upgrading libmdns, I figured this update also needs to be reflected in Snapcast.
So I guess my question just comes down to please update to the latest librespot?
Or am I totally off track here?

[kingosticks]

Snapcast just uses whatever librespot binary it finds on the path, with a particular set of options as defined here . There is no librespot code/binary provided by snapcast. To fix this you need to update the version of librespot you have on your machine which snapserver will then use.

[delneet]

Ok, thank you for clearing this up for me.