Plex shows items as newly added1.x

since 1.3.0

When Plex marks an old episode as “newly added” and re-runs intro/credits detection, infinidysk almost never changed the file’s metadata in place. WebDAV getlastmodified is the immutable DavItem.CreatedAt; there is no ETag. Plex tracks items by file path, so “newly added” means the path vanished and came back — either the server deleted and recreated it, or Plex removed its own library row after a failed scan and re-added it on the next clean scan.

Use the checks below in order. The first one settles most cases without touching logs.

1. Compare file mtime with Plex “added” date

On the host, run:

ls -l "/path/to/plex/library/Show Name/Season 01/episode.mkv"

If the mtime is weeks or months old but Plex says “added today”, infinidysk did not recreate the file. The Plex library row was deleted and re-added because a scan saw the path as unavailable — skip to section 4 below.

If the mtime is recent or the path changed (new release name, or a (2) suffix), the server really did re-import the file. Check infinidysk history, health results, and Sonarr history for that episode.

2. Is background repair enabled?

Settings → Health & Repairs → Enable Background Repairs. Default is on. If off, health-repair deletion is ruled out.

3. Look for a server-side deletion

SELECT CreatedAt, Path, Result, RepairStatus, Message
FROM HealthCheckResults
WHERE RepairStatus IN (1, 2)
ORDER BY CreatedAt DESC;

RepairStatus values: 1 = Repaired, 2 = Deleted. Neither value tells Arr blocklisting apart from a forced deletion; read the Message column and the matching deletion audit line. Also search the container logs:

docker logs <container> 2>&1 | grep dav-delete

Health-repair deletes are logged as dav-delete source=health-repair ... reason=health validation failed; ... or reason=auto-removed after repeated streaming failures (count=N). See Deletion audit for all sources.

4. Transient scan failure

If mtime is old and no dav-delete exists, the most likely cause is a scan that raced an unavailable or stale rclone view. Likely triggers:

• container restart or auto-update while Plex was scanning
• rclone vfs/forget of /content/{category} immediately after an import forces a fresh PROPFIND
• lazy RAR size correction changing the advertised size after first stream
• frontend proxy timeout on a large season folder
• network or mount blip

Plex’s Empty trash automatically after every scan likely turns that temporary unavailability into a deleted library row; the next scan re-adds it.

5. Confirm the Plex trash setting

Plex Settings → Library → Empty trash automatically after every scan is likely enabled when this symptom appears. Disabling it prevents the re-add churn but leaves stale “unavailable” items after real upgrades.

6. Sonarr history

Even if you do not remember a grab, check Sonarr History for the affected series. A repair-triggered EpisodeSearch or a repack/proper shows up there and produces a new /content path.

---

If these checks point to a transient listing failure, collect a technical support pack while the problem is fresh and open an issue with the webdavCounters section of environment.json and any dav-delete lines.