Bug 198 - Playlists with title information overrides ID3 tags. Make this optional.
: Playlists with title information overrides ID3 tags. Make this optional.
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Playlists
: unspecified
: All All
: P2 normal (vote)
: ---
Assigned To: KDF
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-24 16:43 UTC by Blackketter Dean
Modified: 2008-09-15 14:37 UTC (History)
0 users

See Also:
Category: ---


Attachments
only update title if we need to (533 bytes, patch)
2004-11-26 10:32 UTC, KDF
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Blackketter Dean 2004-02-24 16:43:33 UTC
Two albums:

both have full sets of ID3v1.1 and ID3v2.x tags. One album comes up in
the playlists as:

1. "1.Track 1" by Artist from Album
2. "2.Track 2" by Artist from Album
etc

which is what I would expect

while the other displays as:

1."1.Artist-Track 1" by Artist from Album
2."2.Artist-Track 2" by Artist from Album

I've seen this behaviour in both the web interface and the squeezebox
display. MP3 Tag Database is set to Don't Cache.

I can't see an obvious reason as to why this may be happening. A restart of the
server appeared to cure the problem, but it was back by track 2 of a
playlist. It's causing grief beta-testing the new windows audioscrobbler plugin
as it's submitting tracks with the wrong filename. Here's an example of the
plugin output:

Has anyone come across this before, and is did they find a solution? I'm tempted
to just strip out all ID3v1.1 tags but hopefully there's a better way.

There's a composite screenshot of the difference at
http://g.hindsight.it/slim_web_compare.jpg showing the problem in the fishbone
skin if that makes my explanation any clearer...

I was just about to post a question about this.  Based on what I've
been able to determine this is caused by winamp playlists (at least for
me anyway):

slimserver 5.0.1, winXP pro

I have a lot of playlists that I've created with winamp and am accessing
through slimserver.  The problem is, after the playlist is read, the
Title for the song (as pulled from the id3 tag) get replaced by the
#EXTINF line from the playlist.

Maybe an example would help:

If I have a playlist with:
#EXTM3U
#EXTINF:372,The Cars - Let's Go
C:\music\The Cars - Let's Go.mpg

Normally the song info shows
Title: Let's Go
Artist: The Cars

After reading the playlist, song info shows
Title: The Cars - Let's Go
Artist: The Cars

The messed up title also appears in song listings.

-- 
DS

I did some digging around and found Slim/Formats/Parse.pm which looks to
be handling playlist files.
Sub M3U has the following

if ($entry =~ /^#EXTINF:.*?,(.*)$/) {
			$title = $1;	
		}

and further down

if (defined($title)) {
			Slim::Music::Info::setTitle($entry, $title);
			$title = undef;
		}

I'm no perl expert but this seems to be the cause of the problem I've
been having, namely playlist EXTINF names overriding the cached song
titles read from id3 tags.
Since winamp always puts "artist - song title" as the title in the
playlist, I get messed up listings when browsing.

Is there any way this behaviour could be altered or at least made
optional?
Comment 1 KDF 2004-11-26 10:32:50 UTC
Created attachment 209 [details]
only update title if we need to

This patch updates the title from #EXTINF only if its not a local file with a
title already cached.
Comment 2 KDF 2004-11-26 22:35:17 UTC
patched in cvs.  extinf is ignored for files that are already defined.
Comment 3 Chris Owens 2006-06-16 14:40:13 UTC
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.