When saving the playlist, some entries are doubled. Also vice versa, when starting an entry from a saved playlist, it occurs 2 times

[Ulrichgau]

When saving the playlist, some entries are displayed doubled in different mpd clients. 0-a.m3u.txt the first 2 double entries are: http://strm112.1.fm/rockclassics_mobile_mp3 http://strm112.1.fm/crock_mobile_mp3

Also vice versa, when starting this entry from a saved playlist, it occurs 2 times.

• version of forked-daapd 27.4
• platform raspbian buster 10

[ejurgensen]

Yes, I can reproduce this, though for some reason the duplications I get are different. Will look into it.

[ejurgensen]

Scratch that, I actually can't reproduce this. The reason I have duplicates is that there are duplicates in the m3u you shared (why?):

http://85.25.43.55:80/rock_classics.aac
http://91.250.82.237:8004

Do you have (incorrect) duplicates in the web interface (if you navigate via "Playlists")? What if you run sqlite3 /var/cache/forked-daapd/songs3.db and then select count(*) as c,filepath,playlistid from playlistitems group by filepath having c>1;?

[Ulrichgau]

Hello Espen

Sorry, maybe I was just to lazy to shrink the problem to the most simple way: When I call the playlist test1.m3u.txt there are 5 entries in the active playlist in the mpd client. (see screenshot)

Test1.m3u.txt

Now I delete the 2 duplicate entries in the active playlist and I save it to Test2.m3u

Then Test2 looks like in this screenshot:

But the content of Test2.m3u is the same as Test1.m3u. So in my opinion it is just a bug in the generation of the list for the client in some cases. Not for radio paradise but for crock and rockclassics. This behaviour is shown in different mpd clients.

I also tested your suggestion with sqlite3 and got this: select count.txt

(I have no idea what this means :-(, but maybe you have?)

best regards Uli

[ejurgensen]

Sorry, I still have trouble reproducing this. The m3u you attached has 3 entries, and when I test with Cantata it shows the 3 like it should. I also tried saving the playlist, but that didn't seem to produce any duplicates.

If you could help me reproduce it would be great. Provide a m3u that I can add to my library, then tell me exactly which mpd client to use and what to do in it to produce the issue.

Unfortunately the sql I gave you was incorrect - you can try again with select count(*) as c,filepath,playlistid from playlistitems group by filepath,playlistid having c>1;

[Ulrichgau]

I think your system works in a different way. When I look at my playlist Test2.m3u it looks like the picture independent of the used mpd client (m.a.l.p, MPD Remote and also your web interface) your query gives this result: select count.txt Maybe some clarification is helpful: The bug is not that there are double entries, some entries are displayed double in the clients, independent of whether they are shown in the saved playlist or in the active playlist. And you can delete one of the appearances so that it is shown only once. I can offer a teamviewer session to my windows PC which is connected via putty to my raspi if this helps.

[ejurgensen]

As I understand it, the bug consists of the saved playlist having duplicates - so when you view Test2.m3u it has duplicates. To fix this, I of course need to understand what is making owntone sometimes writing entries twice. I'm not up for debugging via Teamviewer, so I still hope you can help with a recipe that I can follow to reproduce.

The SQL reveals that you do indeed have a number of duplicate playlist entries, especially of rockclassics. But I don't know why that is.

[Ulrichgau]

No, the saved playlist do not have duplicates, but duplicates are displayed if you open it via owntone

[ejurgensen]

Ok, if the m3u doesn't have duplicates, but the database + UI has, then the issue is probably occuring when the m3u is being read by owntone. So perhaps this can give the clue I need: Set the log to debug level (in owntone.conf) and then run touch Test2.m3u. This should make owntone rescan the playlist, and perhaps the log output of that scan will show why it is causing duplicates in the database.