You already know torch.__version__ → 1.10.0a0+git71f889c worked. Since then:
Hit the Rust-toolchain wall repeatedly (safetensors, hf-xet via huggingface-hub, later tokenizers for transformers/BLIP) — no Rust compiler on this box, and rustup's prebuilt binary needs glibc 2.17+ which this base CentOS 6 system doesn't have. Worked around every Rust dependency by pinning older package versions or using --no-deps + manual selective installs:
open_clip_torch --no-deps, then ftfy regex tqdm timm (all clean)huggingface-hub<0.24 (avoids the newer hf-xet Rust dependency)torchvision==0.11.1 --no-deps (pinned to match PyTorch 1.10's real compat matrix — unpinned, it tried pulling its own torch==1.13.1, an 887MB download that would have silently shadowed the working custom torch)safetensors skipped entirely — not needed for standard .bin/.pt checkpoints_imagingft.c (Pillow's optional font-rendering module) failed compiling against this CentOS 6 box's ancient system FreeType — needs FreeType 2.5+ constants (FT_LOAD_COLOR, FT_PIXEL_MODE_BGRA) for color-emoji/bitmap font support, unrelated to basic image decode/resize. Fixed with PILLOW_DISABLE_FREETYPE=1 pip install "Pillow<10".
model, _, preprocess = open_clip.create_model_and_transforms('ViT-B-32', pretrained='openai')
tokenizer = open_clip.get_tokenizer('ViT-B-32')Real OpenAI CLIP checkpoint downloaded successfully — confirms Clone has genuine outbound internet access (unlike an earlier sandboxed dev environment that blocked huggingface.co/openaipublic.azureedge.net).
Tested against 5 real photos (unlabeled, no predefined categories) with free-text queries. Result on the query "bag of pills" against a photo of bagged tablets: 96.65% confidence, correctly and heavily favoring "pills" over dog/syringe/landscape distractors. Repeated successfully on a second, visually distinct real image (99.74%).
Corrected the initial (wrong) mental model along the way: CLIP does NOT caption/describe images freely — it only ranks similarity between an image and text YOU provide. The real ISEmedia design (confirmed correct, not changed): embed every image once at index time with no labels, embed the user's free-text search query at search time, rank by similarity. This is what was actually validated, not a fixed-category classifier.
No ffmpeg on this box (dropped from CentOS repos years ago for licensing). A static prebuilt binary failed with FATAL: kernel too old (needs newer kernel syscalls than this CentOS 6 box's actual kernel provides) — same class of issue as the Rust/glibc wall. Compiled ffmpeg 4.4.5 from source instead (--disable-x86asm --enable-gpl --disable-doc, devtoolset-7) — worked cleanly, much faster than the PyTorch build. (One red herring along the way: a stale copy of the failed static binary was still shadowing the working compiled one via $PATH order — wasted a few minutes before spotting it.)
Extracted a real frame from a real Instagram-format mp4 (h264/aac, 720x1280, 89s), fed it into the same embedding/search pipeline as the photos — full pipeline now proven for both images AND video.
Andrew wanted true "just tell me what's in it" captioning with zero predefined labels. That needs a genuinely different model (BLIP/BLIP-2), which needs transformers, which needs tokenizers — Rust again, same wall as safetensors. Tried installing rustup directly to solve the Rust gap once and for all: failed — rustup-init's prebuilt binary needs glibc 2.14+ through 2.17+ (multiple missing symbols reported), and this base CentOS 6 system's glibc predates all of them. Building Rust from source was assessed as its own bootstrap nightmare (rustc needs an existing Rust binary to compile itself) — comparable to or harder than tonight's whole PyTorch saga, for a "nice to have" feature.
Decision: BLIP is parked. The core, actually-required ISEmedia feature (similarity search, no captioning needed) is fully proven and working. BLIP/Rust is flagged as a future project — likely worth revisiting only alongside a base-OS upgrade (e.g. as part of Andrew's floated idea of migrating to a dedicated VMware ESXi host on newer hardware/OS), not worth chasing further on stock CentOS 6.
Decision made: since Clone has now fully proven this works, migrate the same setup (torch + open_clip + ffmpeg) onto Live — the actual production box — rather than leaving this only on the disposable test VM. Standing safety rule for anything touching Live: image Live first, and any live-server change happens with a pre-change rollback point available. Andrew's real backup window is 2-6pm AEST (usually done by 2:30pm) — but this specific work was judged "safe enough to do now" since it's purely additive (new software installs, no touching the forum's existing code/DB), not the kind of destructive/structural change the backup-window caution is really protecting against.
kernel-2.6.32-431.1.2.0.1.el6.x86_64 on both — an earlier scare about Clone running a different/newer kernel than Live turned out to be a false alarm: uname -r on Clone showed 754.el6, but rpm -q kernel confirmed only headers/firmware packages at that version were ever installed, not an actual different boot kernel)/usr/local/bin/python3.8)/swapfile2) alongside the existing 2GB one — Linux pools multiple swap files/partitions together automatically by priority, confirmed via swapon --summary showing both active and free -h correctly reporting the combined 6GB totalvm.swappiness=15 (down from Live's prior default of 40) — deliberately biases the kernel toward keeping the forum's actual working set resident in RAM, only reaching for swap under real pressure, rather than swapping proactively. Reasoning explicitly discussed and agreed: on a 2GB box running a live web service, you want ordinary requests protected from swap-related latency, with swap reserved as a safety net for the occasional CLIP inference memory spike — not used casuallyhtop set up and kept visible throughout to watch memory/swap behavior live during upcoming testingMediaIndexer.py/MediaSearch.py's existing SimilarityRule scoring (built and tested against mock data months ago, never yet fed real embeddings)