|
a/doc/release-0.8.txt |
|
b/doc/release-0.8.txt |
| 1 |
= Notes for upmpdcli 0.8 release series
|
1 |
= Notes for upmpdcli 0.8 release series
|
|
|
2 |
|
|
|
3 |
== Minor releases
|
|
|
4 |
|
|
|
5 |
=== 0.8.1
|
|
|
6 |
|
|
|
7 |
0.8.1 has many changes in the library code, but almost none of them affect
|
|
|
8 |
the device side, they concern support for writing a control-point, which is
|
|
|
9 |
mostly disjoint. The following changes are relevant to upmpdcli, and
|
|
|
10 |
consistant with a minor release:
|
|
|
11 |
|
|
|
12 |
- When used with an non-OpenHome Control Point, multiple calls to
|
|
|
13 |
SetNextTransportURI no longer result in a lengthening of the MPD queue,
|
|
|
14 |
and a wrong playlist.
|
|
|
15 |
|
|
|
16 |
- The OpenHome Playlist metadata is now writen to a temporary file which
|
|
|
17 |
is then renamed, to avoid partial saves of big lists.
|
|
|
18 |
|
|
|
19 |
- The AVTransport service uses the OpenHome PlayList metadata cache
|
|
|
20 |
for describing the current track data to a pure AVTransport Control
|
|
|
21 |
Point. This is a very marginal improvement, and only makes sense in case
|
|
|
22 |
the AVTransport CP is used for displaying the current track.
|
|
|
23 |
|
|
|
24 |
- The OpenHome service was not completly switched off when the option was
|
|
|
25 |
off sometimes resulting in spurious error messages (and nothing more).
|
|
|
26 |
|
|
|
27 |
- Bad lock management inside the device code could result in a
|
|
|
28 |
semi-deadlock in rare situations. Upmpdcli would then mostly be gone from
|
|
|
29 |
the network, while still doing temporary appearances. This is linked to
|
|
|
30 |
design issues in libupnp, which handles quite badly a situation where a
|
|
|
31 |
subscribed Control Point responds very slowly or not at all to event
|
|
|
32 |
connections.
|
| 2 |
|
33 |
|
| 3 |
== Changes in upmpdcli 0.8.0
|
34 |
== Changes in upmpdcli 0.8.0
|
| 4 |
|
35 |
|
| 5 |
The main changes in release 0.8 deal with better handling of the OpenHome
|
36 |
The main changes in release 0.8 deal with better handling of the OpenHome
|
| 6 |
playlist, in addition to a number of small bug fixes, and efficiency
|
37 |
playlist, in addition to a number of small bug fixes, and efficiency
|
| 7 |
improvements.
|
38 |
improvements.
|
| 8 |
|
39 |
|
| 9 |
- OpenHome playlist: metadata from tracks directly added to the MPD queue
|
40 |
- OpenHome playlist: metadata from tracks directly added to the MPD queue
|
| 10 |
through an MPD client (such as, e.g. MPDroid, gmpc...) is now remembered
|
41 |
through an MPD client (such as, e.g. MPDroid, gmpc...) is now remembered
|
| 11 |
by *upmpdcli* and will be displayed in the UPnP control point.
|
42 |
by *upmpdcli* and will be displayed in the UPnP Control Point.
|
|
|
43 |
|
| 12 |
- OpenHome playlist: the metadata for the playlist is now saved to disk so
|
44 |
- OpenHome playlist: the metadata for the playlist is now saved to disk so
|
| 13 |
that it survives restarts (like the MPD playlist does). The previous
|
45 |
that it survives restarts (like the MPD playlist does). The previous
|
| 14 |
situation was that the current playing queue was still active after a
|
46 |
situation was that the current playing queue was still active after a
|
| 15 |
player restart, but no metadata (titles, artists, etc.) was displayed.
|
47 |
player restart, but no metadata (titles, artists, etc.) was displayed.
|
|
|
48 |
|
| 16 |
- Actually advertise on the network when starting up and dying. An
|
49 |
- Actually advertise on the network when starting up and dying. An
|
| 17 |
oversight in previous versions resulted in the fact that *upmpdcli* could
|
50 |
oversight in previous versions resulted in the fact that *upmpdcli* could
|
| 18 |
only be discovered by a search (when the control point started), but,
|
51 |
only be discovered by a search (when the Control Point started), but,
|
| 19 |
when *upmpdcli* was started, it would not appear in a running control point
|
52 |
when *upmpdcli* was started, it would not appear in a running Control Point
|
| 20 |
device list.
|
53 |
device list.
|
|
|
54 |
|
| 21 |
- Do not advertise support for raw PCM strings (audio/Lxx), as we can't
|
55 |
- Do not advertise support for raw PCM strings (audio/Lxx), as we can't
|
| 22 |
actually play them. It is better to give accurate information to the
|
56 |
actually play them. It is better to give accurate information to the
|
| 23 |
control point, so that it can choose an alternate format such as Wav if
|
57 |
Control Point, so that it can choose an alternate format such as Wav if
|
| 24 |
it is available.
|
58 |
it is available.
|