I disagree Eugene - data is data whether or not its part of a program or a video stream. If any corruption occurs due to magnetic head relocation (or any other effect) the storage controller on the disk itself will complain and inform the OS of the fact - eventually the message will reach you as the user. The GPU cannot do magnetic data retrieved integrity checking as you say

The storage controller knows nothing about the difference to the owner/operator between "data" and "video" - its job is to reliably manage 1s and 0s filling up sectors on the drive and the built-in error correction algorithms makes it impossible to present to the operator/owner/user a sequence of 1s and 0s OTHER than that that was intended - even a single bit incorrectly retrieved from the magnetic surface is detected before its presented to the OS and its corrected along the error correction algorithms before being sent out to the OS. There is sw that can investigate the health of disks that will analyse and look at the error correction logs on the drive itself (any errors/retries/etc etc is automatically logged on/in the drive firmware). If your OS gets presented with corrupt data (even the smallest bit) from the storage controller/driver your Windows error logs will also be full of complaints

You cable box is a dumb cluts (when compared to eg the PC) and has no intelligent OS to communicate the failing of a drive to you unless its of a catastrophic nature - the read/write retries on the failing drive there (what you are talking about effectively)  basically only prevents the timeous presentation of data to the box' processor and its overall design simply acts as if it couldn't care - rather create a drop-out or miss part of the movie that prevents the viewer from missing the movie altogether. 

Read retries are basically the first indication that the drive's error correction mechanisms detected/figured there is uncorrectable corruption present - it will continue to try and read/re-read the required sector while trying to apply the error correction algorithm (while halting data retrieval for the OS altogether) and unless the error correction eventually after many read tries  (function of firmware parameters) give up, absolute reliable data will always be presented to the OS - it may take a while due to the re-reading/re-checking of a detected funky chunk of data on the media, but reliable data will always be presented to you. In your situation where the output is created in file form, the additional re-reading/error correction/checking will simply manifest itself ito a longer production time. If the controller cannot retrieve data reliably the OS will undoubtedly complain because most all drives are designed to continue re-trying to re-read funky chunks of data untill it either can or it eventually reports a failure.

As for the evening thing - nah - been up 2 hours now and currently on my 3rd cup of morning coffee here