Issue 32

I’m not sure if this is a problem, or a feature of some setting on my system.

If I play a longish m3u8 playlist (current one is 212 tracks) from minimserver, on my laptop local upmpdcli it often (maybe always - not sure) comes out in reverse track order, On my real UPnP players it’s OK, as it seems to be if I pick a upmpdcli on another computer on my network, all runing the same upplay 1.3.0 on the same laptop.

The list of tracks shown in the right panel is always in the correct order.

What can be causing this? Some feature of my local upmpdcli?

This is weird… As far as I know upmpdcli never reorders tracks. Maybe MPD is doing it, but I really can’t see how it could be instructed to revert the tracks. If you want to investigate this, one thing to do would be to look at the upmpdcli log during the insert operation to see in what order the tracks are sent to MPD. Like this we’ll know on what side on this boundary the thing happens…

I may not have made myself clear - the playlist in upplay is in shown reverse order. Can the renderer (upmpdcli) do that?

I am not necessarily saying that this is the case here, but, yes, upplay displays the state of the playlist on the renderer (it could be changed by another control point). I’m not even sure that any local update of the playlist takes place, but anyway, as soon as the playlist is altered on the renderer, it is displayed altered on the CP, so knowing in what order the tracks are actually sent is important, because it tells us on what half of the system we have to inquire further.

I attach an extract of a upmpdcli log. I don’t understand it, but can say that the last item mentioned in the log should indeed be the last, but is showing on the upplay left window playlist as the first item.

[sampleupmpdcli.txt](https://github.com/medoc92/upplay/files/114201/sampleupmpdcli.txt)

Yes, I do see something weird (each track are inserted at position 0, so the list is reverted), but I can’t see why this would happen (will look closer tomorrow). I see that upplay is 1.3.0. What are the software versions for upmpdcli and mpd ?

I build them from git, and it’s not always easy to be 100% sure the versions are. As far as I can tell all my systems are on the same versions, but only the laptop one gets reversed order. Mystifying.

If you can give me a definitive way of telling what versions things really are I’d be grateful. upplay says 1.3.0 on the screen, but I don’t know where that comes from.

All were pulled and built on 6/1/2016.

The upplay changelog says 1.2.2-1 The upmpdcli changelog says 0.13.1-1 . The mpd NEWS file says 0.20.

I can’t reproduce this. The problem seems to be that mpd returns 0 as the id of each track inserted, so that the next insert, which normally would be after the returned value, is done after 0, so at the start of the playlist, which gets reverted.

I have no idea how this happens. The weirdest part is that it would only happen for a playlist, it should be the same with all multiple track insert operations.

My best guess at this point would be a problem in one of the git versions, and I think that there is a good chance that using the released versions could clear the problem.

Thanks for trying. I’ll do some reinstallation at some point. It’s odd, since I’m running the same versions on other PCs (as far as I can tell). I can’t quite recall why I went to the latest mpd, but there was a good reason at the time!

Can you help me with how to identify your own software versions?

Apologies if I misled you. I don’t think I said any set of tracks was in the normal order on this particular renderer, but if I did, I was wrong! All sets of tracks seem to be reversed, but only on this laptop upmpdcli/mpd.

I removed mpd 20 and installed mpd 19-1 (the standard ubuntu release) with the standard mpd.conf (except commenting out the local music database and enabling pulseaudio). I still get reversed playlists on this system. Strange.

Pastim writes:

The thing is, I don’t actually understand what is happening, but as one of the suspects with git code would be a temporary issue, it would be inefficient to try harder.

If you build from git code, the only approach is to take a note of the branch and latest commit

Maybe there is a simpler git way to print this out, but it should do.

The current upmpdcli code prints detailed version information with -v, but it is only valid for released versions, not git ones (I could try harder…)

Pastim writes:

Ok, this makes things at least consistant (I still don’t know what’s going on).

Then it looks like an upmpdcli issue, maybe try to update it, or run the release version.

I updated and built libpnpp, upmpdcli and upplay. All is now OK - so I’ll close this issue.

I probably mucked something up, or picked up some versions in-between changes - I happily take the hit for being on the latest unreleased versions :)