I'm retired now, but I spent over 30 years in the computer industry mostly as a systems programmer and many of the last years working on Unix and Linux systems. One of the jobs of a systems programmer is to determine and correct performance problems. I don't claim to know how D* DVRs are programmed, but I know that they use a Linux operating system. Linux is a virtual system, which means that real memory is divided into pages. Many of the pages are fixed and not eligible for swapping. A good portion of the Linux operating is fixed and also any pages used for I/O operations are fixed. I believe the performance issues we now see on the HR2x systems is due to a thing called thrashing. http://en.wikipedia.org/wiki/Thrashing_(computer_science) Thrashing is caused when there are so few pages available for paging, the paging rate becomes excessive. The best solution to this problem is to increase real memory. Since this is not possible on existing HR2x systems, another solution needs to be found. I sometimes wonder if the programming staff at D* has any system level programmers and if anyone knows how to solve these problems. If they could streamline their code to make it smaller or find ways to free up some of the fixed pages it would help. Another way to help the problem would be to make all the crap they have added lately optional. There are some things we can do to speed things up. If you want to add an external disk, get one that is high performance. The 5400 rpm green disks will not perform as well in a system that is doing heavy paging as a 7200 rpm disk. Also, the Linux file system is much different than the file systems used by Windows. Linux uses a journal to keep track of which sectors on disk are available, to chain disk segments together for large files, and to prevent disk corruption in case of a system crash or power failure. The journal resides both on disk and in fixed memory. The larger the disk, the more pages need to be fixed in real memory to hold the journal. Those of you that have added a 2 TB disk have caused the number of pageable pages to decrease and probably contributed to thrashing. Any I/O pages must be fixed. If you are using Dual Live Buffers or Multi Room Viewing or a connection to the Ethernet, you are causing pages to be fixed and possibly causing the system to thrash.