A minor release with one behaviour change — read the first item below before upgrading if any of
your rows are set to 0% already-watched, which is the default.
Changed
-
A row set to 0% already-watched now also excludes shows someone has only STARTED. It used to
exclude only shows they had finished, where "finished" meant 80% of the episodes or a
length-scaled floor of about three. So a series you were two episodes into was, as far as the row
was concerned, a fresh discovery — and could be recommended straight back to you. That was
reported, and it was doing exactly what it was told.Plex draws no such line: its own watched filter returns a series from its first episode. A probe of
a real server found it returning shows as little as 1.1% watched (2 of 176), and on that server
five of ten started shows were still eligible to be suggested to the person watching them. At 0%,
started now means watched — the two agree.Rows above 0% are unchanged. There the percentage is still a ceiling on finished titles,
because "N% of the row" needs a definite line to mean anything. If you relied on the old
behaviour, set the cap above 0. Rows re-pick their titles on their own refresh night, so the change
reaches a row when it next rebuilds rather than immediately. -
"Only series they haven't started" is now offered on a films-and-shows row, not just a
shows-only one. The API and the engine always accepted it there; the switch was hidden, so the
default row most installs have could never turn it on. On a 0% row it is now a no-op — that row
excludes started series anyway — and it still does real work on a row whose cap is above 0%.
Added
-
"Have an issue?" — a new page, replacing the sidebar's separate Report a bug and Copy
diagnostics buttons. It runs twenty-one read-only checks against your own server and, for most
problems, names the cause outright: which library refused someone's token, which setting actually
applied, why a row is short, whether Plex still matches what Shortlist thinks it delivered.Nothing on the page changes anything — not your Plex server, not your rows, not your settings. The
checks stay off until you switch them on and switch themselves off again after 24 hours, because
they read share filters and per-user tokens. Every check has a Copy for support button, and
what it copies is shown on screen first so a paste holds no surprises. The last section files the
report: a pre-filled GitHub issue plus a diagnostic to attach, as a paste or a file. That
diagnostic masks credentials, IP addresses and your server's machine id. It is a good first pass
rather than a guarantee: logs carry whatever a dependency decided to print, so give the report a
skim before posting it publicly. It does name the people on your server by their Plex username —
replace those yourself if you'd rather not publish them.If someone reports a problem on a server you don't administer, sending them there is usually faster
than a list of questions.
Fixed
-
A downloaded log zip no longer carries your server's IP address or machine id.
Logs → Downloadcalls itself "the attachment for a bug report" and had only ever removed
credentials — so it shipped your Plex server's address on every line that recorded a call to it
(17,234 of them in one real export) and, where a collection write was logged, the machine id that
identifies your server. Both are now removed there and in the diagnostic report, which had the same
gap in the log files it bundles.A URL keeps its scheme and port (
https://<host>:32400) because those are the parts that answer a
question. The live Logs view is deliberately unchanged: it renders on your own screen, where your
server's address is what makes a line readable. -
The documentation described a
recommendations.watched_show_pctsetting that has never existed.
The finished threshold is fixed in the engine; the docs now say so.