Bugzilla – Bug 1716
Artist and album names have url style escaping
Last modified: 2008-08-18 10:54:16 UTC
The Windows compiled EXE was doing the same, but I'm now running the Perl version. Using Subversion, I have the latest SlimServer rev 3559. Most artist and album names appear twice in the data and in most browse modes - once without and once with URL style special characters. Items with leading articles are not repeated. The data _is_ in the database, not just the browse views, although the duplicate items are not seen in Browse Music Folder or Browse Years. In Browse Genres the special characters dupes are only seen under 'All Artists' and 'No Genre'.
Are you using Music Magic, MoodLogic or iTunes?
No. In fact, these plugins are disabled.
Could you attach your slimserver.db file to this bug? Do you remember when this behavior started happening?
After the merge. Since the major work in the branch had to do with playlists, let me see what happens if I delete all the m3u files that I have stored in each album directory. They're easily regenerated by a script. I'll post back...
Created attachment 575 [details] Typical m3u That was it. Apparently the problem has to do with the m3u files in the album directories. Both bug #1716 and bug #1717 were cleared up by deleting the m3u's. FWIW, I've attached one.
Ok - that's good to hear, Jim. If you could - what's the logic behind having the m3u's per album? For something other than SlimServer? Obviously I'd like to get this back to the previous behavior, but i need a little background. Should we just be ignoring non-cuesheet playlists inside the audiodir, but not playlistdir? Thanks
> If you could - what's the logic behind having the m3u's per album? For > something other than SlimServer? Yes. I was generating them for album playback with Winamp or other PC-based audio playback software to give me one click ability to queue up an album. > Obviously I'd like to get this back to the previous behavior, but i need a > little background. > > Should we just be ignoring non-cuesheet playlists inside the audiodir, but > not playlistdir? I'm not sure if that's necessary (or desirable). Other than these playlists, I don't use playlists much, so I'm not sure of the problems that might cause other people. The problems seem to stem from incorrectly putting together the paths to the files being referenced by the playlist. I assume that if a playlist references a track already in the database (based on its full path) then it shouldn't be added again. The paths in Bug 1717 show that the full paths to the playlist referenced files aren't be constructed correctly, maybe because of the relative paths used in the m3u files. This bug is seemingly from not reversing the special characters in album and contributor names, apparently happening at the same time those tracks are incorrectly added for the second time. If both of those problems (Windows only?) can be fixed, then there shouldn't be an issue reading playlists in audiodir.
Dan is working on this one for 6.1.
possible fix for 1717 in svn. try next build and see how the results here might change.
note: it seems the use of simple splitdir/catdir would maintain url escaping, while using pathFromFileURL, and fileURLFromPath to wrap them would deal with escaping nicely. change 3662 goes back to the old method, using that wrapper (pre change 3427), so the nightly build should now clear this up.
I believe that's got it. Updated to r3662, recreated all the m3u files within the music directory tree, then did a wipe/rescan. Everything in the database looks good - no URL escaping and no invalid paths (bug 1717). Thanks.
Thanks KDF
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!