You are correct that USB 2.0 is Half Duplex but you are misunderstanding what half duplex is. With half duplex communication can only travel in one direction at a time. So you can send as little or as much traffic as you wish up to some max (not the theoretical max) in one direction at a time. You could not however have in your example 15MB going from the box to the drive while concurrently having another 5MB coming the other direction. Add to that the overhead involved in each conversation, the control and buffering of up to 6 conversations and USB 2.0 just is not going to do it. If and when Dish receivers have support for USB 3.0 which is Full Duplex then it will be viable as the total bandwidth would be split between all active data conversations which can take place both up and downstream concurrently. You can verify this yourself if you care to give it a shot. If you have a USB 2.0 drive that you can attach to your computer first try copying a single file from your computer to the drive and see what your throughput is. Next do two concurrently. Now keep upping the count until you not only are copying 4 to the drive but also 2 from the drive. You'll see that as you add more and more concurrent transfers to the mix your overall performance drops.
I am not misunderstanding half-duplex at all. 20MB/sec is 160Mbps, versus the "theoretical" 480Mbps that USB 2.0 can support. The overhead is already taken into account, thus, the reason it is 160Mbps and not 480Mbps. You are right in that in half-duplex, data is only sent one direction at a time. That is the very reason that the 20MB/sec average transfer rate is split between up/down. It's just like Wikipedia states, think of half-duplex as a one-lane highway, with traffic controllers on both ends, only allowing traffic to flow in one direction at a time. What you seem to be leaving out though, is the fact that the USB traffic changes directions in a matter of milliseconds, thus, allowing traffic in both directions, near-simultaneously.
Think of it this way: If the connection is capable of 20MB/sec down, while sending nothing up, then it is spending the full time sending that data downwards. Though, if you are trying to send another 20MB/sec up, while still maintaining 20MB/sec down, well, since it is half-duplex, the time spent sending data up and down is split (half of the time is spent sending, other half is spent receiving,) thus, 10MB/sec up and 10MB/sec down.
Same applies to 15MB/sec going to the drive, and 5MB/sec coming from the drive, less time is spent on data coming from the drive, thus, more time is allocated to sending data to the drive, thus, more bandwidth in that direction.
If it was full-duplex, it could just send the data both ways at full speed regardless, as there are separate "lanes" that are independent of each other.
Ethernet is full-duplex, thus, 100Mbps Ethernet can handle 12MB/sec up and 12MB/sec down (96Mbps up, 96Mbps down, including overhead.)
If anything the real limitation here is most likely the DVR's CPU. When data is being transferred to/from the EHD it is being encrypted/decrypted. Thus, for 4 streams being recorded, and 2 streams being played back, there is a good chance that it is too much for the CPU.
