Bug 265567

I can confirm that. After it happend the first time I closed Amarok and restored
 .kde4/share/apps/amarok
 .kde4/share/config/amarok*
from my backup.

I started Amarok and everything was back in place. I started to play some music and for some minutes everything seemed to be fine. But suddenly the local album list emptied itself and in the playlist all data but title and playing time vanished. The same happed to the details in the middle part of the window.

While all that was happening Amarok continued to play.

If there's anything I can do to help, let me know.

I can confirm this bug, too.

Additional information: It first appeared after upgrade to KDE 4.6 and does not appear when the first run assistant runs after the first startup with a pre KDE 4.6 database. I'm able to reproduce this with a backup.

exactly the same here: after an upgrade to kde 4.6 (Amarok 2.4), I could use it normally for a while. Then -- while playing music -- suddenly all metadata vanished. After restart, my collection was empty. Using "update collection" from the menu didn't bring it back, using "complete rescan" from the settings dialog did, but lost the playing statistics and ratings.

I cannot try to reproduce this, though, because I have no backup of the data :-(

This happend on openSuSE 11.3 using KDE 4.6 and Amarok 2.4 from the new KDE 4.6 build service repository: http://download.opensuse.org/repositories/KDE%3a/Release%3a/46/openSUSE_11.3/

I think this is what happens:

1. User starts Amarok
2. After one minute the scanner checks for collection changes
3. For a unknown reason Amarok detects all directories as modified
4. For a unknown reason Amarok has the bug from 2.4 beta still in it (Mark, your bug) and the scan completes with an empty collection.

We have a fix for the problem, but it would be useful to know exactly which version is in the openSuSE 11.3 and how the debug output looks like when this problem happens.

I just checked the 2.4 version again.
The worst problem (using UIDs with the identifier "file" which trigger a problem with the length restriction in the sql database) is not in 2.4 final.

It's therefore interesting to know it 2.4 beta has gotten into the releases.

I'm seeing what appears to be the same bug on gentoo with amarok-2.4.0
DB empty after upgrading to KDE 4.6. everything was fine before upgrade.

So this might be related to KDE 4.6? Was there something changed in MySQL for that release?

Might be. Can someone provide a debug output.
Especially interesting are any sql errors.

I can provide debug output, but I've no idea what I should look for. I try it anyway.

I think this is the point when Amarok starts to rescan the collection and the fun starts:

amarok: [00;35mBEGIN:[00;39m virtual void ScannerJob::run() 
amarok:   [MySqlStorage] Initialized thread, count== 3 
amarok:   [00;36mBEGIN:[00;39m bool ScannerJob::createScannerProcess(bool) 
amarok:     [ScanManager] starting scanner now: 
amarok:   [00;36mEND__:[00;39m bool ScannerJob::createScannerProcess(bool) [00;36m[Took: 0.007s][00;39m 
amarok:   [00;31mBEGIN:[00;39m void ScannerJob::getScannerOutput() 
amarok:   [00;31mEND__:[00;39m void ScannerJob::getScannerOutput() [00;31m[Took: 0.082s][00;39m 
amarok:   [00;32mBEGIN:[00;39m void ScannerJob::getScannerOutput() 
amarok:   [00;32mEND__:[00;39m void ScannerJob::getScannerOutput() [00;32m[Took: 0s][00;39m 
amarok:   [ScanManager] ScannerJob: got count: 837 
amarok:   [ScanManager] ScannerJob: run: 0 current path "PATH1" 
amarok:   [ScanManager] ScannerJob: run: 1 current path "PATH2" 
amarok:   [00;34mBEGIN:[00;39m void ScannerJob::getScannerOutput() 
amarok:   [00;34mEND__:[00;39m void ScannerJob::getScannerOutput() [00;34m[Took: 0s][00;39m

It continues with lots of those messages:

amarok:   [ScanManager] ScannerJob: run: X current path

[...]

amarok:   [00;32mBEGIN:[00;39m virtual void SqlScanResultProcessor::commit() 
amarok:     [SqlScanResultProcessor] in commit, dir not skipped "PATH"

[...]

amarok:     [SqlRegistry] SqlRegistry::getDirectory new Directory "PATH"

[...]

amarok:     [07;33m[WARNING][00;39m [SqlScanResultProcessor] track "/home/..." with uid "amarok-sqltrackuid://amarok-sqltrackuid://" already committed. There seems to be a duplicate uid. 

[...]

amarok:     [SqlScanResultProcessor] deleteTrack "amarok-sqltrackuid://XYZ" url id 1

[...]

With those messages in between (but I think, those are only albums I added since the backup):

amarok:     [Playlist::Model] Metadata updated for album "NAME"
amarok:     [00;34mBEGIN:[00;39m void StatusBar::updateTotalPlaylistLength()


Now the collection was empty. Then I restarted Amarok and I started a manual scan:

amarok:     [ScanManager] starting scanner now: 
amarok:   [00;31mEND__:[00;39m bool ScannerJob::createScannerProcess(bool) [00;31m[Took: 0.005s][00;39m 
amarok:   [00;32mBEGIN:[00;39m void ScannerJob::getScannerOutput() 
amarok:   [00;32mEND__:[00;39m void ScannerJob::getScannerOutput() [00;32m[Took: 0.078s][00;39m 
amarok:   [00;34mBEGIN:[00;39m void ScannerJob::getScannerOutput() 
amarok:   [00;34mEND__:[00;39m void ScannerJob::getScannerOutput() [00;34m[Took: 0.004s][00;39m 
amarok:   [ScanManager] ScannerJob: got count: 837 
amarok:   [ScanManager] ScannerJob: run: 0 current path "PATH" 
amarok:   [00;35mBEGIN:[00;39m void ScannerJob::getScannerOutput() 
amarok:   [00;35mEND__:[00;39m void ScannerJob::getScannerOutput() [00;35m[Took: 0s][00;39m 

[...]

amarok:   [00;35mBEGIN:[00;39m virtual void SqlScanResultProcessor::commit() 
amarok:     [SqlScanResultProcessor] in commit, dir not skipped "PATH"

[...]

amarok:     [SqlMeta] deleting cached image:  "XYZ" " : ok"

[...]


This is the only "ERROR" appearing in the debug output:

amarok:             [UpnpCollectionFactory] ERROR "The name org.kde.Cagibi was not provided by any .service files" 
amarok:               [ERROR__] Can not parse dynamic.xml 
amarok:               [ERROR__] "unexpected end of file" 
amarok:               [ERROR__] "Line: 1, Column 1"


Hope this helps.


btw: I'm using Arch.

The same here afetr upgrade from amarok 2.3.? (I really don't know) to 2.4.0 with KDE 4.6.0 on Ubuntu 10.10 using kubuntu-ppa-backport PPA.

How can I help?

I also experienced this bug when upgrading from KDE 4.5 to 4.6.

As Kristian hints in Comment #2, using the pre-4.6 collection database but removing amarokrc works.

Could this have something to do with KDE 4.6 using UDisks instead of HAL?

Yes, I think it has something to do with UDisk and HAL.

Because of the change the uuid of the device has changed.
So the old "collection" setting points to a device not longer existing.

Once Amarok checks for changes it will notice the now not longer existing device and remove all the tracks.

Solution for this problem: Go to settings/collection and set the collection location again.
Amarok will do a full rescan but the old statistics should remain (as the track uids are still the same)

Maybe Jeff knows what we can do to prevent this behaviour.

After I was hit by this bug, I tried the approach mentioned in comment #12. I started with a clean amarok configuration, but used a backup of my collection database (external mysql database). Then I set the collection path as it was before and did a full rescan. Unfortunately, playcounts and ratings were empty afterwards.

It does seem like this is an issue triggered by the udisks/hal change. But reports (such as bug 265539) show that AFT is broken in 2.4.0 so I wouldn't expect setting the collection location and rescanning to preserve statistics or labels.

Could this be a case of Amarok being too smart for its own good?  If it simply used the file's path, instead of UDisk or HAL stuff, it wouldn't be an issue at all, would it?  Why should Amarok care about anything besides the file's path?

This reminds me of the "no-duplicates" bug in Amarok 2.  It seems to me that it's a simple case of Amarok trying to be smarter than the user, failing miserably, and frustrating the user to no end.  If, instead, Amarok was made to K.I.S.S., neither of these problems would ever have existed.

For my needs, I would still be completely satisfied with the good ol' reliable Amarok 1.4.  Now we're at 2.4 and Amarok is still wiping out data, not doing what the user wants, and frustrating the user.  Is there an issue of underlying development philosophy that's causing these problems?  I think something needs to change.

Quite sure this is the wrong place to start a topic like this, but I would like to second Adam's thoughts on the matter.

The codebase for amarok 2.4 seems to be inherently overdependent on a whole plethora of external code, which comes with it's own selection of bugs (and which causes things to periodically break as external components get updated).  The database should have been stable as of version 2.0, but mine must have been wiped out dozens of times since then...  While the path from 2.0 to 2.4 has brought many shiny new features, I have not really seen an improvement in stability.

Maybe the focus should change from new features to fixing up what's broken?  Just a thought...

I've hit the same problem. As a temporary measure I created a read-only user in mysql which has successfully prevented Amarok from deleting all of my tracks.

When I get a chance (tonight maybe?) I'm going to try manually updating the devices table to reflect the HAL/Udisk change. I'll report the results here.

I got the same problem when I upgraded to the beta of Kubuntu Natty [1]
The amarok version upgrade was from 2.3.2 to 2.4.0. The UUIDs on my partitions didn't change after the upgrade.

[1] https://bugs.launchpad.net/ubuntu/+source/amarok/+bug/768641

I tried adding a new device for / with the correct UUID and and then set the deviceid for all of the URLs to that device.

It didn't help.

Now I realize that it's only the records in the tracks table are deleted, not the ones from the urls table.  So later when I run a full rescan the tracks are rediscovered, and I still have my stats because they are keyed to the urls.

That's all great, except that the tracks table contains the add date, which I want to keep. So the next thing I'm going to try is to write a script which sets the filesystem dates for each file on the basis of what's in the tracks table in my backup db, and then try again.

Here's a dirty hack which prevents track deletes from the scanner. 

Please do not think that this is a real fix, it's just a quick hack. Fixing it for real will take some time with the debugger for me, or (better?) someone with more experience with the code.


--- amarok-2.4.0.orig/src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp       2011-04-24 20:31:41.755467006 +0200
+++ amarok-2.4.0/src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp    2011-04-24 20:35:54.505467005 +0200
@@ -365,6 +365,7 @@
 SqlScanResultProcessor::removeTrack( int urlId, const QString uid )
 {
     debug() << "deleteTrack" << uid <<"url id"<< urlId;
+    return;
     if( m_collection->registry()->m_uidMap.contains( uid ) )
         static_cast<Meta::SqlTrack*>(const_cast<Meta::Track*>(m_collection->registry()->m_uidMap.value( uid ).data()))->remove();
     else

*** Bug 272061 has been marked as a duplicate of this bug. ***

I reproduced this bug on Gentoo where the kde 4.6 upgrade is on the agenda for stable users. I can confirm that comment #12 does not work.  I also looked at the sql database (which is external in my case).  The statistics table is crowded with entries, but they are not associated to the songs.  It really seems as if all songs got new ids and the old statistics (which are not deleted from the db!) are not visible anymore.

Please see my description in Bug 272061 
It *may* shed some more light into it.

See the following forum posting for info on restoring the Amarok database from a MySQL backup:

http://forum.kde.org/viewtopic.php?f=116&t=94868&p=195086#p195086

I'm wondering if this has already been fixed in 2.4.1 Beta? I upgraded to KDE SC 4.6.1 with 2.4.1 Beta already installed (built against KDE SC 4.4 though) and did not lose anything (as far as I tell anyway).

My bad, sorry, I forgot to close it, since this is not even an Amarok bug but caused by a KDE upgrade and the HAL -> UDEV migration in KDE 4.6. It is solved upstream since quite some time now.

(In reply to comment #26)
> My bad, sorry, I forgot to close it, since this is not even an Amarok bug but
> caused by a KDE upgrade and the HAL -> UDEV migration in KDE 4.6. It is solved
> upstream since quite some time now.

Could you give us a reference bug, commit, or any other information?  What does solved mean?  Install kde-4.6.1 and get your stats back, or is everything lost.  Please, pointers to give to our fellow Gentoo users are highly appreciated.

One is the resolution of bug 258948 which will be in Amarok 2.4.1 to be released in a few days, the other one is the HAL -> UDEV transition of KDE which is achieved in KDE 4.6.1 beta 1 already: http://kde.org/announcements/announce-4.6-beta1.php

(In reply to comment #28)
> One is the resolution of bug 258948 which will be in Amarok 2.4.1 to be
> released in a few days, the other one is the HAL -> UDEV transition of KDE
> which is achieved in KDE 4.6.1 beta 1 already:
> http://kde.org/announcements/announce-4.6-beta1.php

Well to be fair, the HAL -> UDEV transition of KDE does not really solve the problem but cause it. Whoever is still upgrading e.g. from KDE 4.4 to KDE 4.6 will lose the amarok statistics that way...

If everything in the bug report is true, how is this not amarok bug? Amarok uses bad unstable data (UUID) as the key in the database. And you said it was upstream fault. Hmm

I think this is NOT resolved as Andreas points out in comment #29

I am running KDE 4.6.2++ (4.6 branch) and with amarok 2.4.0 the database is fine from a users POV: The stats are there.

WHen you upgrade to amarok 2.4.1 amarok will trash the database in a way that cannot only be caused by HAL -> UDEV migration (e.g. writing uniqueid's to the rpath field overwriting the paths...)

When I updated to Kubuntu 11.04 and got my collection clobbered I was using KDE 4.6.2 and Amarok 2.4.0 (all the packages versions are in Dependencies.txt in my launchpad report)

I can't try to reproduce since I didn't had a backup of Amarok's data. 

I don't know what files should I backup anyway, everything with *amarok* in ~/.kde? Can't Amarok do backups by itself?

If Amarok can't handle a transition in KDE libs without losing user
data, that's a bug in Amarok.

If Amarok loses user data, that's a bug in Amarok.

Anytime data is lost, it's a very serious bug that should be fixed
quickly.  Rebuilding from a database dump is not a valid
workaround--Amarok is not aimed at developers but at general users,
people who can't be expected to manually dump and restore a SQL
database.  Even "power users" or other devs shouldn't be expected to
do this because of an unhandled library upgrade.  When an app shows
that it's not dependable, reliable, and trustworthy, people will lose
trust in it, and will use other apps instead.

I think Amarok should either use simple filesystem paths as UIDs,
relative to the user's homedir, or use hashes of the entire file.
Either one would be more reliable than the current situation.  Hashes
would take a little time, but they'd be robust and reliable, and cope
well with moving files outside of Amarok--they would allow Amarok to
be sure to do The Right Thing.  File sizes and mtimes could also be
compared to see if rehashing a file is necessary with updating a
collection.

The point is for metadata to never, ever be lost, whether due to a
crash, an upgrade, a library API change, a file being moved, or even
file corruption to a limited extent.  So few apps nowadays are written
to be robust, to handle a wide range of situations well, to do The
Right Thing whenever possible, to fail gracefully--many apps even fail
silently!  It's simply poor programming and poor engineering--it just
takes a little more time to write and test robust code, but it seems
like few projects are interested in it.

I don't mean this as an attack on individual developers involved with
Amarok: Bugs like this and the all-too-frequent dismissal or deferment
of them is what's pushing me away from Amarok and toward Clementine.
Amarok 2 still seems like a playground for developers rather than a
serious app, a _product_, one that can be relied upon by all users to
do its job faithfully without losing data or functionality when new
versions come out.  Why does it seem like Amarok 2's new versions are
frequently downgrades rather than upgrades?

Hey, I'm not paying anyone's salary, so the devs can do whatever they
want.  But I had the impression that they wanted to make an
application suitable for everyone's music playing and managing needs.
If that's true, they are missing the mark, and often seem to be not
even aiming at it.

My two cents.  :)

Adam, using hashes of the entire file is not a good solution, as metadata stored within the file changes quite often.  (Users sometimes manually update IDv3 and Vorbis tags, and Amarok itself stores scores and other metadata in the files.)  A hash of the audio data might be more appropriate, as this is less likely to change.  Using the path and filename as the ID is problematic as that is also likely to change; users don't want to see songs (and associated metadata) disappear from their collections just because they renamed their files, or moved them from one directory to another.

People, this discussion is moot, both issues, the AFT and the upstream bug are solved since quite some time.

I can't speak for others but what I am saying is that we will probably have a mass of Gentoo users running into this 'long fixed issue' because there is no upgrade path kde 4.4 -> 4.6 (without installing 4.5) which preserves your amarok statistics.  We will send all of our Gentoo stable users down that road, they will lose their statistics, and start complaining with us and with you.  What you are saying is 'there is no problem', go away, and that's what the people will do, sorry.

Myriam, it would help a lot if you explained if there was a HAL->UDEV transition problem (e.g. HAL uuids became invalid) in the first place. Or it was just a coincidence and the real issues were those two problems you mentioned in comment #36.

I upgraded to amarok 2.4.1 Beta 1 on 2011-03-20 (built against KDE SC 4.4). I upgraded from KDE SC 4.4.5 to 4.6.1 on 2011-03-30 while keeping the same amarok binary and I have NOT lost any bit of statistics. So the question is if I was lucky or I was not supposed to lose anything? This bug (or actually the bunch of bugs-in-one) just needs more clarification to lower the heat and concern.

Like Gentoo, Debian will be upgrading from 4.4.5 to >= 4.6.3 so I'm still care about this problem.

"People, this discussion is moot, both issues, the AFT and the upstream bug are
solved since quite some time."

Sticking one's head in the sand doesn't help the people who will lose
data upon upgrading.  It doesn't help Amarok avoid frustrating people
who will stop trusting Amarok and stop using it.  It doesn't help the
damage Amarok's reputation will suffer.

Most significantly, it doesn't help the "who cares about the users,
we're just playing with the codebase, throwing in new features and
ripping out chunks of them at will" attitude that *seems* to permeate
Amarok 2.x's development as a whole.

Other apps, like Clementine and Bangarang are looking better all the
time.  For example, the primary Bangarang developer describes his
interest as being in "creating and releasing a Bangarang 2.0 that I
can genuinely be proud of.  I’m not interested in beating everyone
else to punch with features. That’s not why I created Bangarang.  My
aspirations were to create a pleasant, carefully crafted media player
that does what it does well."

That *seems* so different than the approach and goals of Amarok 2.x.
Maybe that's not what the devs are really after, but that's the
impression they are giving off.

Well, since I've found some alternatives, maybe I should just be quiet
and go away.  :)  I do still care about Amarok, though, because it has
a lot of potential, and Amarok 1.x was so good.

On Sun, May 8, 2011 at 02:12, Myriam Schweingruber <myriam@kde.org> wrote:
> https://bugs.kde.org/show_bug.cgi?id=265567
>
>
> Myriam Schweingruber <myriam@kde.org> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|RESOLVED                    |CLOSED
>
>
>
>
> --- Comment #36 from Myriam Schweingruber <myriam kde org>  2011-05-08 09:12:28 ---
> People, this discussion is moot, both issues, the AFT and the upstream bug are
> solved since quite some time.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

It surprises me how people think that Amarok 1 development model was not any different. You know people kept losing database too, Amarok 1 kept missing some files (or not finish scanning DB), it was slow and it could crash in various weird ways under normal usage. However, back then SQLite (upstream) was blamed for that even if a couple of DB indices were missing to speed things up. But Firefox, Android and other big software names were able to utilize SQlite perfectly and preserve people data for years and after numerous (major) upgrades. Now when Amarok 2 switched to MySQL, some other abstract "upstream" is being blamed for the same issues. So generally you might prise Bangarang (not that I know anything about it) but don't give Amarok 1 too much credit in this area. It would not be fair.

P.S. I know that I'm sorta trolling in this bug report. But that's how Amarok development looked and still looks to me from the "outside" while still having to deal with complaints of frustrated users (not that I can help them :/).

That's interesting.  Thanks, Modestas.  I do appreciate a lot of
things about Amarok 1, but I guess the lens of nostalgia tints
everything rosy.

Isn't it great when software really does prioritize safety and
reliability above all else?  We can hope, at least....

On Thu, May 19, 2011 at 01:56, Modestas Vainius <modestas@vainius.eu> wrote:
> https://bugs.kde.org/show_bug.cgi?id=265567
>
>
>
>
>
> --- Comment #40 from Modestas Vainius <modestas vainius eu>  2011-05-19 08:55:55 ---
> It surprises me how people think that Amarok 1 development model was not any
> different. You know people kept losing database too, Amarok 1 kept missing some
> files (or not finish scanning DB), it was slow and it could crash in various
> weird ways under normal usage. However, back then SQLite (upstream) was blamed
> for that even if a couple of DB indices were missing to speed things up. But
> Firefox, Android and other big software names were able to utilize SQlite
> perfectly and preserve people data for years and after numerous (major)
> upgrades. Now when Amarok 2 switched to MySQL, some other abstract "upstream"
> is being blamed for the same issues. So generally you might prise Bangarang
> (not that I know anything about it) but don't give Amarok 1 too much credit in
> this area. It would not be fair.
>
> P.S. I know that I'm sorta trolling in this bug report. But that's how Amarok
> development looked and still looks to me from the "outside" while still having
> to deal with complaints of frustrated users (not that I can help them :/).
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

I have exactly the same problem with amarok 2.4.3 on openSUSE 12.1. This occurred twice already: 
1. Start amarok.
2. As the playlist progresses, song titles and statistics slowly disappear.
3. The collection becomes empty.

After restarting amarok, I observe that lyrics, ratings and playlists are gone. Thankfully, the backup I did a week ago works fine.

Should I file a new bug report? The symptoms are the same.

This stil occurs with amarok 2.5.0. I have gentoo and ubuntu installed on the same PC. Everytime I switch from gentoo to ubuntu or vice versa, the collection is lost and need to be fully scanned again.
With gentoo, the device id is set to -1 and this one is not present in the devices table. With ubuntu, it then complains that device is not in the database and deletes all tracks.
If I start form a blank database with gentoo, the deviceid is correct and present in the devices table. But switching to gentoo also destroys the database because it can't find the device.
Can somebody explain how to avoid such so strange behaviour ?
Thanks for your help.

François: Amarok 2.5 is heavily outdated, we released Amarok 2.6 in August and are about to release Amarok 2.7 in a few days. There have been a lot of changes in the database handling since, you really should upgrade and try again.

(In reply to comment #45)
> François: Amarok 2.5 is heavily outdated, we released Amarok 2.6 in August
> and are about to release Amarok 2.7 in a few days. 

To be fair, this does not make the upgrade path 2.4 -> "anything later" unbroken. I know several who lost their several year old databases and consequently stopped using amarok. If one doesn't care about the content of the database (like ratings and playcounts), then upgrading both installations to something beyond 2.5. should do it.

How about actually saving your database and trying out 2.6? As I said, there have been many changes since 2.4.x in the database handling, if you don't even try we will never know if it works, we don't have such old databases lying around.

(In reply to comment #44)
> This stil occurs with amarok 2.5.0. I have gentoo and ubuntu installed on
> the same PC. Everytime I switch from gentoo to ubuntu or vice versa, the
> collection is lost and need to be fully scanned again.

Please note that sharing a single Amarok database across multiple different hosts (in your case different Linux distros) is not supporter. At least not in combination with the Dynamic Collection feature turned on (by default), see bug 273046.

(In reply to comment #46)
> > François: Amarok 2.5 is heavily outdated, we released Amarok 2.6 in August
> > and are about to release Amarok 2.7 in a few days.
> 
> To be fair, this does not make the upgrade path 2.4 -> "anything later" unbroken.

It does. All Amarok 2.x versions support upgrade path from earlier 2.y versions, so loading your (not corrupted) 2.4.3 database in 2.6 or 2.7 Beta is fine and prevents any data-loss bugs.

> Can somebody explain how to avoid such so strange behaviour ?

Are you using the same Solid backend on both distributions? There are at least 3 backends you may be using: HAL, udisks 1 and udisks 2. They all behave differently and probably all produce different device IDs for the same storage device.

The version of udisks is the same on gentoo and ubuntu but the version of solid is newer in gentoo (4.9.3) than in ubuntu (4.8.5). What I still don't understand is that in gentoo, the same version of amarok set the device field in the urls table to -1 while is set to a positive value in ubuntu which is also present in the devices table. This is why amarok in ubuntu thinks al tracks have disappeared and are thus removed from the database.

(In reply to comment #50)
> The version of udisks is the same on gentoo and ubuntu but the version of
> solid is newer in gentoo (4.9.3) than in ubuntu (4.8.5).

François,
again, sharing a single Amarok database for multiple hosts is not officially supported.

It could work if you disable dynamic collection on all hosts. [1]

[1] http://community.kde.org/Amarok/Development/Dynamic_Collection

> What I still don't
> understand is that in gentoo, the same version of amarok set the device
> field in the urls table to -1 while is set to a positive value in ubuntu
> which is also present in the devices table. This is why amarok in ubuntu
> thinks al tracks have disappeared and are thus removed from the database.

This could be because dynamic collection is disabled on Gentoo and enabled on Ubuntu. Amarok assigns -1 as device id to all tracks urls when dynamic collection is turned off. And Again, changing device ids in devices table don't lead to data-loss bugs with Amarok 2.6 or 2.7 Beta, just hit Update Collection. (the track counter in Local Collection tab maybe off, but this is a display bug)