id3, playlists and DB

Sun Jan 13 16:44:43 UTC 2008

On Sun, 13 Jan 2008 09:54:48 -0500
Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:

> 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

Not that I've fallen in love with NFS and I'm aware of some
pitfalls... but actually I think it is still one of the most diffused
"nfs" around and a lot of stuff works properly on it and I think
there is no simple alternative to it.

It is like forcing people to use Ferrari in a country where there are
just bumpy roads. It'd be better to have nice roads, but that doesn't
make easier to use Ferraris ;)

> 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.

Do you know the sid package? there is no libtag/taglib in the
"recomanded" in amarok package and the most reasonable candidate are:
libid3tag0 (installed)
libtaglib-ocaml (not installed)
libtaglib2.0-cil (not installed)

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

Yep.

> > 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

While great for "home users" and from a simplicity point of view it
seems it is not the right solution for centralised archives.
Furthermore if people can move files... they can edit tags and the
"write only" archive argument loses a bit of sense.

> 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

I was so proud of having my collection on an enterprise ready DB as
PostgreSQL and :( I can't make concurrent changes without making a
mess ;)

As you've read later... the behaviour is a bit strange anyway.
I don't know how amarok works internally but I'd expect that since
modifications aren't stored (at least in my case) on the file, they
should be stored in the DB... and well mostly they are.
Infact when I eg. change the genre of a bunch of files they are shown
in another client too even if as I checked they aren't saved in the
file.
So I can't think nfs is involved when I change the genre of 5 files
and 4 get changed and 1 doesn't... or well I could understand it if
the DB uses the "UIDs" to update files... but this comes with its
list of problems in a multi-user centralised environment.

> > 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.

It could be NFS related (I'll check) but I wouldn't consider it an
NFS fault even if I've the feeling that switching that box to NFS4
may help, but LSI/Dell were so *kind* to kill support for CERT ATA
RAID and I'm stuck with sarge on that server for a while.

> > 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

Only inside Amarok.

OK let's starto from 0.
Select a collection that is shared over NFS with the same path across
all clients.
Import all collection into a playlist on 2 clients.
Edit a tag on one client.
Completely close both amarok clients.
Open both clients.
The one who edited the tags see the changes.
The one where I just populated the playlist doesn't see the change.

To see the changes on the second client I've to delete the playlist
and import it once more even if I thought that information about
songs were loaded from the DB.

I'm not expecting that a client refresh the tags as soon as
another change it... but deleting and repopulating the playlist is
really time consuming and prone to crash/freez and after all once
opened still the client needs some time to populate the playlist and
I can't understand why it picks old info if they are coming from the
DB.

> 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

never changed tags outside amarok... just changed them on different
clients. I'd expect changes show up as soon as a playlist is
reloaded, not after some black magic.

> 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

I changed one time the location of all files.
I had a symlink in my home... but my home had a different path from
the one of my wife... so I decided a pass the full share path.
I just did update the path/url in all the tables of the DB through
SQL.
With this exception no direct action on files/tags has been taken
outside amarok but still I get the above mentioned behaviours.
Consider that eg. changes don't show off no matter which client I use
and in both clients collection was rescanned, playlist killed and
restored etc...
As up to my knowledge UIDs shouldn't be generated on path.

Please don't take it wrong.

Your work is great and I'm not criticising design choices, it is more
like questioning them to understand how can I overcome my problems.
I know too few about amarok internals to be in a position to
criticise its design and I didn't contribute a single line of code to
criticise the result, I'm perfectly aware of it ;)

thanks

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it