Version: svn (using KDE 4.2.0) Compiler: gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) OS: Linux Installed from: Fedora RPMs all examples I have thus far are oggs (I have about 6k oggs, 6k mp3s, 1200flacs) it's always a whole directory of files representing one album (afaict) the files that are missing from the collection will show up in the random playlist when they do they are missing all the metadata, they show just the filename renaming the file causes amarok to show that file in the collection (after "watch folders" notices) making a meaningless (updating the comment for instance) change to the metadata to a file (using easytag or similar) causes the whole album/directory to appear in the collection (after an "update collection"), even if I only changed one file in that directory! touch(ing) the file does not have that effect rescanning after updating the metadata causes the files that previously showed up after updating metadata... to disappear again! the renamed file(s) persist in the collection after a rescan renaming the containing directory causes amarok to show the whole contents (after "watch folders" wakes up and updates the collection)
Can confirm. I've been looking into this myself lately...
This may be obvious from the symptoms but I started poking around in the tables and it's easy to find the "missing" files in the urls table. They point to a row in the tracks table that contains essentially no information. I assume that when I rename the files amarok sees it as a completely new file and populates the database appropriately. It turns out I have 1742 tracks entries where the artist and album are 0 and the title is blank. The entries look like this: +------+------+--------+-------+-------+----------+------+-------+---------+-------------+------------+---------+--------+------------+----------+----------+------+------------+------------+-----------+---------------+-----------+---------------+ | id | url | artist | album | genre | composer | year | title | comment | tracknumber | discnumber | bitrate | length | samplerate | filesize | filetype | bpm | createdate | modifydate | albumgain | albumpeakgain | trackgain | trackpeakgain | +------+------+--------+-------+-------+----------+------+-------+---------+-------------+------------+---------+--------+------------+----------+----------+------+------------+------------+-----------+---------------+-----------+---------------+ | 7909 | 7796 | 0 | 0 | 0 | 0 | 0 | | | 0 | 0 | 128 | 174 | 44100 | 0 | 0 | 0 | 1235083375 | 1222370421 | NULL | NULL | NULL | NULL | +------+------+--------+-------+-------+----------+------+-------+---------+-------------+------------+---------+--------+------------+----------+----------+------+------------+------------+-----------+---------------+-----------+---------------+ Formerly I thought this only affect oggs and whole directories of them at that but looking at the database there are also flacs and mp3s with no metadata and it isn't always a whole directory.
Since it could be useful to others, coping music files from 'musicfolder' (not by Ctrl+A, but using Shift) to 'musicfolder2', removing 'musicfolder' and renaming 'musicfolder2' as 'musicfolder' solved this problem for me.
I can fix one directory at a time by opening the database with the mysqld daemon and using the mysql client to update the changedate for a directory to 10. (Would other values work, probably.) When mysql starts up the next time it updates the collection and the metadata gets populated correctly in the tracks table. This (very slow, I don't know if there is a more efficient method) query returns all the affected directories on my system: select id,dir from directories where id IN (select distinct directories.id from tracks,urls,directories where artist=0 and album=0 and tracks.url=urls.id and urls.directory=directories.id) order by id; I thought I could fix it with something like: update directories set changedate=10 where id IN (select distinct directories.id from tracks,urls,directories where artist=0 and album=0 and tracks.url=urls.id and urls.directory=directories.id); but I get a mysql error. I can easily write a script to get the list of directories ids one by one and update each in turn which I will probably do.
*** This bug has been marked as a duplicate of bug 171418 ***
I do not believe this bug is related to the one it was marked as a duplicate of. Perhaps my description was unclear. My dynamic playlist shows files that are in my collection, but do not have metadata in the tracks table so they show up without metadata in the dynamic playlist.
This bug continues to bite me with SVN from yesterday. Tracks are continuously losing their metadata and I have to use one of the above mentioned tricks to get amarok to put the track metadata back into the database. It seems like I'm doing something wrong... or why else aren't many others noticing this?
This happens to me as well. Amarok will spontaneously lose most of the metadata in the tracks-table for a file, rendering it invisible. These columns are NOT affected: id, url, bitrate, length, samplerate, createdate and modifydate. Every other column gets set to 0/null, although since I don't use replay gain the gain columns are probably always 0. I just checked and I currently have 14 affected files. I have been unable to notice any particular trigger for this; yesterday one of the tracks in my short dynamic playlist got reset while amarok was stopped and hidden. No files had been modified when it happened.
This was a known bug for earlier version, it should be solved in version 2.1.1 Also there has been a lot of work done in 2.2-git, so this is certainly fixed.