Currently when creating ShaderNodeTexImage nodes like this:

import bpy
import os

filepath = os.path.expanduser("~/Desktop/test.png")
img = bpy.data.images.load(filepath)
mat = bpy.data.materials.new("Frame Duration Test")
mat.use_nodes = True

node = mat.node_tree.nodes.new(type = "ShaderNodeTexImage")
node.image = img
node.name = img.name

print(f"frame_offset: {node.image_user.frame_offset}. Should be 0")
print(f"frame_start: {node.image_user.frame_start}. Should be 1")
print(f"frame_duration: {node.image_user.frame_duration}. Should be 1")
print(f"frame_current: {node.image_user.frame_current}. Should be 1")

the image_user for the node will be configured with the following settings:

frame_offset: 0. Should be 0
frame_start: 1. Should be 1
frame_duration: 100. Should be 1
frame_current: 0. Should be 1

which leads to the image being used like an animated texture.

And in case of rendering an animation, this image_user configuration makes ImageLoader comparisons fail in ImageManager::add_image_slot (frame will differ). This way the image manager will allocate new image slots for the misconfigured textures each frame. In case of Persistent Images option enabled, old slots will never be freed, so the memory usage will grow with insane rate each rendered frame (as described in T78537).

This patch proposes to set the image_user defaults to:

frame_offset: 0
frame_start: 1
frame_duration: 1
frame_current: 1

suited for the single image textures, as the most used texture type. With this configuration the insane memory use issues will be avoided when rendering animation that use textures imported by script like in the example above. The wrong image_user configuration may be easily fixed in the script that create the nodes. But considering there are existing popular scripts that do it this way (never settings the appropriate image_user settings), and the fact that the high memory use issues cause isn't obvious, I think it's better to change the defaults.

The reason for the hardcoded default frame count of 100 is unknown for me. And I leave this question for the reviewers. It seems to be introduced in rB0a4cded91eed.