Bugzilla – Bug 18043
urlmd5 column in tracks table not set properly for new playlists
Last modified: 2013-06-24 09:52:21 UTC
The urlmd5 column isn't set properly for playlists created via LMS web interface. When creating new playlists from the LMS web interface the playlist entry in the tracks table always gets the same urlmd5 value. The result is that the urlmd5 column can't be used for joining. The problem is corrected automatically after a full rescan is performed. A playlist rescan or new/changed rescan is not enough, a full rescan is required.
What do you mean by "gets the same urlmd5 value"? If it's supposed to be the playlist's urlmd5 value, then that seems correct to me?
The urlmd5 valu(In reply to comment #1) > What do you mean by "gets the same urlmd5 value"? If it's supposed to be the > playlist's urlmd5 value, then that seems correct to me? It's supposed to represent the URL pointing to the playlist file generated but the MD5 is exactly the same independent what I name the playlist. For example, creating a new playlist and naming it "Playlist1" and then creating another playlist and naming that "Playlist2". I then execute this SQL: select id,url,urlmd5,title from tracks where title like 'Playlist%' This results in: 57016 file:///home/erland/Configurations/Playlists/Playlist1.m3u 5ed1a5a77e364a90dde8b744708af119 Playlist1 57017 file:///home/erland/Configurations/Playlists/Playlist2.m3u 5ed1a5a77e364a90dde8b744708af119 Playlist2 As you can see the urlmd5 column is the same even if the URL differs. The expected result would be: 57016 file:///home/erland/Configurations/Playlists/Playlist1.m3u 5eaa80f82a1f2aeafea89576f2e97de5 Playlist1 57017 file:///home/erland/Configurations/Playlists/Playlist2.m3u f444baddfaa2f85f909d8484752fe5e4 Playlist2 This will also be the case after I've performed a full rescan.
The playlist first is saved with a generic name (eg. "No Name"). The urlmd5 hash is calculated based on this name, and not updated when the playlist gets renamed (or saved under a real name). Fixed in 7.7.3