Version: 2.3.1 (using KDE 4.4.4) OS: Linux If the lyrics for a certain song are edited, these changes are lost when the song file is renamed. One would expect custom lyrics to be associated with the track ID3 information rather than the filename. Reproducible: Always Steps to Reproduce: 1. Edit the lyrics for some song in the collection. 2. Change the name of the song file and update the collection. 3. View the lyrics for the renamed song. Actual Results: The lyrics are fetched anew from the internet, and the custom changes are lost. Expected Results: The lyrics are the same as they were after the original edit. OS: Linux (x86_64) release 2.6.33-ARCH Compiler: gcc
Setup: Amarok 2.3.2 KDE 4.4.5 Test Result: Same thing here. But it does gives an warning that the lyrics will be changed...
Could you please upgrade to a newer Amarok version and test again? Current is Amarok 2.4.0, Amarok 2.4.1 is to be released tomorrow. Please report back.
This still happens with Amarok 4.2.1.
Thank you for the fast feedback.
Setting severity to major as it's a data corruption bug.
(In reply to comment #1) > Same thing here. But it does gives an warning that the lyrics will be changed... Ognyan, can you please paste the exact message (please switch Amarok to US English first) and tell when exactly it pops out? Thanks.
The patch that whould fix this is at https://git.reviewboard.kde.org/r/104966/ Reporters, if you can patch and rebuild Amarok (current git), please test. The patch changes Amarok database structure, so please backup your Amarok database first otherwise you may never be able to go back without losing statistics etc.
Git commit 5bf3f7be1fc27755391a223cbdfa8d2ee297c356 by Matěj Laitl. Committed on 16/05/2012 at 13:36. Pushed by laitl into branch 'master'. DB: change lyrics table: text url -> integer url pointing to the urls table 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. FIXED-IN: 2.6 REVIEW: 104966 M +4 -2 ChangeLog M +2 -4 HACKING/mysql_database_schema.txt M +38 -4 src/core-impl/collections/db/sql/DatabaseUpdater.cpp M +1 -0 src/core-impl/collections/db/sql/DatabaseUpdater.h M +8 -11 src/core-impl/collections/db/sql/SqlMeta.cpp http://commits.kde.org/amarok/5bf3f7be1fc27755391a223cbdfa8d2ee297c356