Use DeviceReadBuffer for HDTVRecorder and FirewireRecorder

[danielk]

Work around #551 for DVB recordings by implementing device ringbuffer.

This involves cleaning up the device ringbuffer implemented in HDTVRecorder and then bolting it onto DVBRecorder. This should allow you to format a partition on the same disk as your recordings without losing any data provided you have enough memory. I had planned to do this in 0.20, but now that the scheduler runs more often it ruins too many recordings to be acceptable. This won't help with PVR-x50 recordings thrashed by #551, but I'll let someone else worry about that.

[danielk]

Implements device reading ringbuffer, not quite done but usable.

[danielk]

updated to head, fixes some dvbrecorder issues, breaks hdtvrecorder

[danielk]

(In [8203]) References #712.

This is part one of two sets of innocuous changes to the DVBRecorder pre-DeviceReadBuffer? patch. The idea here is to seperate things that are unlikely to break things from the things that may, so there are no new features or bug fixes in this commit.

This adds a IsOpen?() call, it separates writing regular packets and PAT/PMT packets, it renames the and rearranges some methods and variables, etc.

[danielk]

(In [8205]) References #712

This seperates the device polling and reading portions of StartRecording?/ReadDMX from the packet processing. It also moves but does not change the PS stream portions to the 'to be removed in 0.20 portion of dvbrecorder.cpp file.

[danielk]

(In [8206]) References #712.

This commit could cause problems. It changes how PIDs are tacked, instead of using 5 QMaps and one vector to keep track of information about the streams, this creates one entry in one QMap to track the information. This means 4 less QMap lookups per TS Packet processed by the recorder.

This also changes the TS->PS transform to use the same keyframe tracking as the TS recordings, and to use the same source for constants instead of using it's own defines.

[danielk]

References #712. References #551.

This adds the DeviceReadBuffer? to the DVBRecorder. This is taken from the same functionality in HDTVRecorder written by John Poet, except it has been extended to allow for non-blocking file descriptors.

This doesn't close the ticket because I'd like to replace the same functionality in HDTVRecorder with the DeviceReadBuffer? with a non-blocking file descriptor. But this does make the rest of this is non-critical for 0.19. I've tested this by running 'dd if=/dev/zero of=/video/zero.tmp' while recording, there were no lost packets...

There are two important defines. If you comment out "#define USE_DRB" in dvbrecorder.cpp, it will fallback to relying on the buffering in the driver. If you change "#define REPORT_RING_STATS 0" in DeviceReadBuffer?.cpp to "#define REPORT_RING_STATS 1", then it will print out buffer usage information every 20 seconds.

WRT #551. I did my testing for this patch using the XFS file system. Brandon reported to me earlier this week that switching from ReiserFS3 to XFS made his problem much less severe even without the DRB patch (He had a problem recording multiple HDTV streams, triggered by a reschedule). If anyone reports disk write performance problems in the future we should insist that they switch to XFS or JFS before spending too much time on the problem. With ReiserFS3 the problem continues long after the reschedule, but with XFS the problem only lasts a few seconds and then goes away. Of course with this commit, neither file system should cause any problems to the DVBRecorder, but the bttv and ivtv recorders could theoretically experience similar problems (though in practice they have much less data to write).

[danielk]

removes hdtv specific ringbuffer and uses generic DRB, still has some shutdown problems.

[Mark.Buechler@…]

Just to comment on this, I have seen write performance issues with a PVR250 (on ext3) during times of load on the backend or raid resync.

• Mark.

[danielk]

Duplicate of #1660, which has patch for PVR-250 as well.