OK. I will try re-phrasing my question. Suppose I am browsing a
directory which contains JPEG images. Now I am browsing it using the up
and down arrow keys. While doing so I want to mark a few files as
"Review later" or "Enhance image". So when the cursor moves to a
particular item in the file
On Thu, 2008-10-02 at 17:00 +0200, Dirk Meyer wrote:
> Using ~/.thumnails is freedesktop.org standard so it works between
> freevo and other prjects. Except that we use epeg for faster jpeg
> thumbnailing. That is against the standard and stolen from
> enlightenment.
Except I see a movie thumbnail
Jason Tackaberry wrote:
> On Thu, 2008-10-02 at 12:18 +0200, Dirk Meyer wrote:
>> You can not add covers to the db, they MUST be in the
>> filesystem. Beacon supports the basic styles like folder.ext and
>> movie.avi.ext with ext jpg or png. Besides that covers in id3
>> tags. The thumbnailing of t
Jason Tackaberry wrote:
> Ultimately the question comes down to: where should authoritative
> user-created metadata be stored?
Yes.
> The two obvious responses are 1. keep user-generated metadata in an fxd
> file, and have beacon parse it and duplicate it in its database
> (updating the db when t
On Thu, 2008-10-02 at 11:50 +0200, Hans Meine wrote:
> My idea was to use something like the .fxd files to make the latter types of
> data more permanent (and Dischi thought along the same lines IIUC), which
> does not prevent kaa.beacon from duplicating their content in a better
> accessible w
On Thu, 2008-10-02 at 12:18 +0200, Dirk Meyer wrote:
> You can not add covers to the db, they MUST be in the
> filesystem. Beacon supports the basic styles like folder.ext and
> movie.avi.ext with ext jpg or png. Besides that covers in id3
> tags. The thumbnailing of this images are done in beacon
Hans Meine wrote:
> Probably, cover images should not really be duplicated but referenced by
> appropriate filenames in the DB; for removable media, one would need a cover
> image cache directory though. (That could be Freevo stuff at first, at least
> I would not expect that functionality to b
Hi again!
Am Mittwoch, 01. Oktober 2008 19:56:25 schrieb Jason Tackaberry:
> The database arranges objects in a parent/child relationship,
> corresponding to the filesystem hierarchy. All objects have a media
> object as their top-most ancestor.
That's IMHO a logical, obvious structure and exact
Jason Tackaberry wrote:
> (dischi, it might be convenient if there was an 'available' attr of the
> media object which is True if the media is mounted currently. Or is
> there some alternate means of getting that info?)
IIRC you can get the list of all media available. But that could be
cleanup u
