Re: [Tracker] Write-back data & default/dummy data

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2009-10-26 at 10:43 +0000, Martyn Russell wrote:
> Hi,
>
> After this mornings meeting, we briefly discussed libstreamanalyser 
> (LSA) and again, this topic of writing data back to files and setting 
> default data where it doesn't exist in the file's metadata was brought up.
>
> So I am bringing this discussion here to get some ideas/feedback so we 
> can extend the meeting on Wednesday to discuss it. Ivan, Mikael, Philip, 
> Jurg and Carlos, I would appreciate any comments you have here especially.
>
> So here is the common problem:
>
> 1. If a file doesn't have ALL the metadata associated with it that we 
> would normally expect (for example Video Title), should we set a default 
> value for these cases?

Which leads us to: should we strip the filename to figure out a nice
title then?

> 2. If we do have a default value to set, should we write this back to 
> the file?
>
> I think if we plan to do this, we should have some "fix-up-data" 
> solution somewhere which we can apply after the actual data is extracted 
> to keep this part separate. This is currently a bug in 0.6. because we 
> use data like the file name for video title and if the file name 
> changes, of course, we don't update the video title. So we should 
> consider having to do that too.
>
> The write back issue is also being discussed later (Thursday I believe) 
> this week as to how or who should be doing this task. In 0.6. it is done 
> by the applications. Should it be done by Tracker? If so, what approach 
> makes sense here? Considerations here include how would LSA do it if we 
> switched or used it partially at some later date? Changes to the files 
> also mean monitor events, which means reindexing automatically (so some 
> signal blocking might be needed).

When I combine these two: having default values for missing fields and
writing back, I must conclude that it would be a terrible idea to write
back those default values to the files:

The user doesn't request that his files get "fixed up" with default
values. We're not EasyTag (which does this if you allow it to).

As for writeback: I guess the FS-miner or a separate component should do
this, and possibly only for local files and/or optional for miners that
are being developed externally.

As for the blocking: we'll be changing the mtime if we make any changes,
so this means that we need to update our database and yet be aware not
to do a complete rescan of the file (else we might end up in an endless
loop). For example by temporarily turning off filemonitoring for the
file being changed (ignoring it until the writeback is finished) and
then storing the mtime storage of it, then unignoring it.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be