id3, playlists and DB

[Jeff Mitchell]

On Sunday 13 January 2008, Ivan Sergio Borgonovo wrote:
> I'm currently using amarok 1.4.8 (sid) and while I think it is one of
> the best players around with a lot of interesting features etc...
> that makes me even more greedy ;)

It turns out you're not that greedy, because the functionality you want mostly 
already exists...you just don't know it :-)

> I've a centralised postgres DB and an nfs share that I share across
> people/client at home.

NFS can cause problems.  Weird problems.  It's a NFS thing, not an Amarok 
thing.  Just throwing that out there.  I wouldn't be surprised if this is the 
reason for some of your filesystem problems, like tags not getting updated 
and the like.  Also, please make sure the taglib package you're using isn't 
just made from the 1.4 tarball.  There have been a bazillion bug fixes since.  
Ideally, if you're in sid, someone is taking a SVN snapshot regularly...but 
if not, you may want to uninstall taglib and compile it yourself.

You can also use a shared database, but you must make sure that the music 
resides in the same exact location on every share.

> Currently I generally:
> - put new stuff in the collection folder
> - add new stuff to playlist
> - edit "proprieties" eg: genre, artists
>
> a) stuff is hard to relocate
> if I decide that an album/artist have to be moved in a "genre"
> directory, the DB is not updated, and I lose scores and edited "tags"
> I could use the manage file, but that is not always viable if all the
> tags haven't been fixed [1]

Check the Amarok Wiki for "AFT" or "Amarok File Tracking."  It's a nifty 
little feature that, when you move songs, updates the location of scores, 
cached song lyrics, etc, and it's automatically on for every file in your 
collection.  But there are some caveats; for instance, you can not change the 
location of a file and the tags all at once without the collection scanner 
doing at least an incremental scan in between (in some cases more than an 
incremental scan is necessary, on some broken filesystems -- again, this may 
very well be a NFS issue, and doing a touch on your directories may help to 
force it).  So it could be that Amarok *would* pick up the changes, but 
you're changing too much at once.  See the Wiki page for more details as to 
how it works.  It's generally rare that it totally doesn't work for someone; 
if you're having trouble it's likely some outside factor causing it.  Check 
it out, take it slow, make sure incremental updates happen in between, and if 
you're still having trouble let me know.

> b) tags don't get updated in the file, but just in the DB

They should be getting updated.  My guess is it's NFS-related.

> c) if I access the same collection from other workstations it is a
> PITA to see changes to tags.
>   1) delete all entries in playlist
>   2) rescan collection
>   3) add all collection to playlist

If you have a shared database, you shouldn't have to do this.  But I don't 
know the exact process you're using.  i.e. changes to tags made with Amarok, 
or some outside program.  Changes to tags made with Amarok should get 
populated into the shared database, changes outside will require at least an 
incremental rescan -- but note that simply changing files outside of Amarok 
usually isn't enough to trigger an incremental rescan, because it goes by 
mtimes of your collection folders.  Those don't get updated when a file does, 
they get updated when a file is added or removed from that directory.  So 
using touch on a directory is your friend here.  I don't know that the 
playlist entries will get updated with new tags during such a scan -- because 
of AFT they should get updated with the new location of files if that has 
changed if you haven't changed both the tags and location of the file at 
once -- but I believe they'll get updated with the new tags when you attempt 
to play that file.  Either way, a full rescan shouldn't be required.

> when collections are huge it is a very slow process and it is prone
> to freeze/crash

Freezing and crashing is likely either a taglib issue (update to as recent SVN 
as you can) or NFS issue.

--Jeff