I believe that the old lyrics table structure was more or less a mistake:
TABLE lyrics (
    id INTEGER PRIMARY KEY, -- actually never used in code
    url VARBINARY(324), -- actually a rpath from urls table
    lyrics TEXT
)

Apart from data duplication and non-conformity to the "update anomaly"
requirement of the database design, there was additional problem that rpath
itself is not unique. The (deviceId, rpath) is.

This change makes the lyrics table look more sane:
TABLE lyrics (
    url INTEGER PRIMARY KEY, -- points to url.id column
    lyrics TEXT
)

with an effort to transition existing entries. The transition of 5000
lyrics entries takes 16s on my 2.5 GHz Core i5 (one core used), so it
should be acceptable.

This is the first time I'm changing db structure, I'd be glad to
receive thorough review, namely of the update13to14() method and
especially the duplicate-removing query. This is critical because
database-corrupting fault would leave many Amarok users in a state
where they would need to drop their database to make Amarok working
again.

ChangeLog of the unrelated iPod fix is updated because DB_VERSION bump
triggers full collection rescan as far as it is documented.

BUG: 242350
FIXED-IN: 2.6
REVIEW: 104966