Why does Emby simultaneously write a duplicate (temp) copy of each DVR recording?

[sjabaker 9]

Can anyone clarify the reason why when Emby is recording something (as a scheduled DVR recording), it not only writes the programme as a .ts file in the appropriate TV show or movie folder (with the relevant filename), but also simultaneously writes a duplicate .ts file (with a random alphanumeric filename) in the transcoding-temp folder, which is then deleted once the recording ends?

When I first noticed this behaviour, I thought perhaps it might be to support the "timeshifted" playback of the programme while it is still being recorded (though why a duplicate file would enhance that isn't clear) - but when I tried starting playback during a recording it just started additionally creating the dozens of very small .ts files that are normally used when "transcoding" (actually just DirectStreaming), the same as when no recording is taking place.

Why does Emby do this duplicate-writing? Is it not just placing unnecessary load on the system?

[Carlo 4561]

It was likely done this way to handle some of the different quirks of the many devices/apps that Emby had to support.

This is changed in the new version of Live TV nearing completion.  So it won't be this way in the near future.
Sorry can't give any dates or timeframes yet.

[sjabaker 9]

Thanks for that; good to know - and no worries about as-yet-unknown timeframes.

Aside from technical curiosity, my main reason for wanting to know was that I was considering a new 'server' machine and potentially looking to put transcoding-temp onto a RAM-drive... and the difference between capacity to handle a single stream of transcoding (my only actual use case) vs having to allow capacity for all parallel recordings (e.g. perhaps 4 multi-hour HD movies) could've been quite expensive in mostly-unused RAM! Now I know I can just plan on the basis of the more reasonable future-state scenario.