dsh-bili-scroll: Bilibili scroll plugin setup

dsh-bili-scroll does not auto-scroll videos. It searches Bilibili by keyword, reads subtitles, filters content, and writes a digest. Four same-name implementations exist with different configuration and delivery; choosing the wrong one makes every later setting mismatch.

Correct the name first: inspection, not scrolling

The word scroll suggests simulated scrolling and view inflation. The actual flow is search, read subtitles, judge, and write a digest, with no click simulation (source).

Input is a keyword; output is a Markdown digest. Judging relies on subtitles rather than thumbnails or titles, so videos without subtitles may be skipped. That is a design trade-off, not a failure.

The purpose is to reduce time spent browsing, not to increase views. Understanding this prevents wrong frequency and boundary settings.

Four same-name implementations

Same name does not mean same features. Compare focus before choosing.

lll-77777777 suits topic inspection. Keywords and @ targets are the main settings.

zxz-feng suits getting started. The settings page exposes options and the install method is documented.

littlefallenstar suits workflow integration. Email and Obsidian support make results part of a note system.

c1overzz suits scheduling plus comments. It adds a comment toggle and scheduled runs for a fixed daily output.

Do not install all four. They will duplicate fetching and delivery, and may overwrite each other's digest files.

Install: dependencies before plugin

These plugins rely on external capabilities; read the dependency list first.

1. Search dsh-bili-scroll in the Hub, check the owner, and confirm the implementation you chose.
2. Read the dependency and configuration notes on the detail page.
3. Install, then restart so the plugin registers.
4. Open the settings page; if it is missing, the profile or version is wrong.
5. Leave scheduling off until a manual run succeeds.

Dependencies usually include network access, subtitle reading, and a delivery channel. Missing any one produces "the task ran but produced nothing."

Verify delivery separately. A wrong email, Obsidian, or webhook setting does not fail during inspection; it fails only when delivering.

Configure: keyword, target, schedule, delivery

Fill four groups in order: make search work, then make delivery work.

1. Keyword and @ target: start narrow with one clear topic, and add creators only when you want a fixed list; otherwise search the whole site.
2. Schedule: pick a later time slot after a manual run works; avoid high frequency to reduce platform limits.
3. Delivery: send a test message through email, Obsidian, or webhook before connecting the digest.

Keywords decide quality; delivery decides whether anyone reads it. Tune them separately.

Keep a configuration record. Keyword, time slot, and delivery channel in one note; scheduled failures can then be compared.

First run: manual first

Do not start with a schedule. A manual run verifies search, subtitles, judging, and delivery separately.

1. Trigger one manual run from the panel.
2. Read the run record: how many videos found, how many subtitles read, how many conclusions produced.
3. Open the Markdown digest and check structure and content.
4. Confirm the delivery channel received the same digest.
5. Only then enable scheduling.

Manual runs make each stage visible. When a scheduled run fails later, you know which stages worked before.

A weak first result is normal. Broad keywords, missing subtitles, and unclear judging all hurt quality; tune the keyword first, then the prompt, not everything at once.

Scheduled failure diagnosis

Manual works but scheduled fails: the problem is runtime conditions, not plugin logic.

1. Schedule did not fire: check for a record at the expected time; none means the schedule or service is not running.
2. Missing dependencies: scheduled tasks may use a different environment; confirm Node.js, network, and command paths.
3. Expired credentials: search and subtitle reading need valid credentials; manual runs may also fail, just not at the time you tested.
4. Delivery failure: inspection succeeded but delivery failed, and the digest remains local; read delivery logs.

Check the run record, then dependencies, then credentials and delivery. Reverse the order and you waste time on plugin logic.

Keep failure records. Time, error, and configuration together make reproduction possible; "it did not run" is not enough.

Boundaries: public content, frequency, copyright

The plugin handles public content, but boundaries remain.

1. Control frequency: do not schedule too densely; it stresses the platform and raises limit risk.
2. Public content only: do not fetch authorized or paid content, and do not bypass access controls.
3. Personal digest: credit sources when quoting subtitles; do not redistribute full subtitles as your own content.

Boundaries are habits, not technical limits. Reasonable frequency and scope keep the tool stable over time.

Next steps

Pick one implementation, run it manually, then schedule. For browser-related plugins, read dsh-browser explained. For installation and verification, read How to install from DSH Plugin Hub. To choose plugins by scenario, read Choosing DSH plugins by scenario.

Sources: dsh-bili-scroll plugin page (lll-77777777), dsh-bili-scroll plugin page (zxz-feng), dsh-bili-scroll plugin page (littlefallenstar), dsh-bili-scroll plugin page (c1overzz)