Yes, I am indeed saying that it wants to keep the shows defragmented, and the idea of deleting the best candidate rather than the oldest show is in the interests of keeping the the free space as well as the shows as defragmented as possible. That is how it works.
I work every day installing, maintaining, and fixing media servers and large collaborative media storage systems spanning beaucoup TBs, and I have been paid well for doing that for many years, so it is not that unlikely that I might have learned how such things work along the way. And a DVR is simply a dumbed-down consumer version of a professional media server.
A HDD in a typical PC scenario can fragment files or available space all it wants; it is not unlikely that a well-used HDD on a PC that is a couple of years old may have 300,000 files or possibly many times that, with even more fragments than files. I've seen single files that have as many as 3000 fragments. My MacBook Air has exactly that scenario. But since the other 99.999% of the public does not have my job it is not all that surprising that they may have "never seen any behavior like this". But this particular scenario, a DVR with a constantly-full HDD primarily used to record 30-minute and 60-minute shows that is asked to record 6 and 8-hour blocks of the Olympics for 17 days on end, is the perfect-storm scenario for such issues to begin to manifest, and this very thread is proof that they do.
A streaming media server abhors fragmentation for two reasons; it needs to have successive sectors of a file as physically close to each other as possible, and it needs to try to record while fragmenting the free space as little as possible, because if you don't do the second thing well, it makes the first thing that much harder to do over time. And it wants to do that to be able to maintain a simpler more reliable database, to be able to stream media at the fastest possible rate and avoid stuttering, and to efficiently use the space files are recorded in, all goals that are not really important on a PC, and are usually not taken into account.
For that reason, recording of streaming media needs to pre-allocate space before recording. On a DVR it pre-allocates an entire 30-minute contiguous chunk of space for a scheduled 30-minute recording of known length. There is some wiggle room due to varying bit rates, but it tries to be as exact in that regard as it can. And most media servers that will do a crash record (press record without knowing how long the recording will be) pre-allocate on the fly, a chunk of available space at a time, every 300-800 MB or so, which is why that is called "chunking". But it attempts to do that in contiguous space with one successive chunk adjacent to the next. And it makes decisions about what to delete among shows not marked to be saved, based on what the best candidate might be, and usually with the oldest shows being deleted first, but not always, because there are other attributes that determine the untimate best candidate for deletion.
So it is not a theory; it is a fact. That is how media servers work. And you are not unlike most people; never in their lives have they been presented twith this either, because it's not your job to understand it, and there is usually no good reason that the customer needs to see the details of how the sausage is made. But sometimes understanding something is also key to being able to explain what some see as puzzling behavior, and that behavior is only puzzling until they begin to understand and stop guessing.
Yes, KUID should always delete the oldest shows, and it always does, because that is essentially a direct command and there is no decision made in that scenario by the space management algorithm of the server, nor is there any need for it to. But "delete when you need the space and the HDD is otherwise full" is completely different and is indeed based on intelligent decisions made by the space management algorithm, which tries to but does not always erase the oldest show if there are shows that are better candidates for managing the DVR better. Only it knows, and it knows better than we do, and it is based on how things stand at the moment.
And you will only see these sorts of things happen if the HDD is nearly full, and usually only if unusually-large recordings are made with it full. And if everything is KUID, it simply stops recording. But any file not protected from deletion is a potetial candidate to be marked the best candidate for deletion, regardless of whether it is the oldest show or not. End of story.
Edited by TomCat, 25 February 2014 - 08:42 PM.