search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD media server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2k stars 229 forks source link

Different icons for different types of streaming output #1056

Open SamuelCook opened 3 years ago

SamuelCook commented 3 years ago

When using the web interface, AirPlay sources appear with identical icons.

My airplay receiver offers two targets, one for Apple TV and another for Apple Lossless Audio - however, both appear with the same icon in the forked-daapd web display, making it impossible to determine which is which.

image

As an example, the Apple Music application displays the two targets with an icon depicting their use.

image

ejurgensen commented 3 years ago

I haven't come across this before, what device is this? And can you post the output of avahi-browse -r -k _raop._tcp? I would like to see what exactly the device announces.

SamuelCook commented 3 years ago

The Airplay server is AirServer Windows 10 Desktop Edition. Pallida is the name of the computer on which it's running.

forked-daapd is running on a Rasberry Pi4 running the latest Raspberry OS.

Output of avahi-browse -r -k _raop._tcp:

+   eth0 IPv6 00155D1D01D8@Pallida                          _raop._tcp           local
+   eth0 IPv6 ea7b1e8a285b@Pallida                          _raop._tcp           local
+   eth0 IPv4 00155D1D01D8@Pallida                          _raop._tcp           local
+   eth0 IPv4 ea7b1e8a285b@Pallida                          _raop._tcp           local
=   eth0 IPv6 00155D1D01D8@Pallida                          _raop._tcp           local
   hostname = [Pallida.local]
   address = [192.168.0.3]
   port = [7000]
   txt = ["et=0,3,5" "ft=0x5a7fdfd1,0xe" "vv=2" "cn=0,1,2,3" "da=true" "am=AppleTV3,2" "pk=dc8ec12f1c421b5a07979cc352203ee9a5f7712044dc631bd99985e05b9a5eb5" "sv=true" "vs=220.68" "md=0,1,2" "sf=0x04" "vn=65537" "tp=UDP"]
=   eth0 IPv6 ea7b1e8a285b@Pallida                          _raop._tcp           local
   hostname = [Pallida.local]
   address = [192.168.0.3]
   port = [7001]
   txt = ["ch=2" "sm=false" "ss=16" "et=0,1" "cn=1" "da=true" "ek=1" "sv=true" "txtvers=1" "md=0,1,2" "pw=false" "sr=44100" "vn=3" "tp=UDP"]
=   eth0 IPv4 00155D1D01D8@Pallida                          _raop._tcp           local
   hostname = [Pallida.local]
   address = [192.168.0.3]
   port = [7000]
   txt = ["et=0,3,5" "ft=0x5a7fdfd1,0xe" "vv=2" "cn=0,1,2,3" "da=true" "am=AppleTV3,2" "pk=dc8ec12f1c421b5a07979cc352203ee9a5f7712044dc631bd99985e05b9a5eb5" "sv=true" "vs=220.68" "md=0,1,2" "sf=0x04" "vn=65537" "tp=UDP"]
=   eth0 IPv4 ea7b1e8a285b@Pallida                          _raop._tcp           local
   hostname = [Pallida.local]
   address = [192.168.0.3]
   port = [7001]
   txt = ["ch=2" "sm=false" "ss=16" "et=0,1" "cn=1" "da=true" "ek=1" "sv=true" "txtvers=1" "md=0,1,2" "pw=false" "sr=44100" "vn=3" "tp=UDP"]
ejurgensen commented 3 years ago

What AirServer is announcing is two Airplay services, which is peculiar because it is only necessary to announce one. An Apple TV, for instance, only announces one service, but is still capable of everything.

Both these announced services should be equally valid Airplay audio services (there is no such thing as a "Apple TV" service and a "Apple Lossless" service), so it shouldn't actually matter what service you choose. Is that not what you observe?

It's not that I mind having different icons, but it would be a partial fix, because it would only make it possible to differentiate in the web UI, not other clients. So I think the true fix for this is with AirServer.

SamuelCook commented 3 years ago

According to AirServer - and I've no way of knowing whether or not they're correct - the audio-only service is akin to an Airport Express and is lossless. The Apple TV service streams AAC-compressed audio, presumably to optimise bandwidth to accommodate streaming video content as well.

It's unclear if this is only a factor when streaming from a Mac (e.g. when pointing Apple Music at the forked-daapd library and then streaming to an Airplay target).

ejurgensen commented 3 years ago

forked-daapd will send the same ALAC to both services. I'm not sure what Apple Music does, but if it is audio only I don't see why it wouldn't do the same. For video it could make sense to use AAC, like you write.

I have tested a bit with AirServer, and I saw some odd behaviour here and there. A major issue was that when it was idle in the background it didn't respond to connection requests? To me it seems like it might need some more work. If you are in contact with a dev you could suggest that he reaches out here on github, then I can share my observations.

cdlenfert commented 3 years ago

@SamuelCook It also seems like it would be helpful for you to simply exclude the "Apple TV" speaker from your forked-daapd config file. Since you'd only ever want to send audio from Forked Daapd, this should work. That's assuming there's some more technical way to figure out which speaker is the "Apple TV" speaker. Can you temporarily disable one in AirServer?

SamuelCook commented 3 years ago

@ejurgensen:

A major issue was that when it was idle in the background it didn't respond to connection requests? To me it seems like it might need some more work.

I've noticed this, too. I agree that it could use some work.

If you are in contact with a dev you could suggest that he reaches out here on github

I'm not, but thank you for the offer.

@cdlenfert :

Can you temporarily disable one in AirServer?

Sadly no, although I've created a ticket in AirServer's support to request that feature.

That's assuming there's some more technical way to figure out which speaker is the "Apple TV" speaker.

You've hit upon the problem - the "Apple TV" service has the same broadcast name as the "Airport Express" speaker.