This one page is shared by all five search dropdowns — ISE (forum posts),
ISEpdf (PDF attachments), ISEmisc (text/code attachments),
ISEmega (Posts + PDF + Misc, merged into one result list), and
ISEmedia (images, video and audio, searched by filename, internal
filename, post subject, AI captions and audio tags). Reach it any time by typing /help as your search
query, or via this same link shown at the bottom of every results page.
*/? wildcards work on bare words
in all three, and "double-quoted phrases" are case-sensitive exact
matches. Wildcards do not work inside quotes in any source — see Wildcards
below. The one remaining difference among those three is what a phrase
can check: ISE (posts) and ISEmisc check real adjacent-word-order
phrases against actual stored text; ISEpdf now checks real phrases too, and
case-independently (see the note under ISEpdf below). ISEmega simply runs your query against those same three
sources and merges the results — it doesn't add its own quoting/wildcard
rules, it inherits whatever each of the three does on its own. ISEmedia
(as of MediaSearch v1.6.0) supports wildcards and quoted phrases too — it
searches names, captions and tags rather than full text; see the dedicated
ISEmedia section below.
| Style | ISE (posts) | ISEpdf | ISEmisc |
|---|---|---|---|
| No quotes e.g. heroin |
Normal word search. Case-insensitive, fast index lookup. | Normal word search. Case-insensitive (as of v7.4 — the stored index still isn't lowercased, but matching now folds case at search time). | Normal word search. Case-insensitive, fast index lookup. |
| "Double quotes" e.g. "opioid crisis" |
True phrase match. Exact, case-sensitive, literal substring — spacing and punctuation inside the quotes must match exactly. | True phrase match (as of PDFsearch v7.6.0). Case-independent. The index finds pages holding every word, then each page's real text is checked for the words side by side (punctuation and line breaks between them don't matter). If a page can't be checked (too many candidates, or no PDF reader on that server) it's kept and the results page says "not checked word-for-word". | True phrase match (as of v7.4). Case-sensitive, real literal substring against the file's actual stored content — same guarantee as ISE (posts). |
| 'Single quotes' e.g. 'heroin' |
Known gap — avoid. Not recognized as a phrase marker. The quote characters become part of the literal search string, which almost never appears verbatim in real post text, so this will usually return zero results. | Not supported. Same as ISE above — avoid. | Not supported. Same as ISE above — avoid. |
Audio is measured when it's indexed (AudioProcessor v1.1.0): tempo in BPM, musical key, loudness (LUFS) and, for long mixes, approximate track changes. Two filters use it, on their own or with ordinary words:
| Type | Finds |
|---|---|
bpm:124 | tempo 122.5–125.5 (a whole number means ±1.5) |
bpm:122-126 | tempo in that range |
key:Am key:A-minor key:F# key:Gb-major | that key; a bare note (key:A) matches major or minor; flats are read as their sharp |
A file fits when its own value does, or — for long mixes — when any
30-second stretch does, and the card says where (“132 BPM at 12:00, 12:30 …”).
Filters must all fit; ordinary words still need only one to match. Each filter is
checked on its own, so key:Am bpm:122 means “has A minor somewhere and
122 somewhere”, not necessarily in the same stretch. Automatic tempo can read half
or double the real tempo on some material (fast drum & bass may show as ~87).
By default, every search source requires all terms
(AND). A space between words means both must appear: mysql incremental
only returns results containing both words. The old capital-AND
keyword (mysql AND incremental) still works and is equivalent; it is
stripped before the search, so it is never treated as a literal word to match.
To switch to OR mode — where a result needs any one of
the terms — prefix the query with /sort use-OR:
/sort use-OR mysql incremental returns results that contain either
word. The prefix is stripped before searching and does not appear as a search term.
| Syntax | Meaning | Sources |
|---|---|---|
mysql incremental | Both terms required (AND, default). | ISE, ISEpdf, ISEmisc, ISEmedia |
mysql AND incremental | Same as above — uppercase AND is a keyword, not a search word. | ISE, ISEpdf, ISEmisc, ISEmedia |
/sort use-OR mysql incremental | Either term matches (OR). | ISE, ISEpdf, ISEmisc, ISEmedia |
For ISEpdf and ISEmisc, AND applies across all fields: a
document matches if all query terms appear somewhere across its content,
filename, and topic subject (they do not need to be on the same page). A lowercase
and, or AND inside quotes, is treated as an ordinary word.
* matches any run of characters, ? matches exactly
one character.
| Source | Wildcard support |
|---|---|
| ISE (posts) | Supported (as of v7.4.1). Post bodies and subjects. Case-insensitive, matching this source's normal case-insensitive word matching. |
| ISEpdf | Supported — content and filename/topic search. Case-insensitive (as of v7.4), matching this source's normal case-insensitive word matching. |
| ISEmisc | Supported — content and filename/topic search. Case-insensitive, matching this source's normal case-insensitive word matching. |
| ISEmedia | Supported (as of v1.6.0). Matched against the whole filename, internal filename and post subject (so *.png lists every PNG, IMG_01.PNG included), and against each caption/tag word. Case-insensitive. |
Wildcards inside "double-quoted phrases" are not
supported in any of the three sources — a */?
inside quotes becomes a literal character in the exact-match/phrase check,
which will almost never appear verbatim in real text. Wildcards only work on
bare, unquoted words.
Example: *aud* in any of the three sources'
content search matches any indexed word containing "aud" — "claude", "audio",
"fraud", etc. Example: methad* in ISE (posts) matches "methadone",
"methadose", etc.
*/? in it always uses the faster
exact-match path — wildcards only trigger the slower full-scan when actually
present in what you type.
By default, results are ordered by relevance score (see "Why is this ranked #N?" on each result card). Typing one of these as part of your query re-sorts the results you already got, without changing which results matched:
| Command | Effect | Works on |
|---|---|---|
/sort newest | Newest first, by date posted. | ISE, ISEpdf, ISEmisc, ISEmega, ISEmedia |
/sort oldest | Oldest first, by date posted. | ISE, ISEpdf, ISEmisc, ISEmega, ISEmedia |
/sort newmod | Most recently edited first. Posts that have never been edited fall back to their post date. | ISE only |
/sort oldmod | Least recently edited first (same fallback as above). | ISE only |
newmod/oldmod only work on
ISE (forum post) search — PDF, Misc, and Media attachments don't have an
"edited" concept the way a post does, so there's no modified date to
sort ISEpdf/ISEmisc/ISEmega/ISEmedia results by. On ISEmega specifically, a
newest/oldest sort also changes how results
from the three sources are combined: normally ISEmega interlaces
Posts/PDF/Misc results to keep all three sources represented even when
one scores much higher than the others; a date sort instead merges all
three into one straight chronological list.
On ISEmedia specifically, a real search term always
still has to match — even under /sort newest/oldest
— before date-sort reorders the matches. This is different from how it
might sound by analogy with the other sources: ISE/ISEpdf/ISEmisc/ISEmega
already only ever see matching items by the time a sort is applied (their
underlying index lookup filters to real matches first), so their date-sort
"just" reorders what's already a matching set. ISEmedia's ranking starts
from every indexed image/video as a candidate (it's a similarity search,
not a word-index lookup), so as of v1.2.0 it explicitly requires a literal
caption/filename/subject keyword match before applying any sort — including
date sort — so a query like /sort newest brown only shows
items that actually match "brown," newest first, rather than every recent
upload regardless of relevance.
Sorting applies after search — it never changes which posts/PDFs/files/media match your query, only the order they're shown in.
| Source | Searches | Result links to |
|---|---|---|
| ISE | Forum post bodies and subjects, forum-wide. | The matching post directly. |
| ISEpdf | Text extracted from PDF attachments, plus PDF filenames and their topic's subject line. | The PDF opened in the PDF.js viewer at the matching page, plus a "Jump to post" link. |
| ISEmisc | .md/.txt/.text/.json attachment content, plus filename/topic subject for those and for a wide range of code/config attachment types (.py, .php, .js, .sh, .sql, .html, .css, .c, .cpp, .java, .rb, .go, .rs, .pl, .xml, .yml/.yaml, .ini, .conf) — those code/config types are filename/type searchable only, not full-text searched, but always viewable via "Open file". |
The owning forum post, plus "Open file" to download/view the attachment directly. |
| ISEmega | Runs your query against ISE + ISEpdf + ISEmisc only and merges the three result lists into one page (interlaced by relevance score by default, or a flat chronological merge under /sort newest/oldest). Shows up to 180 results by default (soft cap — an on-page "Show all" link or an explicit --limit/&all=1 bypasses it); everything was still searched and ranked, the cap only limits how many cards are drawn. |
Whichever of the matching post / PDF viewer / attachment the result actually is — same links as that source's own search. |
| ISEmedia | Images, video and audio, by name and by what's in them. A search term must match the item's filename, internal filename (<id>_<hash>, the name on disk), the subject of the post it's attached to, an AI caption (image, or any video frame), or an audio tag/caption. Wildcards and quoted phrases work (see the ISEmedia section below). Shows up to 180 results by default with a "Show all" link, like ISEmega. Not included in ISEmega yet — this is a separate dropdown option, searched on its own. |
The image displayed inline / video attachment, plus a "Jump to post" link. |
ISEmedia (MediaSearch v1.6.0) has no full-text word
index — media has no text of its own. Instead every catalogued image, video
and audio file is matched on these fields, and each result card says which
one matched ("*.png" in filename: IMG_01.PNG):
| Field | What it is | How a term matches |
|---|---|---|
| Filename | The name it was uploaded with | Whole name: plain word = anywhere in the name; wildcard = the whole name must fit the pattern |
| Internal filename | SMF's name on disk, <id_attach>_<hash> | Same as filename. 6204_* finds attachment 6204 exactly; a bare 6204 also finds any other internal name containing 6204 |
| Post subject | Subject of the post it's attached to | Same as filename |
| Caption | AI caption of an image, of each video frame, or of each audio window | Whole words (ham won't match "hammer"); the best-matching frame/window is shown, e.g. "12:30 into audio" |
| Tags | Audio tags (dance, lecture, male ...) | Whole words |
Any term matching any field includes the item (like the
other sources' default OR). "Quoted phrases" match as one unit, and
here they are case-insensitive (AI captions have no meaningful
case). Wildcards don't work inside quotes, same as everywhere else. A bare
/sort newest/oldest with no other term lists
every item by upload date.
No AI model is loaded when you search — the AI work (captions, tags) was done once, when each file was indexed.
Type /help in any of the five search boxes to get back here.