Hi Annet,
When you save a file, so I can look at:
Main Menu>File> Save Project with Assets…
The key file in your question is missing. I assume that is the Environment/Context? If so…
HDR001_4000x2000.hdr (HDRI_01)
Let me start with, HDRi is only producing problems (and misses advantages) if you don’t use Motion Blur, or Depth Of Field, or Global Illumination. IF you don’t use any of them, use a 16bit/inter/channel instead. Please note, that the Background image should be in agreement with the middle/fore-ground. It is even often practice to have a low resolution HDR image for Light information, and a larger resolution for the background. But with your length of aniamtion and as you mentioned previous, you are interested in short rendertimes, I would stick with 16bit/channel - integer images for 360ºx180º on a Sky object.
For HDRi: All I can tell you now is, that you should avoid the hdr [radiance] format at any time for professional work. It is not a 32bit/float per channel format. The only useable idea I have about is to store (if at all) high brightness values, like ten times the sun. HDR radiance has 8bit per channel, but four channels. I try to get this format since over a decade out of projects, but since it is so limited (e.g., in color values) people give it away. It might be good for GI, but even there it is very questionable. Yes, they are small, and that is perhaps the only reason why MAXON even put them into the Content folder. I never got any other idea about it.
If you want quality work, use OpenEXR. But OpenEXR is just a container, to just save an “.hdr” into it, will not do anything good at all. People do it anyway, I know.
Besides that, the size, if given correctly in the name tells me already, that it was not provided by someone who works a lot with it, and that it is way too small. Your camera has a field of view of 53.13º, the default. This is roughly 1/7th of a full circle (360º). IF you take now the 4000 pixels and divide this by 7 then you get something around 571 pixels for your camera view, given an infinity sized sphere. The minimal quality rule is that one should have for camera rendered backgrounds at least 1.5 times the resolution, to get an at least acceptable quality, around 857. Since background pixels never match rendered pixels. Your setting for the final output is 1280h and that is already much bigger than you have in the HDRi. If you go to HD or the current new standard UHD, then the background would look very pixelated. The 4000x2000 is just enough for SD 720x576 BT.601 for example. Since hdr can contain super high values the anti alias might screw up as well in some areas.
Another part that is not often discussed is the color space and the gamut of HDRi. Often one gets an image that is not calibrated. The only real value that one can get is a 50% or 0.18 gray-card reading. There is not defined black point, not a white point. A white point in 8bit/channel or 16bit/channel integer is only the point where things clip, and that sets all information to equal, hence no saturation and the result is white. If lower it would be gray.
This assumption of white leads often to misleading ideas that there is a white point, and people set it that way, to get a print for example. In High Dynamic Range, that white might be the sun, but one can’t calibrate an image with values million times below the sun with the sun. Hence my practice to use a gray card, the only agreed fixed value at all. Then one doesn’t have to deal in a correction [sic] into the scene.
If you don’t get a gray card nor a “MacBeth Chart” with the image[s], as extra image, don’t use it, or use it very carefully. Anything else is from my point of view a risk.
So quality in, quality out.
I have made a whole series about HDRi, see link below. And yes, I’m pretty picky about quality in photography. 
I will wait for the image.
All the best
