protonscr

Toggling shader pre-caching off and on triggers full re-download of `transcoded_video.foz` despite existing on-disk file

steamopen
ValveSoftware/steam-for-linux#13215 · opened 2026-05-16 by Groni3000 · updated 2026-05-16 · 0 comments · github
GGroni3000 2026-05-16 github

Your system information

  • Steam client version (build number or date): 1778281814
  • Distribution (e.g. Ubuntu): Pop!_OS 24.04 LTS (ID_LIKE="ubuntu debian")
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes
  • Steam Logs: steam-logs.tar.gz
  • GPU: Nvidia RTX 4070TI

Please describe your issue in as much detail as possible:

When shader pre-caching is disabled and then re-enabled, the Steam client abandons all bucket tracking metadata and deletes the small steam_pipeline_cache.foz files, but leaves the much larger transcoded_video.foz payload on disk. On re-enable, the corresponding bucket (SteamSwarm/G7:CompatVideoTCMediaV1) is committed from 0 and the full manifest is queued for re-download, despite a payload of comparable size already existing locally.

For Wuthering Waves (AppID 3513350): a 46 GB on-disk transcoded_video.foz is orphaned and a ~45.75 GiB re-download is triggered by a single UI toggle.

Steps for reproducing this issue:

  1. Install a game with substantial pre-cached video content. Wuthering Waves (AppID 3513350) reliably reproduces; transcoded_video.foz reaches ~46 GB after normal use.
  2. Confirm ~/.steam/steam/steamapps/shadercache/3513350/transcoded_video.foz exists at multi-GB size.
  3. Settings → Downloads → uncheck Enable Shader Pre-caching. The cache size shown in the UI immediately drops to 0.
  4. Confirm on disk that transcoded_video.foz is still there at full size (it is not deleted).
  5. Re-check Enable Shader Pre-caching.
  6. Observe Steam queue a full re-download of the CompatVideoTCMediaV1 manifest.

Below is Claude's shader_log.txt analysis.

Feel free to skip it and verify/analyze attached logs by yourself. I'm just trying to be honest: I just verified that AppID is correct.
Here is a log file I fed it: share_log.txt
I just deleted dozens of thousands of Mismatching key! lines like in the head of this log.

Log evidence

On disable (12:12:43):

Abandoned all bucket tracking progress for AppID 3513350.
Removed native depot cache file .../shadercache/3513350/fozpipelinesv6/steam_pipeline_cache.foz
Removed native depot cache file .../shadercache/3513350/fozpipelinesv6/steamapprun_pipeline_cache.f8e37139bec012fd/steam_pipeline_cache.foz
Removed native depot cache file .../shadercache/3513350/fozpipelinesv6/steamapprun_pipeline_cache.2e6c105801134e9c/steam_pipeline_cache.foz
Deleting shader cache library folder .../shadercache/3513350/steam_shader_cache/.

Only the small pipeline cache files are removed; transcoded_video.foz (~46 GB) is retained on disk.

On re-enable (12:29:13):

[ AppID 3513350 ] Queuing depot manifest 9019217494482230314 (49123288933 bytes) for bucket ID 78069828, type SteamSwarm/G7:CompatVideoTCMediaV1.

49,123,288,933 bytes ≈ 45.75 GiB queued for a bucket whose payload already exists locally at comparable size.

On subsequent commit:

Committed bucket 70068269 (AppID 3513350) from 0 to 52961765028922651.
Committed bucket 58966600 (AppID 3513350) from 0 to 589479061043197911.

from 0 confirms the client has no recorded state for this bucket and is fetching the full manifest, not a delta against the local file.

Filesystem state during the re-download — a fresh transcoded_video.foz is being assembled in downloads/ while the existing 46 GB file sits one directory up untouched:

~/.steam/steam/steamapps/shadercache/3513350
├── downloads/
│   └── transcoded_video.foz   (growing: 3.2G → 3.6G during sample window)
└── transcoded_video.foz       (46G, appears untouched during the redownload)

Expected behavior

One of:

  • Disabling pre-caching also removes transcoded_video.foz and other bucket payload files so on-disk state matches the UI's reported 0 GB
  • Re-enabling pre-caching validates existing on-disk bucket payloads against the manifest (hash check or equivalent) before queuing a full re-download.

Actual behavior

Tracking metadata is discarded but payload files are retained, and the lookup path on re-enable appears to consult tracking metadata only — not on-disk archive contents. The toggle therefore produces both orphan storage (~46 GB unused) and avoidable bandwidth use (~45 GiB re-download) in a single operation.

❯ cd downloads
❯ l
total 2.7G
drwxrwxr-x 2 groni groni 4.0K May 14 12:51 .
drwxrwxr-x 8 groni groni 4.0K May 14 12:51 ..
-rwxrwxr-x 1 groni groni 3.2G May 14 12:51 transcoded_video.foz
❯ l
total 3.1G
drwxrwxr-x 2 groni groni 4.0K May 14 13:13 .
drwxrwxr-x 8 groni groni 4.0K May 14 13:13 ..
-rwxrwxr-x 1 groni groni 3.6G May 14 13:13 transcoded_video.foz
❯ cd .. && l
total 46G
drwxrwxr-x 8 groni groni 4.0K May 14 13:13 .
drwxrwxr-x 4 groni groni 4.0K May  2 22:29 ..
drwxrwxr-x 2 groni groni 4.0K May 14 13:13 downloads
drwxrwxr-x 2 groni groni 4.0K May  2 01:40 DXVK_state_cache
drwxrwxr-x 2 groni groni 4.0K May  2 02:06 fozmediav1
drwxrwxr-x 4 groni groni 4.0K May 14 12:47 fozpipelinesv6
-rw-rw-r-- 1 groni groni    0 May 14 11:13 h264-used
drwxrwxr-x 3 groni groni 4.0K May  2 01:40 nvidiav1
-rw-rw-r-- 1 groni groni    0 May  8 22:35 placeholder-video-used
-rwxrwxr-x 1 groni groni  75K May 14 13:13 state_3513350_3513350.patch
drwxrwxr-x 2 groni groni 4.0K May 14 13:13 temp
-rwxrwxr-x 1 groni groni  46G May 14 10:06 transcoded_video.foz
╭─ ~/.steam/steam/steamapps/shadercache/3513350 ············ at 01:17:14 PM
╰─❯

Nothing extracted yet.