Get the complete compendium of troubleshooting articles. Download Now in PDF Format.
Back in the early 2000’s I was a DVR fanatic. My TiVO and ReplayTV collection and I were mentioned in a New York Times article on DVR users.
In 2003 the ReplayTV 5000 series DVR was released. In addition to the automatic commercial skip found on earlier models, this new model could send shows to a ReplayTV in another room or anywhere in the world.
Even with increased sales from the new products, 2003 was a bad year for the company. TiVO was the number one DVR brand and broadcasters were suing over commercial skip and show sharing features. It wasn’t long before legal costs overwhelmed their parent company, SONICBlue, which filed for bankruptcy protection.
Although the brand was acquired by Denon & Marantz Holdings under the DNNA brand, ReplayTV was struggling to survive.
During the ReplayTV 5000’s first year, users reported losing audio sync in some recordings. Video would momentarily freeze and after resuming the audio was seconds behind. It was only a matter of time before I, too, experienced the same problem.
After talking with tech support, I learned there were no developers left to fix the problem. I was an unemployed software developer taking care of two young kids. I had free time and experience with audio and video compression, so I decided to see if I could find the cause and fix it.
The ReplayTV recording format was known after hackers figured out the disk partition table and file system. Developers created utilities to access the files and those apps were shared on sites like www.avsforum.com.
That meant that by connecting the DVR drive to a computer, a technical user could extract recordings using command line utilities When show sharing was available, a utility, called DVArchive, allowed everyone to move recordings to a PC without pulling the drive.
DVArchive was a Java application that cleverly mimicked the ReplayTV networking protocol. A PC running DVArchive looks like a DVR to a ReplayTV, which allowed the two to share shows.
A recorded show is a large MPEG2 file. I figured the problem might well be caused by a hardware issue like a bad disk or MPEG encoder/decoder problem; a software bug; or a bad data stream.
MPEG video was designed to gracefully play through data loss and recover completely. Since playback wasn’t recovering it didn’t seem like a decoding error. This could be as simple as one bad key bit, byte, or value in gigabytes of data. Where to begin?
My brilliant idea was to ask users with bad recordings to send their recordings to my DVRs. After moving the files to a PC with DVArchive I had 15+GB of files to examine!
MPEG files are interleaved streams of audio, video, and proprietary system data. I trimmed each recording down to a few seconds before and after the glitch, hoping the problem existed nearby. I could only basically hope that was the case, because these trimmed clips played fine on my DVD players and with Cyberlink’s PowerDVD.
I wrote a program to parse the MPEG stream, so I could examine all data packets. After weeks of work I made little progress and the decoded data looked fine.
Because these recordings are generated in a closed system, I ignored much of the data frame headers except data type and size fields. I ignored the decode timestamp (DTS) and presentation timestamp (PTS) that are embedded in every data frame, which tell the decoder when to decode and present the data. I found these values may be ignored by MPEG decoders (including those mentioned above), which correctly play these clips.
Running out of ideas, I decided to check the time stamps, notwithstanding that I had absolutely no idea what constituted a “bad” value. Since encoding and playback rates are consistent, I decided to check offsets between PTS and DTS values in successive data chunks.
I got extremely lucky that among the thousands of values displayed a single negative PTS offset stood out. Could this be the cause?
I confirmed a bad PTS was set for seconds before the prior PTS. This jump backward was found in all shared recordings. Since a PTS is derived from the previous PTS, any error will propagate through until the end.
The fix was simple; I needed to recalculate the bad audio PTS and then update the remaining times. I shared my streamfix tool with users on avsforum.com. Users began fixing their recordings with my tool.
This troubleshooting escapade took me a lot of time, but it turned out to be well worth the effort as I enjoyed helping the ReplayTV community!
I shared my findings with ReplayTV, but unfortunately they never fixed their problem.
Jeff Davies is a consumer electronic hardware and software designer and developer currently working on intelligent lighting products. He loves tearing things apart to rebuild them to perform better than they did when new.
NOTE: This article is a submission to Electronic Designs Halloween 2018 "Double, Double Toil and Troubleshooting" Contest.