Re: Audio/Video file preview using gstreamer

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2007/9/26, John Stowers <john stowers lists gmail com>:

> Hi John,
>
> I recommend xesam for this as it means not having to rewrite tons of
> stuff for all possible backends

Yeah I agree.
>
> xesam 1 which is being finalised should be ready soon (along with client
> libs)
>
> xesam 2 which provides metadata store and keywords will follow after
> that

AFAICT xesam 1 provides support for querying tags via user search
keywords (tags), see [1] point 10

So at least in a xesam 1 implementation would provide the ability to
read tags from tracker/xesam even if it could not yet add them.

I believe that xesam-glib is also underway, so the transition from
xesam 2 -> would not add any additional libs beyond xesam-glib

>
> for the simple non-index backend I think mikkel was going to implement a
> non-indexed backend to xesam (perhaps he can confirm?) in which case
> your job would be much much easier

Cool, I will look into this.

While we are discussing this the other major architectural hurdle I
ran into was getting tracker/xesam to notify nautilus on metadata
changes. Il bring this up now to get your opinions if possible.

There are three difficult requirements I identified for this in the
nautilus-tagging stuff.

1) Nautilus needs to be kept updated about the user created tags in
tracker/xesam. In this case it might be possible to have some sort of
dbus-signal "user-created-keyword" or something. This signal would be
low frequency and would be used to update the nautilus emblem sidebar
to show tags that a user *created*.

2) Nautilus needs to be made aware of tag/metadata changes on files so
that it can update the shown emblem if a tag is added from another
application to a file currently showing in a nautilus open window. The
two possible ways would be to have a metadata-added signal emitted on
each file. I felt something like this would be too high frequency
(during indexing for example), and would require a fair bit of work on
nautilus part to filter out signals that refer to files in the open
window. The second option would be to use the existing inotify watches
on the files in the open window and somehow get tracker to trigger an
inotify event when it attaches metadata to a file. Unfortunately I
could not find anything in the inotify api for doing this
programatically. Perhaps tags could also be stored as xattrs on the
file by tracker because AFAICT intotify events are emitted when any
attribute on a file changes, enclusing xattrs. Other options included
creating a xesam live query for each folder shown in nautilus, and
watching this query for updates.

3) When visiting a folder the querying of tracker/xesam for the tags
on each file can be quite time consuming. Perhaps a query/live search
could be created that includes the uri of each shown folder. This
seems wasteful as a new xesam query would have to be destroyed and
created each time the user visits a folder. The benefits however, may
include getting updates if the metadata on any file in the query
changes.

So (2/3) were the biggest roadblock for me as I could not see a nice
way to do it without heaps of complexity, heaps of DBus calls and/or
reloading the nautilus window. Thoughts?

I would certainly not like an inotify solution to this, as it would be a linux-only solution.

It should be fine to keep a live xesam query for user tags for each folder with an open nautilus view (and not any particularly big overhead (assuming we have a solid search engine)).
 

For tags particularly I'm not sure that using the xesam search api is the right way. I can easily imagine users that want tagging abilities, but do not want to run an indexer.

Cheers,
Mikkel