Avahi gives us several ipv6 addresses for an ATV4 that aren't actually
connectable. Here we simply try to make a connection to the address,
and if it is not possible within a timeout we ignore the announcement.
We also now don't start a mdns record browser if the address from the
resolver passes the connection test and isn't link-local.
Changing a speaker volume in a DACP clients results in two dacp requests
(at least in Retune):
setproperty?include-speaker-id=0&dmcp.volume=41
setproperty?speaker-id=198018693182577&dmcp.volume=43
The first request sets the absolute volume for the speaker (player.c -
volume_setabs_speaker). The second request is only triggered if the
volume from the first one is not the new master volume. This second
requests adjusts the relativ volume based on the loudest device (new
master volume) (player.c - volume_setrel_speaker). After the second
request the master volume and the relative volumes are correct (range
from 0 - 100 percent and master volume is 100 percent).
MPD and JSON API clients only set the absolute volume which results in
inconsistent master_volume and relative volumes. The added option to
update the master volume in volume_setabs_speaker/volume_setrel_speaker
makes sure the master volume and the relative volumes are correctly set.
Implements Active-Remote, which is sent to the speaker, so it can use this
to tell us who it is when it makes dacp request with a device-volume update.
These commands are not used by Remote, but some Airplay speakers are
able to make them (e.g. my Sony STR-DN1040).
Also prepare being able to set the device volume property.
Old Airport Express hangs up if we use GET_PARAMETER (despite announcing support
for it...), and since iTunes seems to use OPTIONS we also do that. We weren't
really using the return value of GET_PARAMETER anyway.
See also comment added to commit d9a67b6dce
Allows adding non-library spotify tracks to be added to the queue. The
path given to queue_add should either be a spotify track, album or
playlist uri.
For some reason it seems the Docker version of ffmpeg 3.4 uses "optimal"
Huffman tables (despite not being default), which cause ffmpeg to crash
when mjpeg encoder is encoding artwork jpeg's
