Ocorre que um dia resolvi testar meu favorito tocador de música digital usando a base de dados MySQL, é padrão do Amarok usar a base de dados SQLite, pois é claro, ela não necessita de ajustes do usuário e é salva em um arquivo .DB dentro do diretório de configuração do aplicativo, sendo fácil de trabalhar e manipular.

No entanto as consultas feitas nela levam muito mais tempo que numa base de dados MySQL ou PostgreSQL. Para quem só quer ouvir música e não se importa com o desempenho o SQLite é perfeito, mas este não é meu caso. Usei Slackware Linux por quatro anos em meu Desktop e tudo que eu fazia era compilar, compilar e compilar, sempre tentando extrair o máximo de performance do meu hardware. Se é também seu caso, vamos para o passo-a-passo.

Abra seu editor de textos favorito e um terminal, no terminal vá até o diretório:

cd ~/.kde/share/apps/amarok

Se você listar os arquivos deste diretório verá uma estrutura semelhante à esta: Veja que marquei um arquivo chamado collection.db, é nele que ficam os dados que precisamos pegar, então faremos da seguinte forma: separaremos os dados da estrutura do banco de dados e em seguida enviaremos isto por um pipe (|) para o MySQL. Parece difícil, mas é muito simples.

O banco de dados "amarok"

Execute seu MySQL em um terminal, crie um banco de dados chamado "amarok" e dê ao usuário amarok todas as permissões, como mostrado a seguir:

mysql -p -u root
mysql> CREATE DATABASE amarok;
mysql> USE amarok;
mysql> grant all privileges on base.amarok to [email protected]; Se você abrir o Amarok agora e informar em Configurações/Coleção que deseja usar como base de dados o MySQL ao invés do SQLite, o Amarok criará uma estrutura semelhante à seguinte, porém faltarão algumas tabelas, e isto pode causar vários erros ao importar os dados do SQLite para o MySQL. A maior parte dos manuais e artigos pela internet dizem para fazer isto, mas vamos seguir outro caminho, vamos extrair a estrutura que está dentro do arquivo ~/.kde/share/apps/amarok/collection.db, desta forma você não corre risco de tentar inserir dados em uma tabela que possivelmente possa não existir.