nils/shairport-sync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update release notes

Browse Source
This commit is contained in:
Mike Brady
2023-05-20 17:54:17 +01:00
parent 25ac1017d1
commit b46962c733
1 changed files with 58 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RELEASENOTES.md
+58 -2
View File
@@ -1,4 +1,60 @@
Version 4.1-rc0 Release Candidate
Version 4.2
====
This release consists of enhancements and bug fixes to Version 4.1. For information on the new features of 4.1, including AirPlay 2 support, please see the section "Version 4.1" below.
Important
----
If you are updating an existing installation of Shairport Sync, you must also update [NQPTP](https://github.com/mikebrady/nqptp). The reason is that this update to Shairport Sync requires NQPTP with Shared Memory Interface Version `smi9` and will not work with older versions.
* The Shared Memory Interface Version `smi*` needed by Shairport Sync is part of its version string, obtainable using `$ shairport-sync -V`.
* You can check the Shared Memory Interface Version of the installed version of `nqptp` using `$ nqptp -V`.
**Enhancements**
* Allow compilation with `libplist` version `2.3.0`. Thanks to [Markus Reiter](https://github.com/reitermarkus).
* Updates to GitHub Action Workflows -- many thanks to [yubiuser](https://github.com/yubiuser).
* Update to the MQTT documentation to correspond to updates in [Home Assistant](https://www.home-assistant.io/blog/2022/06/01/release-20226/#breaking-changes). Thanks to [hunhejj](https://github.com/hunhejj).
* Update to the PTP clock for improved performance.
**Docker Enhancements**
* Add basic PulseAudio support to the Docker images. Thanks to [Ferdynand Naczynski](https://github.com/nipsufn) and thanks also to [Noel Hibbard](https://github.com/noelhibbard) for championing this idea for a long time.
* Update the Docker images to use Alpine 3.17 and ensure services such as Avahi and D-Bus start in the correct order. Thanks to [yubiuser](https://github.com/yubiuser).
**Bug Fixes**
* In some situations, the Device ID generated by Shairport Sync was all zeros, and so was invalid, causing connectivity problems. The cause of the problem was that `get_device_id` was not interpreting `getaddrinfo` information correctly. Thanks to [Carl Johnson](https://github.com/ridgelift) for [reporting](https://github.com/mikebrady/shairport-sync/issues/1657) the issue, finding the (rather obscure) cause of the problem and for providing [code](https://github.com/mikebrady/shairport-sync/issues/1657#issuecomment-1493423175) to fix it.
* Fix a bug reported in Issue [#1633](https://github.com/mikebrady/shairport-sync/issues/1633). The bug was that when a Realtime Audio stream (e.g. playing from Spotify on iOS or using Shairport Sync as the Sound Output on a Mac) was played, it was fine, but when a second stream was started, it could not be heard. The problem was that the PTP clock was not being correctly revalidated for second and subsequent Realtime Audio streams. The fix was to ensure that the PTP clock is revalidated on second and subsequent plays on the same connection. Thanks again to [David Leibovic](https://github.com/dasl-) for finding the problem.
* Use TCP keepalive a little more generally -- treat it the same as a client closing the link rather than just an error.
* Remove three potential race conditions between Shairport Sync opening a TCP connection and the client checking that the connections are open. The problem was that the connections were being opened in threads that were created just before the client was given the connection information. If the threads were delayed (e.g. on a slow or busy processor), the client could use the connection information to check the connections, but find that they were not (yet) open. This could cause the client to terminate the session immediately with a `TEARDOWN`. The fix was to open the connections before creating those threads and before sending the connection information back to the client. In this way, the connections are guaranteed to be open before the client has the information it needs to try to open them, even if the threads ared delayed in starting. This bug would manifest itself by allowing play to proceed but not play anything.
* When built for AirPlay 2, ensure the hexadecimal string that prefixes the AirPlay 1 Service Name in the Bonjour text strings matches the AirPlay 2 Device ID. For example, if the Service Name is `Kitchen` and the AirPlay 2 Device ID is `b8:2f:eb:d7:85:df`, the AirPlay 1 Service Name should be `B82FEBD785DF@Kitchen`. (When built for AirPlay 1, the hexadecimal prefix is simply a hash of the Service Name.) Thanks to [Casper](https://github.com/casperghst42) for raising the [issue](https://github.com/owntone/owntone-server/issues/1578) and to [ejurgensen](https://github.com/ejurgensen) for identifying the cause of the problem.
Version 4.1.1
====
This release consists of enhancements and bug fixes to Version 4.1. For information on the new features of 4.1, including AirPlay 2 support, please see the section "Version 4.1" below.
**Enhancement**
* Use the TCP `keepalive` facility to close a play session if the client connection drops for a minute.
**Metadata Enhancements**
* Add `FramePosition` (`phbt`), `FirstFramePosition` (`phb0`), `OutputRate` (`ofps`), `OutputFormat` (`ofmt`), `StreamType` (`styp`), `ServiceName` (`svna`), `ClientName` (`snam`) properties to the D-Bus interface and to the metadata stream (codes in brackets).
* `FramePosition`/`FirstFramePosition` metadata is generated only if the `progress_interval` in the `metadata` section of the configuration file is non-zero. The progress interval can also be set by a new `SetFramePositionUpdateInterval` method in the D-Bus interface.
* `FramePosition`/`FirstFramePosition` metadata is of the form `<RTP Frame number>/<Local Time>` where the local time, in nanoseconds (a 64-bit number), is the precise time that frame should be played. The metadata is generated when the frame is placed in the output buffer, and is thus generated `audio_backend_buffer_desired_length_in_seconds` (usually 0.2 seconds) before the time in question.
* Add `xesam:albumArtist` and `xesam:composer` metadata (if available) to the metadata bundle presented in the D-Bus interface.
* Add a new metadata item: `sps:songdatakind`, derived from the `asdk` metadata token, to the metadata bundle presented in the D-Bus interface. If `0` it seems to indicate an item of a specific duration such as an audio track; if `1` it seems to mean the stream is of unknown duration, for example an internet radio stream.
**Docker Enhancements**
* Launch the `shairport-sync` app as `root` user within the Docker container rather than as the user `shairport-sync`.
* Add the configuration file and the sample configuration files back into the Docker image.
**Bug Fixes**
* Fix a bug that prevented multiple classic AirPlay instances being recognised. The bug was that the 12-digit classic AirPlay service name prefixes for each instance were all identically derived from a MAC hardware address. The fix was to modify the generation of prefixes to depend on the service name as well as the hardware address.
* Fix a bug that prevented play to the the PulseAudio backend from resuming after a pause. The bug was due to changes in the way pauses were handled and the fix was to reopen the stream if it is closed whenever a play or latency request was made.
* Fix a long-standing bug which didn't close the socket used for the RTSP connection, potentially exhausting the sockets available.
* Fix a bug in `audio_alsa.c` when there is no hardware device name.
* Add a configuration check for the `xxd` program when building for AirPlay 2.
* Fix a compilation bug on certain platforms by trying to use `AC_CHECK_LIB` to find `libavcodec` if the `PKG_CHECK_MODULES` check fails.
**Documentation**
* Include and reference the HTML version of the man page.
Version 4.1
====
Really Big Update -- AirPlay 2!
@@ -15,7 +71,7 @@ Here is a brief list of the high-level new features and changes (more to be adde
* AirPlay 2 operation.
* Improved `libao` backend for better compatibility with HomeBrew installations.
* Improved MQTT and D-Bus facilities.
* Automatically-generated Docker images (forthcoming).
* Automatically-generated Docker images.
There have been many many bug fixes and enhancements to the core operation of Shairport Sync.