SMPC loads albums wrongly: doubled tracks, wrong display

[dyraig]

Since version 1.3.25, SMPC shows some strange behaviour when adding albums to the playlist: in some cases, one or more tracks of the album are added twice. Moreover, both tracks are displayed in a strange way in the playlist - for one, the file name is shown instead of the title, for the other, the title is shown, but no album/artist information (see screenshot, position 5/6 in the list - the album had just been added to an empty playlist). If I check the playlist with another client (I typically use gmpc on a Linux machine), I can see that the track in question has indeed been added twice, but no other side effects. Also, if I add the same album using gmpc on the same server, it just gets added normally, and shows up normally in SMPC, too.

In addition, when "extra tracks" are present in the playlist, SMPC gets confused with the track count - the "extra" tracks are apparently not counted correctly, which leads to SMPC showing the wrong track as current track (see screenshot - position 83 is shown as current track, but position 86 is actually playing, i.e. there are several "extra" tracks further up in the list).

I have also seen that tracks are already displayed wrongly when simply going to Artists -> album (i.e. without actually adding the album):

I have not yet been able to establish an actual pattern related to the albums/files themselves, but the behaviour seems consistent, i.e. if an album is affected, it is always affected.

Additional information:

• Behaviour observed in 1.3.25, 1.3.26 and 1.3.27. 1.3.24 seems to work normally (I've actually tried all of them yesterday)
• Phone: Xperia X with SailfishOS 4.1.0.24
• MPD: tried with mpd 0.23.4 on Arch Linux and mpd 0.21.4 on Raspbian (both are using the same underlying music files)

If you need any additional information, please let me know.

[a-dekker]

I noticed at least a part of this also. Thanks for your extended testing, I guess some debugging needs to be done.

[dyraig]

Thank you! I did some more experimenting myself, as I was curious whether I could detect any pattern in when this happens. Here's what I have so far:

• I've seen it with both ogg and flac (don't have that many mp3)
• I then had a closer look at the tags that the files have, but unfortunately, that did not help much - I found two albums (those in the screenshots above) where the wrongly added track did indeed have a difference in tags (e.g. had lyrics where the other files did not) - but I also found an album where that was not the case with the wrongly added track. So, apparently, it's not as easy as that. If I find anything else, I'll let you know.

[dyraig]

* I've seen it with both ogg and flac (don't have that many mp3)

Yup, happens for mp3 as well.

[a-dekker]

Can you get a consistent result? After quite some attempts I managed to get a situation like in your first screenshot, but adding it afterwards a few times and the problem did no longer occur. This way it looks more like some random timing issue problem.

When it happens, it seems to always happen on the same point in the album. At least some consistency. Btw it is not just happening when you add it to the playlist. It can also happen when you just select an album.

[dyraig]

I tried a few more things - I have one album where it happens very often, but you are right, there is some variation. What I also saw: the second part (i.e. where the listing is already wrong when simply looking at the album, without adding/playing it) seems very consistent, i.e. an album where I see that effect I always see it.

[dyraig]

I just noticed something else: there are some cases where an album gets added normally to e.g. an empty playlist, then, when I add another album, the list of titles of the first one in the playlist changes in the same way as in the first screenshot - only difference is that the file in question of course does not get added twice. So, I think you're right, there must be some timing issue involved.

[a-dekker]

The issue is caused by https://github.com/a-dekker/smpc/pull/42 I recompiled with the networkaccess.cpp from before this pull request (which is indeed version 1.3.24 and works also fine here), and the issue is gone.

@sh6668 could you have a look at this? I might have to revoke your PR if this does not get fixed.

[sh6668]

Hi A few days ago i noticed this issue too. sometimes mTCPSocket->canReadLine() returns false before the end of mpd file listings - slow networking;-( I hope i get it fixed within this year

[a-dekker]

I found the same. https://github.com/a-dekker/smpc/blob/master/src/mpd/networkaccess.cpp#L1742 gets an incorrect "true". It does not happen in the old situation, where canReadLine is only called as the main loop (while (Q_LIKELY(mTCPSocket->canReadLine())))

[sh6668]

Hi using the mpd respond "OK" instead of canreadline and go back to the old main loop should do it. I will test it and create a pull request.

[a-dekker]

Should be fixed by https://github.com/a-dekker/smpc/pull/45

[a-dekker]

@dyraig could you test the newly released v1.3.27.2?

[dyraig]

Just tried it with a couple of the "usual suspects" albums. I was no longer able to reproduce the errors, neither in the playlist, nor in the album display. Looks fixed to me!

@a-dekker @sh6668 Thank you both for investigating and fixing this and a happy and healthy 2022 to you!

[a-dekker]

Same to both of you, will close this issue now!