I have just started using a (5400 rpm green) Seagate Backup 4 Tbyte external USB 3 hard disk drive with the Homeworx HW-150PVR. It was on boxing day sale for about CDN$159.95. I expect that in a few years there will be 20 Tbyte HDD available inexpensively: plan for the future rather than cling to the past. For example in 1982 10 Mbyte HDD were available, but by 1991 SCSI 2 Gbyte HDDs became available. In 2001 40 Gbyte HDD became available. In 2010 2 Tbyte were on store shelves. By now, you should see the trend... Every few years storage capacity increases significantly. Just wait a short time and 4k Ultra HD might be compressed onto the airwaves and the resulting file sizes will be huge, needing the growing HDD capacities.
The 4 Tbyte Seagate Backup HDD was easily detected. The free disk space was displayed as 3.7+ Tbytes. I recorded 2 scheduled programs: 14 Gbytes, and 20 Gbytes.
When I pressed the USB button on the IR remote, the PVR hung for a number of seconds, then the PVR spontaneously rebooted, however, the alternative way to access recordings is via a longer button sequence: Menu, arrow keys to USB, OK on USB, then the file system was displayed rather than the machine crashing. I could navigate to the folder where the shows were recorded, then select and play them back. The USB navigation should start in the folder / directory where PVR recordings are normally situated in order to save lots of IR remote button presses. For example, the root directory of the HDD could have 500+ preexisting files stored so that many IR remote key presses of the direction / arrow buttons would have to happen just to find and select the PVR's folder for its TV program recordings.
When I first had pressed the USB button and the PVR rebooted, I shut the system down, then connected the HDD to my Windows 7 computer where I found no file system corruption and was able to see the saved files and run MediaInfo on them that showed that the .mts files were mpeg-2 and had several audio streams including 5.1 surround (6 channel). I watched one of the shows via Windows Media player. It seemed fine. I then safely disconnected the HDD and reattached it to the HW-150PVR, then discovered the alternative Menu sequence to access and playback the two files.
If the PVR accesses the HDD via 32-bit offset integers rather than 64-bit, then I would expect that file system errors would start to happen when the disk space used approached, then exceeded the 2 Tbyte limit for 32-bit or 48-bit LBA systems.
I noticed that most USB 2 external enclosures had maximum capacities of 2 Tbytes, but those of USB 3 drives were quoted as the maximum size of a HDD at the time of product manufacture. I also got a Vantec USB 3 / eSata HDD enclosure that can hold and use a 4 Tbyte HDD so that if the Homeworx HW-150PVR could not access the 4 Tbyte unit, I could use one of my existing other HDDs in the USB 3 / eSata enclosure.
I just noticed that the pause / time shift buffer: it is way too small. The configuration menu selection for pause / time shift buffer size should not be specified in Gbytes, but instead in minutes or hours, and instead of having a fixed set of 4 or 6 choices for the pause / time shift size setting, the amount should be a double floating point value. The rational for this assessment is that I wanted to be able to see what was on 8 hours ago, but could only rewind about 5 to 20 minutes or so, depending on the bandwidth compression of the mpeg-2 stream from the originating TV station.
The pause / time shifting function should be the default, ongoing activity of the PVR so that live TV can be paused - time shifted or rewound at any time. A part of the pause buffer could also be "included" in any current show that is selected for recording.
A recording and a time shift / pause operation should be transparently identical. This means that the user should be able to pause a Booked / scheduled recording, then rewind it, fast forward and so on.
The EPG, current show selection, schedule / Book a recording function should not reject a user's request if the station's scheduled time for the start time of the show has already elapsed. This never happens in a Cable TV company's HD PVR such as the Scientific Atlanta / Cisco Explorer 8300HD. On this PVR the user has to arrow to the start time and guess as to what the current time plus 1 minute would be, then enter it quickly in the provided space, then OK the recording Booking / schedule item in order for the PVR to accept it and do the desired show recording. The longer this process takes to do, or if the user has to guess the time too far in the future, the more of the TV show recording is missed in the mean time. If the above suggestion of the pause / time shifting is done, then none of the current show's recording would be missed by the PVR--a very good feature that routinely happens on the Cable TV company's Scientific Atlanta / Cisco Explorer 8300HD PVR.
When the user leaves the PVR tuned to a TV-station with an inaccurate Date/Time stamp, a scheduled / booked recording on a different channel having somehow a different Date/Time stamp, the recording start up can be missed. When I switched to the needed station, the PVR then began the recording, but was 6 or more minutes late to have included the beginning of the scheduled / booked TV show.
This key unreliable time keeping bug of this PVR is a key reason why its sales are not higher because product reviewers who see this happen only see a very broken / error prone functionality that is not easily explainable.
Two solutions to this problem are as follows: maintain a local copy of a designated accurate date/time stamp, or always keep a date/time stamp set initially by the user. The user could specify a particular TV channel where they feel that the station maintains the most accurate date time stamp. Should there be a power failure, the PVR could recover "the accurate date / time" by visiting first the user-specified TV channel to get this value upon first reboot (or whatever). This reference time would be used as a benchmark time for scheduling on other channels whose date/time stamps could be inaccurate. The PVR would then know to compute date/times adjusted to the reference / PVR maintained time rather than the other TV station's EPG provided date/times. In fact, the other TV station's EPG - provided date/times could be adjusted and displayed in reference time "units."
The IR receiver is not very responsive. Either or both problems should be addressed: (1) the IR sensor receiver circuitry is badly implemented, (2) the software is designed with too low a priority assigned to the task of IR remote signal handling so that codes can go missing on a frequent basis. If the CPU is too slow, upgrade its speed in future production. If the operating system is not multitasking with a wide variety of tasking priorities, then improve it so that it is better. Test the results so that the slow IR response is fixed up nicely.