Playlists with radio stream urls are getting mangled after restarting foobar2000 twice. It doesn't matter if I manually add the urls to a playlist or import them.
To test, I've imported pls, m3u8, fpl with the same results on a fresh portable install and manually added the urls to new playlists with the same results. I have also manually added urls, exported the playlists as .fpl, removed the playlist, restarted foobar, imported the new .fpl files with the same results
On initial import of .pls, the metadata titles show properly. After the first restart the stream titles only list as the mountpoint from the url. After the second restart, the urls are all wrong, usually being the last set of urls from the last imported file. I can not be positive but I think it has been since playlists-v1.4. I know I've had the issue for at least a few months but never got around to checking into it. I can definitely rule out any 3rd party components since it happens on a fresh portable install with no additional components. It also seems imported older .fpl files with streams store properly.
I've attached a folder of playlists for testing purposes. I have a whole repository here if you need more: https://github.com/CultofRobots/playlists. Import the files, restart foobar twice and the urls should be mangled.
This is on Win 7 SP1
It's an interesting find, but it's not URLs that are being mangled, it's their shown metadata. The radio stations in your playlists are still playable after the presumed mangling occurs. If the URLs were somehow mangled, they would no longer play.
Please correct me if the above is wrong.
Anyway, thanks for reporting, bug fixed for the next update.
It's an interesting find, but it's not URLs that are being mangled, it's their shown metadata
No. It's not just the metadata. It's the wrong url. The actual urls in the playlists are being replaced.
For example, if I import all 10 playlists from the SomaFM folder I attached, after the second restart, every playlist will have the url's for Underground 80s.pls which is the last imported playlist. Every one. So yeah, They'll play... but they're playing the wrong url. This has been the case for 90+ stream playlists.
Neither Peter nor I could replicate url mangling. Perhaps you have some component causing it.
Thought of that before the OP which is why I tried it with a fresh portable install of the latest stable release with no additional components added in. Also thought it could be an issue with the pls files so doubledchecked and reformatted all of them. If it was just the metadata I wouldn't care. That's easy enough to deal with, but I've got 10 different playlists all showing the same 4 urls after the second restart of foobar (when they should all be sets of 4 different urls). And that's the other weird thing... it doesn't mess up on the first restart. It's always after the second restart.
I thought it might be an issue with punctuation in the title fields of the pls but it happens when importing m3u with nothing but urls.
Also note, I'm importing these through the file menu as individual playlists and not just loading everything into a single playlist. I imagine if I load everything into a single playlist the urls will be fine. Haven't thought to try that yet.
If I make a few new playlists, drag and drop a bunch of .pls (10 or so) into the playlists and restart twice, everything is fine. This is only happening when I'm going through File > Load Playlist.
Managed to see something weird happening with that method. I don't think I have ever used the load playlist command before, I always drag stuff.
Cool. I'll assume it'll be fixed when it's fixed and I'll just work around it for now. Thanks.
Fixed for the next update, thanks for reporting.
Indeed the URLs would change when each of the playlists is loaded into a separate fb2k playlist, and metadata from all of them disappears. The reason was that fb2k incorrectly decided that the playlists were identical and saved them as one file. Version 1.4.3 will address this.
Also having them all in one fb2k playlist prevents this for now.
Thanks Peter & Case. I appreciate you both looking into it. I'll work around it until the update is released.
Fixed in 1.4.3 beta 1.
Wonderful. I'll try it later today. Thanks again.