id3, playlists and DB

[Jeff Mitchell]

On Sunday 13 January 2008, Ivan Sergio Borgonovo wrote:
> 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.

Nope.  There's no good alternative.  There's also no good network 
filesystem  :-)

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

taglib wouldn't be recommended.  It'd be required.  Amarok doesn't work 
without taglib, period.  You must have it somehow, somewhere.  Might not be 
in sid.  In which case, knowing Debian (two years behind, full of 
already-fixed bugs), you may want to compile taglib from SVN.  The 1.4 
release is too out-of-date to be considered reliable.

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

But it should work just fine for centralized archives.  After all, the 
information is stored in a shared database; you only need one copy of Amarok 
to update it.

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

Well you'd expect that, because of the shared database.  But they should be 
getting saved in the file.  Are you sure that you have write permissions (not 
just on the filesystem but through NFS too?)  And, of course, update taglib!  
(And get yourself a decent Linux distribution.  Debian's "stability" is 
overrated, and has nothing to do with how stable or bug-free individual 
packages are.)

> So I can't think nfs is involved when I change the genre of 5 files
> and 4 get changed and 1 doesn't...

It could be.  Who knows.

> or well I could understand it if 
> the DB uses the "UIDs" to update files

No.  Database side, it's a simple update statement.  File side, it's taglib 
calls.

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

3ware FTW.  Dell's built-in cards are always crap.

> OK let's starto from 0.

Sure.

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

Of course not.  The playlist isn't refetched from the database when you close 
and open Amarok -- there'd be no way to have all the customizations you may 
or may not have made to it.  When you close Amarok, the current playlist is 
saved -- along with all the metadata information -- to a file.  current.xml 
IIRC.  When you open Amarok, it's loaded back into the playlist.  So it's 
behaving exactly as expected.

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

They are, when you load the playlist from the collection, i.e. from the 
database.  But when you close Amarok and re-open it, it's not being loaded 
from the collection; it's being loaded, along with any changes you may have 
made (what tracks are queued in what order, any stop-after-this-track flags, 
any repeat information, etc.) from the file that was saved.

> I'm not expecting that a client refresh the tags as soon as
> another change it...

Right.

> but deleting and repopulating the playlist is 
> really time consuming

It shouldn't be, especially not in 1.4.8.  How many tracks are we talking 
about?

> and prone to crash/freez

Again, it shouldn't be.

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

As I explained, it isn't  :-)

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

If you are changing them within Amarok, then, yes, they should.

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

Then you did AFT's work for it anyways.

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

It'd be interesting to see how things behaved if you used Samba instead.  
That's what I use, and I haven't seen any of the problems you describe.

> Please don't take it wrong.

Don't worry, we're not.  We tend not to take offense when people have weird, 
wacky isolated problems that no one else has.  We also tend to think it's an 
artifact of their setup, not an artifact of our program  :-)

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

:-)

--Jeff