protonscr

DOAXVV (AppID 1361350) daily update of 1~10GB and 20-minute processing starting about a week ago, despite no app updates on SteamDB (Debian 13)

steamclosed
ValveSoftware/steam-for-linux#13197 · opened 2026-05-13 by axis6404 · updated 2026-05-14 · 3 comments · github
Aaxis6404 2026-05-13 github

Your system information

  • Steam client version (build number or date): 1778281814
  • Distribution (e.g. Ubuntu): Debian13
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes
  • GPU: NVIDIA GeForce RTX 5060 Ti (Driver Version: 595.71.05)

Please describe your issue in as much detail as possible:

Starting about a week ago, the Steam client began triggering a massive update for DOAXVV (AppID: 1361350) every single day, even though there are no actual game updates on SteamDB.

Before about a week ago, this behavior never occurred. The heavy update happens every day, but closing and immediately restarting the Steam client does not trigger it again on the same day.

  • Steam AppID: 1361350 (DEAD OR ALIVE Xtreme Venus Vacation)
  • Proton version: Proton 10.0-4
  • Current file size: ~/.steam/steam/steamapps/shadercache/1361350/transcoded_video.foz has bloated to 14.7GB

Steps for reproducing this issue:

  1. Launch Steam client on Debian 13 (first launch of the day).
  2. A 1GB to 10GB update is automatically downloaded for DOAXVV (AppID 1361350).
  3. It takes about 20 minutes for the background processing to finish, putting a heavy load on the CPU. (Is this a video format conversion for .wmv files?)
  4. The file transcoded_video.foz continuously accumulates data every day, eventually bloating to 14.7GB after about a week.
Kkisak-valve maintainer 2026-05-13 github

Hello @axis6404, you've describe the nominal behavior of Steam's shader pre-caching subcomponent. In general, this subcomponent is used to distribute hardware independent shaders that are replayed by fossilize and your video driver to warm the video driver's on-disk shader cache. There is also remotely transcoded game videos that are swapped in place as games ask for them.

The general frequency of this subcomponent is being discussed at #8076, and without a stronger indication of a problem, the behavior you've described is the current intended behavior.

GGroni3000 2026-05-14 github

@kisak-valve There is clearly something wrong with pre-caching for some titles.

Wuthering Waves - appid: 3513350

Once it downloaded 45 GB! I thought "ok, whatever" and it was compiling shaders for 40+ minutes (if I recall it correctly, maybe ~1h) before I could enter the game.

And still every single day it downloads 1.3 GB and compiles shaders for 10+ minutes...

Today was a comical case: it downloaded 1.3 GB as usual with 10+ minutes of compilation, I entered the game and... There was an update (such games sometimes have updates in-game only) and the game requested to exit and re-enter the game. I did and... The game itself began shader compilation! Now I have two sources of shader compilation...

I decided to turn this pre-caching off. Setting Enable Shader Pre-caching showed ~50gb pre-cached. I turned it off and it showed 0 instantly. I thought it's strange to delete cache if I just turned download off. And yes, it did not delete, I have... 46 GB transcoded_video.foz.

I thought "what will happen if I turn it on, will it start to download it again?". I tried and... Yes. It started to download 45 GB again.

Here's it downloads transcoded_video.foz again in folder downloads, though the file already exists one level above...

❯ 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
╰─❯
Image Image

I'm not saying that transcoded_video.foz should have less size but every day downloads (I should have tried to exit steam and start it again and just check) of the same size and the fact it's trying to download this file again though I did not delete cache makes me believe there is something wrong with lookup.

I also attach original shader_log.txt and share_log.txt (I copy-pasted content after a big chunk of mismatching like at the head of the file, to clear it up a little bit) of my today's activity: basically played the game, disabled shader pre-caching, enabled, saw that download started again, disabled, noticed that it downloads in the folder downloads, verified it by enabling and disabling again.

share_log.txt
shader_log.txt

I may be wrong, but maybe these issues are related:
https://github.com/ValveSoftware/steam-for-linux/issues/10486
https://github.com/ValveSoftware/steam-for-linux/issues/11949

❯ l fozpipelinesv6 | grep steamapp
drwxr-x--- 2 groni groni  40K May 14 12:47 steamapprun_pipeline_cache.2e6c105801134e9c
drwxr-x--- 2 groni groni 4.0K May 14 12:46 steamapprun_pipeline_cache.f8e37139bec012fd
❯ l fozpipelinesv6/steamapprun_pipeline_cache.2e6c105801134e9c
total 3.6G
drwxr-x--- 2 groni groni  40K May 14 12:47 .
drwxrwxr-x 4 groni groni 4.0K May 14 12:47 ..
-rwxrwxr-x 1 groni groni  20M May 14 10:13 replay_cache.d89520fbd1071ac127e73429ba54f0c0.foz
-rwxrwxr-x 1 groni groni 247M May 11 11:04 steamapp_pipeline_cache.foz
-rw-rw-r-- 1 groni groni  47K May 14 11:17 steamapprun_pipeline_cache.a6ad08581da78544.1.foz
-rwxrwxr-x 1 groni groni 3.3G May 14 12:47 steam_pipeline_cache.foz
-rwxrwxr-x 1 groni groni  39M May 14 10:13 steam_pipeline_cache_whitelist.foz
-rwxrwxr-x 1 groni groni    0 May 14 12:47 TOUCH
❯ l fozpipelinesv6/steamapprun_pipeline_cache.f8e37139bec012fd
total 1.4G
drwxr-x--- 2 groni groni 4.0K May 14 12:46 .
drwxrwxr-x 4 groni groni 4.0K May 14 12:47 ..
-rwxrwxr-x 1 groni groni  22K May  2 01:52 steamapp_pipeline_cache.foz
-rwxrwxr-x 1 groni groni 1.4G May 14 12:46 steam_pipeline_cache.foz
-rwxrwxr-x 1 groni groni    0 May 14 12:46 TOUCH
╭─ ~/.steam/steam/steamapps/shadercache/3513350 ············ at 03:07:28 PM
╰─❯

I forgot to add that before 45 gb re-download it downloaded 1.3 (or 1.4 gb, don't remember...)
So, I assume, I don't have duplicates, just two separate cache pipelines. And that c012fd is that have been already done.

Just my guess: that ~1.3/1.4 GB pipeline were replaying each day.

Aaxis6404 2026-05-14 github

I found a temporary workaround:

  • Delete ~/.steam/steam/steamapps/shadercache/1361350 (or your AppId) /transcoded_video.foz.
  • Pause the update temporarily and launch the game. The game will still launch even if the update is incomplete.