Labels and uniqueid Was: some crash report by Rich

Maximilian Kossick mkossick at
Thu Nov 9 08:46:12 UTC 2006

On Thursday, 9. November 2006 03:47, Alexandre Oliveira wrote:
> The crash is in:
>  for(QMap<QString, QStringList>::ConstIterator it = newLabels.begin();
> it != endLabels; ++it ) {
>         CollectionDB::instance()->setLabels( it.key(),,
> m_playlistItem->uniqueId(), CollectionDB::typeUser );
>     }
> m_playlistItem->uniqueId() is wrong there, as when tagdialog isn't
> called from playlist, m_playlistItem will be null. Also, it'll return
> current item, so if the user uses next or previous and change labels
> for different tracks, all of them would use the same uniqueid on that
> call.
> I could fix it by making newLabels use a QPair with the url and the id
> as key, or by storing the ids in other map, or even by refactoring
> CollectionDB::setLabels() so that it finds the id by itself, but all
> this brought me question:
> Isn't having urls and uniqueids on labels table redundant? We already
> have both on statistics, so when amarok finds out about url changes,
> it could update the url on migrateFile(), like it happens for lyrics
> table.
It is possible to have labels for a file without statistics, so we need the 
uniqueid column in tags_labels. Why do you think that the urls in tags_labels 
are redundant? Updating the url in migrateFile() is a good idea, i'll fix 
that asap.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the Amarok mailing list