Since I switched to using the newest versions from git, I build and install new versions much more frequently. What is the likelihood that one of these times, moving from one development version to another, my database will be incompatible with the new version and I'll lose the data stored there? If the chance is non-zero, is there anything I can do to help protect/preserve the database regardless of upgrades?

(I'm happy to have the option to use an external database, by the way--thanks very much to the developers who worked on that!)

Well, if you are running the development version, I suggest you make a regular backup of your database so you have a fall back version if something should go wrong.
Running a development version also means to be prepared to have stuff breaking, something that tends to happen quite often, especially once a final release is tagged. Don't forget that development == pre-alpha version even if our current git is more alpha like.

That makes sense. Thanks! I'll starting backing it up regularly. So it sounds like the danger, then, comes from bugs rather than changes to the schema that would make an older database incompatible?

Impossible to say, that is surely something you should ask the devs. AFAIK, there is no database scheme changing ahead, at least not in the near future.

In the 2.2 version, most of the database bugs have been corrected anyway, it's more the database queries that are used to display stuff that might go wild every now and then, those still do for the Various Artists for now.

After updating to today's git version, it deleted all tracks from my MySQL database and rescanned my music.

But then it messed up comletely, since obviously only part of my database was deleted: Most songs suddenly had a wrong artist assigned to, and I fear the statistics didn't match, either.
So it seems that there was something messed up with the unique id's of artists/tracks/urls in the database.

What version did you upgrade from? I can't remember you having told that...

I didn't have a forced rescan since the switch from 2.1 to 2.2, which is logical since the database was updated. You were talking about database changes in 2.2-git and I told you there were none inside of that version, and there still are none.

Also, are you talking about the embedded mysqle version or about an external database, available in 2.2-git?

I find it most unlikely that you have a database corruption within 2.2-git, I never heard of but from your description your database seems to be indeed mixed up. No idea how this would have happened...

Could you be a bit more precise of what you did exactly, especially from what version you did upgrade? Rebuilding means just git pull (--rebase if you have a personal local branch) in the source folder and make install in the build folder. I do this as soon as new code changes are made in git master and have never experienced what you describe, nor has it been reported by anyone.

The version I updated from was the git from about a month ago. I use an external MySQL database.
I updated via git pull and make install, then I did a kbuildsycoca4 --noincremental.

Mamarok wrote:I didn't have a forced rescan since the switch from 2.1 to 2.2, which is logical since the database was updated. You were talking about database changes in 2.2-git and I told you there were none inside of that version, and there still are none.

Not that it's a huge deal, but this is someone else you're talking to now. I haven't run into any big problems yet, though I'm sorry this person has.

peppergrower wrote:Not that it's a huge deal, but this is someone else you're talking to now. I haven't run into any big problems yet, though I'm sorry this person has.

Oops, sorry, should have read more closely

fpe wrote:The version I updated from was the git from about a month ago. I use an external MySQL database.
I updated via git pull and make install, then I did a kbuildsycoca4 --noincremental.

AFAIK that last command shouldn't be necessary, it builds the files correctly here after make install.
Also, I don't know much about external databases, AFAIK this was not part of the feature a month ago...

Before the update, the external database was only available by manual editing of ~/.kde4/share/config/amarokrc, like posted on the blog in http://amarok.kde.org/blog/archives/106 ... vered.html
New to this version is the possibility to enable an external database in Amarok's settings menu.
Anyway, my data loss was not that big, in "exchange" for that, I finally was able to re-import my old Amarok 1.4 mySQL database with this new version, since that long-time bug seems to be fixed at last