CI Report:

https://ci-tests.linuxserver.io/linuxserver/pyload-ng/develop-e8bdb7b1-ls6/index.html

LinuxServer Changes:

No changes

Remote Changes:

fix: account stays valid on password change + DDownload detect deleted files as offline (#4706)

• fix: account stays valid on password change + detect deleted files as offline

Fixes 5 bugs found in production use with DdownloadCom accounts.

Bug 1 - Settings 500 Error: AccountInfo crashes on None/missing fields

After calling reset(), the account dict contained None for fields
declared as required (no default) in the Pydantic AccountInfo model:
login, premium, type, valid, options.
This caused a ValidationError on every Settings page load.

Fix in data.py: Add safe defaults to all required fields.
Fix in api/init.py: Use .get() with fallbacks + per-account
try/except so one broken account cannot crash the entire Settings page.

Bug 2 - reset() destroys identity: login/type/plugin wiped

BaseAccount.reset() used a generic clear() that set ALL data keys to
None/[]/{}. This silently wiped login, type, and plugin — the
three identity keys needed for the account to remain functional.

Fix in reset(): Exempt login, type, plugin from clearing.
Explicitly set premium=False (not None) for correct bool semantics.

Bug 3 - update_accounts skips info refresh: get_info() not called

update_accounts() called relogin() but never called get_info()
afterwards. Account info (premium status, traffic) was stale until
the next scheduled refresh.

Fix: Call u["plugin"].get_info() after relogin().

Bug 4 - Wrong password stays valid: session cookies bypass new login

When a user changes their account password in the Settings UI,
update_accounts() -> relogin() -> login() -> get_request() returns
the CACHED cookie jar. The existing session cookie causes signin() to
call skip_login() (op=logout found in form) returning valid=True
without ever testing the new password.

Reproduce: Change account password to wrong value -> account still
shows as valid and downloads the next file before session expires.

Fix: Detect if password actually changed and call
request_factory.remove_cookie_jar() before relogin() to force a
fresh authentication with the new credentials.

Bug 5 - DdownloadCom: deleted files not detected as offline

OFFLINE_PATTERN only matched >File Not Found<. When ddownload.com
serves a deleted file, the response contains >File Deleted< instead.
XFSDownloader found no offline marker, attempted to parse the download
form, found no TEXTAREA F1, and raised: "TEXTAREA F1 not found" /
"Plugin out of date".

Evidence from production log (2026-03-16):
ERROR - DdownloadCom: TEXTAREA F1 not found
The URL served a page with <h1 class="">File Deleted</h1>
No <form name="F1"> was present on deleted-file pages.

Available file HTML (form present, correctly parsed):

Deleted file HTML (no form, old pattern missed it):

File Deleted

Fix: OFFLINE_PATTERN = r">File Not Found<|>File Deleted<"

Tests: 17 regression tests added in tests/test_account_fixes.py

• update openapi.json

Co-authored-by: GammaC0de gammac0de@users.noreply.github.com