[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-multimedia
Subject: Problem with Noatun's tag loading scheme
From: Ismael Orenstein <ismore () ieg ! com ! br>
Date: 2002-03-10 17:32:20
[Download RAW message or body]
Hey there!
I have found a problem with noatun's tag loading scheme. I don't know if it is
a bug or a feature, but I personally doesn't like the current behaviour. The
problem is the following: if I have more than 1 tag loading plugin, Noatun's
library decides which one to load by checking the priority of each plugin
(which is defined by the plugin's creator). First it calls the "update" call
of the plugin of lowest priority. If it returns false, it makes the call on
the next plugin, if it returns false, it makes the call on the next one, etc,
until one of them returns true.
This behaviour looks very nice to me, but it kinda makes some plugin useless.
For example, take a look at the Lucky Tag plugin. This plugin tries to guess
the title and author of a song by analysing it's filename. A lot of mp3
doesn't have a valid id3 tag, but are named like "blur - charmless man". So
it isn't very hard to see that it is the "Charmless Man" music from the
"Blur". This plugin (that is on the kdeaddons directory) automatizes it.
Whenever it's "update" function is called, it tries to guess the author and
title from the filename and calls setProperty to update this information on
the playlist.
The problem is, if I use another Tag Loader, like the "official" Tag Reader
plugin (that gets information from the KFileMetaInfo stuff), the "Lucky Tag"
plugin will never get called, because the "update" call on the Tag Reader
looks like this:
-------
KFileMetaInfo file_info(item.file(),item.mimetype());
// Ack, no file info :(
if ( !file_info.isValid() ) {
return false;
}
/* Do a lot of setProperties and return true */
-------
So, as you see, the Lucky Tag update function will only be called if the
file_info is not valid... and this is very unlikely to happen, as at least
some basic information (like bitrate) can always be guessed from a mp3. Even
if it doesn't have a valid id3 tag for stuff like author or title, the file
info will be valid and I'll have a ugly "blur - charmless man.mp3" file on my
playlist (instead of a nice "[Blur] - Charmless Man").
Besides this obvious problem with the Lucky Tag, it may also be a problem for
any kind of "specialized" tag reader that comes up in the future. For
example, someone may write a plugin that gets the "author" and "title"
property and then searches the net for the "album" name (that's just an
example!). With the current scheme, I can't make it as a tag reader plugin,
as, after any plugin returns true, no more tag readers will be called, even
if the lowest priority one didn't filled all the properties I wanted.
I know this isn't a critical problem (but I really want to get rid of all my
"filename.mp3" items on the playlist!!!!), and I've found some solutions.
Please tell me what you think of them:
1) Change the MetaTag plugin to return false not only if the file info is
invalid, but also if some essential properties like "author" or "title"
couldn't be guessed
2) Compile a list of "important" properties, and keep calling "update" until
all of them are filled. (for example: if my other plugins tell me that they
need the "author", "title", "album" and "bitrate" properties, the lag loader
will call update, from the highest priority's plugin to the lowest priority
one, untill all of them are filled (or we are out of plugins)
3) Change the Lucky Tag plugin to priority -10 and make it always return
false, even when it can correctly guess the filename. (this way, the MetaTag
plugin will overwrite it if found a better info)
4) Change the tag loading scheme to first call the highest priority plugin,
then the next one, etc, until the lowest plugin (in reverse priority), and
make sure that all plugins are called and one can overwrite the other.
This way, Lucky Tag will first try to guess the filename and filll the
"author" and "title" property. Then, the next plugin (usually MetaTag) will
run and, if it has found better values for "author" and "title", it wil
overwrite then. Except for performance problems, this seemed the best
solution for me, and I'm attaching a patch to
noatun/library/noatuntags/tags.cpp that does just that.
Best regards,
--
Ismael Orenstein (UIN 1293061)
ismore@ieg.com.br
http://ksnes9x.sourceforge.net
http://ggz.sourceforge.net
http://linuxgames.com/xrally
["tags.diff" (text/x-diff)]
? tags.diff
Index: tags.cpp
===================================================================
RCS file: /home/kde/kdemultimedia/noatun/library/noatuntags/tags.cpp,v
retrieving revision 1.7
diff -u -r1.7 tags.cpp
--- tags.cpp 2002/01/24 21:11:10 1.7
+++ tags.cpp 2002/03/10 17:06:09
@@ -66,7 +66,6 @@
item.setProperty("Tags::tagged_", "1");
if (item==napp->player()->current())
napp->player()->handleButtons();
- break;
}
}
@@ -84,7 +83,6 @@
{
item.setProperty("Tags::tagged_", "1");
napp->player()->handleButtons();
- break;
}
}
items.remove(item);
@@ -122,13 +120,15 @@
void TagsGetter::sortPriority()
{
- // find the lowest one, since it comes first
+ // find the highest one, since it comes first
+ // It will be the first plugin to be used, however it won't last for long
+ // (a plugin with a lower priority will be able to overwrite it)
- int lowest=0;
+ int highest=0;
for (Tags *i=tags.first(); i; i=tags.next())
{
- if (lowest>i->mPriority)
- lowest=i->mPriority;
+ if (highest<i->mPriority)
+ highest=i->mPriority;
}
QPtrList<Tags> sorted;
@@ -137,7 +137,7 @@
// find the one equal to myself
for (Tags *i=tags.first(); i;)
{
- if (lowest==i->mPriority)
+ if (highest==i->mPriority)
{
sorted.append(i);
tags.removeRef(i);
@@ -148,7 +148,7 @@
i=tags.next();
}
}
- lowest++;
+ highest--;
}
tags=sorted;
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic