OF-Scraper-4-8-2026

Trial Link Scanner plugin — new, all versions

A new Trial Link Scanner plugin is now available (no changes to the main ofscraper package or patch files). It automatically scans for trial links and posts results to Discord via webhook. Place it in your ofscraper plugins directory to enable it.

Two bugs discovered during initial testing have also been fixed:

• Settings not reflecting saved values — the GUI combo boxes (Post timing, Post mode, Discord) reverted to defaults on every launch despite settings.json having different values. Root cause: currentIndexChanged fired mid-initialization before all combos were set, overwriting settings.json. Fixed by blocking signals on all combo boxes during _sync_controls_to_settings().
• Summary mode missing images — when Post timing was set to summary, Discord messages included text and links but no images. Fixed by reusing the same per-entry send logic as immediate mode, so each entry in the summary gets its images uploaded as attachments.

JoyCaption Tagger plugin fixes — all versions

Bug fixes for the JoyCaption Tagger plugin (no changes to the main ofscraper package or patch files).

• Gallery capped at 2000 images — the gallery query had a hardcoded .limit(2000), causing folders with more than 2000 tagged images to display a truncated count. The limit has been removed.
• No activity logging during folder scans — scanning a folder produced no log output. Added INFO-level log messages for each image tagged (JoyCaption: tagging …, JoyCaption: tagged … — N tag(s)) and WARNING when no caption is returned. Errors that were previously swallowed silently in the scan thread now log at ERROR level.

Discord scrape summary showing 0/0 — all versions

The per-run Discord summary ([username] X/Y media downloaded) always showed 0/0 for normal GUI download scrapes. Root cause: the code skipped reading DB stats entirely for normal downloads (to avoid replacing live table rows), leaving the stats dict empty. Fixed by adding a stats_only=True path to _load_models_from_db that reads stats from the DB without emitting table-replacement signals.

Daemon mode — @here Discord ping — all versions

A new @here Discord mention when new content is found checkbox has been added to the Daemon Mode section of the Select Content Areas & Filters page. When enabled, the Discord scrape summary will be prefixed with @here — notifying your whole server — but only when new content was actually downloaded during that run. If a daemon run finds nothing new, no ping is sent.

• Requires a Discord webhook to be configured and the Discord updates checkbox to be enabled
• The checkbox is disabled until daemon mode is turned on
• The preference is saved to gui_settings.json and persists across sessions

Daemon mode — table and Discord stats fixes — all versions

Four bugs affecting daemon mode (scheduled re-runs) have been fixed.

• Crash on every run after the first — stop_live_screen() in ofscraper's live display layer accessed live.transient on the GUI's _NullLive stub, which did not have that attribute. On daemon run #2+, _NullLive.start() had been called during run #1, setting is_started = True, so the early-return guard was skipped and the crash occurred. Fixed by adding transient = False to _NullLive and updating start() to accept the refresh keyword argument.
• Table empty after daemon re-run — the _live_rows_emitted flag was not reset between daemon iterations. After run #1 set it to True, run #2 would "skip DB table replacement" (correct behavior) but also skip emitting any live rows (since the run crashed before downloads began), leaving the table blank. Fixed by resetting _live_rows_emitted = False at the top of each daemon loop iteration.
• Error tracebacks posted to Discord — when a scrape run failed, the full Python traceback was sent to Discord because the Discord log handler was still active at the point the error was logged. Fixed by calling _mute_discord_handler() at the start of the error handler, and downgrading internal DIAG diagnostic log messages from WARNING to DEBUG so they do not reach the Discord handler.
• Discord stats showing same cumulative count every run — the per-run Discord summary always reported the same totals (e.g. 165/199 on every daemon run) because it was reading the cumulative DB totals rather than what was actually downloaded in that run. Fixed by reading photo_count/video_count/audio_count from common_globals (reset at the start of each daemon iteration) for the per-run new count, while the DB totals are shown separately as downloaded/total in DB.
• Table showing only incremental rows on daemon re-run — after a daemon re-run, the content table showed only the small number of newly downloaded items instead of the full model DB (e.g. 5 rows instead of 199). Root cause: the is_normal_gui_download and elif self._live_rows_emitted conditions were not guarded by run_count == 1, so run #2+ skipped the full DB load. Fixed by adding and run_count == 1 to both conditions, forcing daemon re-runs to always reload the full DB.
• Profile/avatar images showing as not downloaded — profile images were filtered out of the download queue by seperate_avatars() before reaching _emit_download_status, so they were never checked against the profile cache and always appeared as []/False in the table. Fixed by passing all filtered rows (extra_table_rows) to _emit_download_status, which now checks each row against the media DB with a profile cache fallback for Profile-type rows. Also fixed a second instance where all items were filtered (empty download queue), causing the finally block to be bypassed entirely via an early continue.