Pastim writes

I’ve just noticed that when playing a track whose title includes a sharp or flat, the text in the right panel and the playlist panel are correct, but the now playing track title (above the playlist) doesn’t show the characters properly in either the main (full) title or the basic track title in small characters below that. I’m running a self-build from the git on 9/12/2014.

The Now Playing track full title shows as (the year etc are added by minimserver):

09:4 - Impromptu No.4 in AÃ Op.90 No.4 D.899 (1983) [80] [16/44100]

but should be:

09:4 - Impromptu No.4 in A♭ Op.90 No.4 D.899 1983) [80] [16/44100]

Pastim writes

Now this is weird. I thought I had better update all my builds, so have done mpd, libupnpp, upmpdcli, and upplay. Playing the same track on my upmpdcli local player, the title is OK. It’s when I play the track on my Musical Fidelity M1 CLiC that I get the corrupted now playing title.

medoc92 writes

Hi,

In upplay, I think that the "now playing" data always comes from the player. So I’ll have to guess that the Musical Fidelity device is corrupting the string. This is quite difficult to confirm, because other control points might work differently, by displaying local data when possible, but you might give it a try with bubble or kinsky anyway.

Pastim writes

bubbleupnp on android display OK but it may use local data - I don’t know. I avoid kinsky, and windows, whenever I can (kinsky is just weird, unintuitive and …..).

The text is OK on the MF display (albeit with an extra space).

I’ve now just run upplay on my desktop instead of my laptop, same track, same renderer, and the text is OK. This is even stranger. I shall do more tests later. It may be something to do with the font used for now playing on my laptop.

Pastim writes

I ran some more tests from my ubuntu 14.04 desktop, and xubuntu 14.04 laptop, all using the same UPnP server on a separate system. On my desktop everything is fine. It is also OK on bubbleupnp on android.

On the laptop, when I first start to play a track with a ♭ in it the now playing title is fine. It then very quickly refreshes such that the main title (with minimserver additions such as track, year etc) and the plain title in small characters below, get corrupted. This does not happen on my desktop. Odd.

The display on the MF M1 CLiC is the same in all cases, and is OK apart from a leading space.

Is there a reason for changing the display shortly after a track starts playing?

medoc92 writes

in UPnP AVTransport mode, I think that the data displayed in the "playing" area initially comes from local metadata, and is replaced by device data when the device reports that it is playing the new track.

I wonder if upplay might be using different fonts in ubuntu and xubuntu. I must have an ubuntu desktop around, I’ll give it a try. I’d like to try with your actual track. Could you please put it somewhere I can download it ?

Pastim writes

I’ve sent you an email with a dropbox address.

medoc92 writes

Thanks for sending this. Can’t make it fail either with ubuntu or xubuntu, but this is with upmpdcli, and the code path which receives metadata from the renderer is never used.

I have added traces to the upplay code on github, which should show any data which is sent by the renderer. If you could build from it when you have a moment, and execute upplay like upplay > /tmp/trace 2 >&1 maybe we’ll be able to see something in the trace data.

Pastim writes

Will do, possibly this evening. Can I turn trace off later, or do I just need to send it to /dev/null?

medoc92 writes

Pastim writes:

> Will do, possibly this evening. Can I turn trace off later, or do I just need
> to send it to /dev/null?

It’s no big deal, upplay always prints stuff anyway, that’s just a bit more. I’ll probably turn it off later on, but it is not a significant change compared to the precedent behaviour.

Pastim writes

Trace attached. I just played the track briefly. I hope it contains what you need.

Tim

On 22 January 2015 at 17:02, Jean-Francois Dockes notifications@github.com wrote:

> Pastim writes:
>
>  > Will do, possibly this evening. Can I turn trace off later, or do I just
>  > need
>  > to send it to /dev/null?
>
> It's no big deal, upplay always prints stuff anyway, that's just a bit
> more. I'll probably turn it off later on, but it is not a significant
> change compared to the precedent behaviour.
>
> —
> Reply to this email directly or view it on GitHub
> https://github.com/medoc92/upplay/issues/8#issuecomment-71055441.

Pastim writes

I hope the trace reached you in the email I sent (there seems no way to attach things to a comment here). I don’t quite understand the link between the emails and this issues list.

medoc92 writes

Nope, did not get it. Best is probably to just send it to jf@dockes.org. I just need it to cross from the time the title is displayed correctly to when it’s not.

Pastim writes

Got your message - thanks. To conclude it seems this renderer is returning corrupt data for some reason. Most control points do not seem to display the data but upplay does, at least sometimes.

My laptop is on wi-fi and displays the corrupt data. My desktop is wired and does not show the corrupt data. I disabled the firewall briefly on my desktop just to check it wasn’t blocking any return data, and the display remained OK.

Unless you want to pursue this I’ll close off this issue as being a renderer problem, with one question.

Why does the control point bother to change the display using data from the renderer?

medoc92 writes

Well, there is a provision for this in the protocol, so it makes sense to implement it… With UPnP AV, the renderers are not shared, so it’s not really necessary, but the message would still make sense to update a passive "now playing" display. With upmpdcli it makes sense because the current title could be changed by another mpd client (I’d have to check that this actually works though… :) )

Pastim writes

Fair enough. I’ll close this.