I wouldn't be surprised if this is a consequence of local ad insertion technology. If you think how 30 sec skip must work, it makes sense...
To jump 30 seconds forward, the software has to calculate the offset in the digital file that represents 30 seconds later. If the stream is redirected in to a different file, the offset becomes invalid and the playback drops back to the stream. This is why slip and fast forward still work, they follow the stream, not file offsets.
To fix this, they will have to look ahead on each skip and see if there is a local ad insertion coming, and recalculate offsets going in and coming back to the main file.
It might make more sense to think about how skip and slip actually do
The statement "If the stream is redirected in to a different file, the offset becomes invalid and the playback drops back to the stream."
both makes no sense and sort of indicates one of two things:
1) you have no real idea how this works
2) you may have an idea, but don't have the wherewithall to explain it properly
But that's OK, you probably do not have the "luxury" of working with this all of the time as some of us do. The files are compressed MPEG program stream files. A few times every second or so there is metadata in the packet headers of the video elemental stream (which is one of many simultaneous streams in the PS) called a Presentation Time Stamp, which is analogous to the running timecode in analog video. Since video files can be accessed non-linearly, it needs to read this PST both to know where playback is, referenced from the beginning, in the file, and to play back the frames in order, especially since they are purposely sent out of order as part of compression efficiency and robustness.
The PST is reconstituted at record, meaning whatever it is coming in is replaced with a new clock on the recording that starts at 00:00:00:00 and continues unbroken until the end of the recording. And as you say, skip and slip use this PST to calculate where to FFWD or jump to.
But there is nothing that distinguishes where a commercial begins and a program segment ends; all of that is by now invisible. Broadcasters learned long ago that if they did put some identifying metadata into the stream that clever techies would find that data and use it to create a commercial-skipping algorithm, and for that reason they will probably never do that.
There is however metadata that can defeat FFWD; anyone who has ever played a store-bought DVD knows this well, and is why we are treated to a nice long FBI warning logo each time we insert a new DVD.
Slip and skip are also not very accurate; they are only approximate because they are only GOP-accurate, not frame-accurate. Find video with a running timer including seconds, and try to skip or slip through that; press the button ten times. Will that be exactly 3 minutes? Rarely, and only by accident. It will be different each time, and different for the same video for skip compared to slip.
This is because it would take too long to decode the frames that are 30 seconds away to find the PST; it is quicker to decode just the I-frames (which decode faster) and not all of them but every Xth one of them, which helps prevent skip and slip from having decoding latency and allows decoded video frames to represent slices of the video as it goes by for slip. The tradeoff is that it isn't exactly 30 seconds, its approximately the number of GOPs that would represent "about" 30 seconds.
While DTV and others may be using technology to thwart FFWD, it is not unusual for the DVR just to simply get confused about the PST should the file get corrupted, whereupon skip and slip, both dependent upon the ability to read PST, just fail to be able to do that at a particular corrupted part of the stream. Sometimes this throws the file back to the beginning (00:00) because it no longer can determine where it is and just defaults there.