You could also click your heels together three times and whisper "there's no place like home".
That would probably be just as effective.
And, wait a minute, isn't the HR24 supposed to be powered with a CPU at least twice as fast as earlier DVR models? Kinda seems to support the theory of the DVR just being too busy doing too many things (things not asked of it before all of the crap features that have been added) and that it is thrashing because of that. True, that is also just theory, but much more well-supported than some of the ridiculous things we see on these forums.
If something (that fixes sluggishness) works, it works, and that's valuable information. What is not valuable is a ton of superstitious behavior surrounding this subject that just confuses the issue. There is also a lot of "faith" in procedures we do not understand, and faith is no substitute for understanding. If you understand the process you can understand why a particular change in user behavior may or may not make a difference to that process. If you don't understand, you are left with superstition and faith, and neither of those have proven to be all that reliable.A "full" HDD is just one example.
I wonder how a file on a HDD, a file that I am not accessing
makes accessing other files on the HDD slower? It can't, since it is technically removed from and physically outside of the current, ongoing HDD R/W process, by definition, to begin with.
Were this file or all of these files that filled my user partition also on the partition where the OS and everything else is, it might have some bearing. But it isn't, so it doesn't. Really. How could it possibly?
On top of that is the empirical proof that I have that filled HDDs and proven that it has no bearing at all on speed. I have done it numbers of times on HD DVRs and it has had ZERO effect, each time. On a PC, well that's different. Files fragment on a NTFS PC; they don't on a Linux-based DVR. Virtual memory paging files expand dynamically on a PC (unless you have the sense to fix the size so that they don't) and that can be hampered by a full HDD when the data is being written to the same partition. That does not happen on a DVR, which keeps media on a separate partition. What slows a PC HDD by being full just does not apply to a DVR HDD.
OK then, how about the fact that a full HDD has a large database while an empty HDD has a tiny database?
The answer there is that the database under practical use never has much more than a thousand entries. If a 2 TB HDD can hold less than 500 hours of programs, the DB can't really be all that large, can it?
Plus, a DB is indexed which speeds read access to the DB. And even a low-level pro database like SQL Express can search a thousand entries in less than a second, which, yes, might take a couple more seconds on a DVR with a slower processor than your garden-variety professional media server. Is that significant? Is that why the DVR is sluggish regardless whether the DB is being accessed or not? Hardly.
That will not account for the remote taking 6 seconds to respond, especially if you have highlighted one program in the guide or program list and pressed the down arrow to highlight the visible line below it. If you want to know how long it takes to search the database of recorded programs, just resort your program list (and if you want to know how long it takes to search the guide data DB, try Smart Search). Even on a full 2 TB HDD resorting the program list will take only a few seconds. That's normal. But 6 seconds to navigate from one item to the next one in the list? There has to be another explanation for the sluggishness, because the DB is not being accessed for that particular task.
And simply scrolling the page down also does not search the entire database; in fact that happens at the moment you press the list button, whereupon the first few entries display pretty quickly, and the other entries first churn in the background and then are ready waiting for you to scroll down (or back up).OK, here's another "useful" tip: flush that nasty guide data.
At least that will make you feel better
Really? Might just as well try a little Immodium. The guide data is only accessed by low-level indexing processes in the background, and when tiny portions of it are read into the GUI on command (when you display the guide). Low-level processes are supposed to be pre-empted by high-level processes such as "respond to that button press" or "Record CH 249 now". The high-level processes should never be sluggish because ofissues with lower-level processes. A design strategy that didn't do that would have no reliability at all.
Flushing the guide data is really only useful if the guide data is corrupted and it is hanging your DVR needing it to be reset, or making it act erratically. That's why its not in the manual and is kept in the back pocket of technical support (until the internet outed it, that is).
And what is the first thing that happens when you flush the guide data? All of that meticulous, intensive background indexing that your DVR has been doing for the last nine days is thrown right out the window, and it has to start over from scratch. You just added a new significant task load to your already-sluggish DVR that it will have to do all over again, and those processes are now again in competition with whatever the real churning process logjam might have been. Good for you.
And that's just two or three.Here's another: Flush that stinkin' NVRAM.
If flushing the NVRAM was helpful, why would that not be a routine that the DVR does on its own at startup or shutdown? Or when the screen saver kicks in, or at any other low-use time? Why are only the smartest guys in the room allowed to know that trick? If you really are
one of the smartest guy in the room, I don't need to elaborate and provide the answer (hint: there is no good reason for any customer to know this). But it makes you feel like you've done something; it alleviates that horrible feeling of not being in control, at least for about as long as the few seconds it takes to either realize that it really didn't work, or for most of us, to imagine and pretend that it might have.
Knowing that your DVR is slower than it once was is one thing, but wildly jumping to a premature conclusion that this is because of something it can't possibly be is just ludicrous.
Bottom line, take the advice on this forum with a giant grain of salt and understand that much of it comes from really wonderfully-earnest and good folks who, while their hearts are in the right place, just might not have the first clue regarding what they are talking about.
Edited by TomCat, 27 July 2012 - 04:49 PM.