Bug 242350 - Manually-edited lyrics are lost when a song file is renamed
Summary: Manually-edited lyrics are lost when a song file is renamed
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Unclassified
Component: Context View/Lyrics (show other bugs)
Version: 2.5-git
Platform: Archlinux Packages Linux
: NOR major (vote)
Target Milestone: 2.6
Assignee: Amarok Developers
URL:
Keywords: release_blocker
Depends on:
Blocks:
 
Reported: 2010-06-21 13:13 UTC by James Dent
Modified: 2012-05-26 12:34 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.6


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Dent 2010-06-21 13:13:54 UTC
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
Comment 1 Ognyan Angelov 2010-12-04 13:57:46 UTC
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...
Comment 2 Myriam Schweingruber 2011-05-07 11:30:50 UTC
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.
Comment 3 James Dent 2011-05-09 05:42:52 UTC
This still happens with Amarok 4.2.1.
Comment 4 Myriam Schweingruber 2011-05-10 03:27:16 UTC
Thank you for the fast feedback.
Comment 5 Sven Krohlas 2011-06-26 14:08:23 UTC
Setting severity to major as it's a data corruption bug.
Comment 6 Matěj Laitl 2012-05-12 15:27:13 UTC
(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.
Comment 7 Matěj Laitl 2012-05-16 13:53:20 UTC
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.
Comment 8 Matěj Laitl 2012-05-26 12:34:02 UTC
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