#1 tags from collection DB

[Myen]

Would it be possible to add the tags from the collection db by asking amarok over dcop? (Seems like this needs `dcop amarok collection query` though...)

This would be useful when the source hasn't got the (right) tags - for example, due to the length restrictions on ID3 tags.

(Of course, this wouldn't apply when being run standalone)

[Myen]

Logged In: YES
user_id=1622973
Originator: YES

Attaching a proof-of-concept patch

Against transKode 0.5 because I can't seem to get transKode 0.6b2 (without any patching) to work as an amaroK script correctly (it can't find any encoders). Should be isolated enough to be easy to apply, and should fail safely (i.e. have no negative effects when failing) as well. Always prefers amaroK-supplied tags (... might need to add a config for it?)
File Added: fetch.tags.from.collection.db.patch

[Myen]

proof of concept, against transKode 0.5

[Sergio Pistone]

Logged In: YES
user_id=1387170
Originator: NO

Sorry, but I can't implement this without adding ugly hacks to the core (shared between the standalone application and the Amarok script).
As a side note, I don't see any reason why Amarok shouldn't be writing ID3v2 tags (which, AFAIK, don't have this limitation) to mp3 files. If you're sure this is the case, I'd suggest you file a bug at Amarok bug tracker, as this seems the reasonable behavior (at least when the data exceeds the ID3v1 size limit).

[Sergio Pistone]

Logged In: YES
user_id=1387170
Originator: NO

What a dunce I am... That should teach me to read _all messages_ before replaying...
I said in my previous post that I can't implement this _in the core_ without ugly hacks... your patch proves I don't have to, nor I should... Sorry, I should have put more thought on the issue.
I like to point, however, that I still see this as unnecessary (IMHO, Amarok should handle the issue better). I'll verify if the problem exist and fill a bug report if it does (I'll consider your patch for inclusion depending on the answer I get from them).