In earlier chapters as we looked into the way that the web interface functions, you may well have assumed that the set inserting process in Wacs was very rigid and structured. We were trying to give you that impression because it is the best way to work but it is absolutely not the case at all! Wacs will actually index pretty much anything you throw at it - the basic ground rules are that there need to be a number of directories and in each directory there are a number of recognisable image files. The only real rule is that where there are directories containing images, all the directories there should contain images - there should not be a mix of directories containing just images and those containing sub-directories at the lowest level.
What the two image set processing applications (generate and updateinfo) actually do is to look at an existing filesystem structure and try their best to digest the content into metadata and insert it into the database. The generate actually calls updateinfo with the values it was called with, so they are effectively the same. It's just that updateinfo doesn't create icons.
Running generate is actually very simple, to import a tree of file
directories (say /home/wacs/images/redheads/smalltits/Sarah
)
you just do:
% generate redheads/smalltits/Sarah
[...]
COMPLETED: 12 new records inserted, 7 updated.
Calling make_index() with redheads/smalltits/Sarah
%
In this example, generate discovered 19 directories
containing image files in the directory specified, 7 of which it already knew
about and 12 of which were new to it. This is normally detected by the
presence of a hidden file called .info
which gives the basic
set number information for each set within each directory.
When the web interface is used, the Wacs placement manager
(see Chapter 8, wacsplacemgr - The Placement Manager) creates a file in the directory called
.unpack
which updateinfo uses to gain
clues about the model featured, the download record “satisfied”
by this set and so on. If this file is found, updateinfo
reads it and uses the values contained therein - if not, it tries a few
other heuristics to determine what it's looking at and if all else fails
just simply creates a new set without any model or download associations.
These heuristics vary by source site but basically resolve around looking for an “unsatisfied” download record with a known filename stem that matches the files found in the directory being considered. When it finds such a match, it will retrieve additional information like model number, set type, source site and photographer from the download record and merge that information with what it can determine from the name of the directory and the model's attributes. The download record will be marked as having been successful and will disappear from the model's detailed page. This method really only works when the image file names are long and quite structured in their naming but this is the case for a surprisingly large number of sites.
If a set is added without any associations, it can quite simply be used without any model associations or you can manually add the associations using the appropriate addassoc command. As mentioned in connection with the discussion of set naming, certain keywords are recognised within the directory name and used to define various special attributes in the default metadata for the set. Generate can recursively scan from the top of the images tree (or from any point on the sub-tree), but probably best avoided if you have a large number of directories in the system.
The genvideo command performs much the same
functions as the combination of generate and updateinfo for the importation
of video clips into the Wacs system.
It actually also includes aspects of the updateinfo program
but re-written for the video context.
However the video naming convention is often a lot simpler and what metadata
there is in inferred from the download record as very
little information can be gleaned from the name of the file itself.
In the case of videos, the .unpack
mechanism used by
the Wacs Placement Manager (see Chapter 8, wacsplacemgr - The Placement Manager provides
the best way of getting metadata about video sets into Wacs.
Note | |
---|---|
Although the relative pathnames appear the same, genvideo
operates in a parallel space under the videos tree in the file system.
Additionally icons are automatically referred to by the same pathname but in
the vidicons directory.
Therefore for |
updateinfo is actually what does most of the hardwork for generate including all of the database interactions. If called via generate, the icons will be made first - if called directly, no icon manipulations will be undertaken. When the placement manager wants to do two passes of the updateinfo process (in order to merge in model attributes and add additional models), it normally uses the direct updateinfo first and only generates the icons on the second pass through.