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 (wacsgenimg and wacsupdinfo) 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 wacsgenimg actually calls wacsupdinfo with the values it was called with, so they are effectively the same. It's just that wacsupdinfo doesn't create icons.
Running wacsgenimg is actually very simple, to
import a tree of file directories (say
/home/wacs/images/redheads/smalltits/Sarah)
you just do:
% wacsgenimg redheads/smalltits/Sarah
[...]
COMPLETED: 12 new records inserted, 7 updated.
Calling make_index() with redheads/smalltits/Sarah
%
In this example, wacsgenimg 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 wacsupdinfo uses to gain
clues about the model featured, the download record “satisfied”
by this set and so on. If this file is found, wacsupdinfo
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 wacsgenvid command performs much the same
functions as the combination of wacsgenimg and
wacsupdinfo for the importation of video clips into the
Wacs system. It actually also includes aspects of the wacsupdinfo
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]](images/note.png) | Note |
|---|---|
Although the relative pathnames appear the same,
wacsgenvid 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 |
wacsupdinfo is actually what does most of the hardwork for wacsgenimg including all of the database interactions. If called via wacsgenimg, 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 wacsupdinfo process (in order to merge in model attributes and add additional models), it normally uses the direct wacsupdinfo first and only generates the icons on the second pass through (using wacsgenimg instead.
The wacsvidcomb is only really used for one specific type of set - a video set that was split into several smaller files for downloading. This command allows you to create a combined, cached copy of the multiple files as a single full length video clip. It only applies to video clips and can only be used when the various clips have been correctly marked up with the wacssetmgr (Wacs Set Manager web app) as being a primary and then continuation files. Additionally the download name for the set has to be specified - this is not the same as the name of the video file within the Wacs video files tree (although it can be if you wish).
With these pre-requisites done, the wacsvidcomb
command is executed with the set number of the primary set. This will
create a video of the whole video in your process directory of the unpack
area. Where possible, the skip frame value will be used to try and remove
any unwanted conformance slates from the later video clips. Note that the
value used here is that of the sskipfr field of the
sets data table. When MPlayer's mencoder is the conversion utility used
(current default for Linux), the skip frame value is considered to be the
number of i-Frames to be skipped. Many of the conformance slates are a
single i-Frame sequence prepended onto the video, therefore a value of 1
is sufficient for a full removal. Obviously the exact rules for each
source have to be determined by experimentation.
Once wacsvidcomb has succesfully run, you will need to also run the wacscachectl command to relocate the compilation movie from your process directory into the appropriate place in the web tree.
The wacscachectl command is responsible for managing the caches in the web tree for wacs sets. This only comes into effect when the UseDirect option is enabled, but it allows the direct downloading of video or zip files from the webserver bypassing the slower and less flexible wacszip system. Where a video set is a single file, this will create a symbolic link in the web tree; where it is a compilation, it will site the file created by wacsvidcomb in the appropriate place and create the necessary links to make use of it in preference to the raw version.
The normal invocation of this command is:
wacscachectl --create setno