Merge pull request #5 from MythTV/fixes/0.26

dtvrecorder: Don't try to buffer frames for audio-only streams.
Merge pull request #6 from MythTV/fixes/0.26

Fixes/0.26
Python binding to stop current recording MythTV Trac #11191
Cleanup some trailing whitespace
Cleanup white-space
Improve DeviceReadBuffer debugging.
(cherry picked from commit 032f290bedb682fff4b2d3c4508f3a715d57bb11)
Use nothrow new[] to allocate buffer in DRB.

This allows us to handle failures to allocate the potentially large
buffers without the program exiting when compiled with exceptions
enabled (the default).
(cherry picked from commit 75e5530925ecf2d4161036ef23b088b9fd4dccb8)
(cherry picked from commit 093057f9ff1bd6457a03d8973d710c03a8bc949e)
Reduce # number DeviceReadBuffer::Read() calls.

Refs #11252.

This reduces the number of reads per second we make in the stream handlers
utilizing the DRB. It does this by waiting 20 ms for at least dev_read_size
bytes rather than 500 ms for min_read bytes. The device reads are larger
than the minimum read so this actually results in waiting a bit longer
under normal conditions while returning more quickly when we're not getting
data from the device. A win-win.
(cherry picked from commit 6912383b2c0c59df12aa9c8af521200fbe4e585d)
DeviceReadBuffer: Try to optimize some of the busy-waiting.

Wait for readThreshold or 20 milliseconds before returning to the stream
handler.

Move the throttling "sleep" from the stream handler into the DRB run loop.

Original patch by Rune Petersen.
Closes #11252
(cherry picked from commit 4f0bfd9d1eeff9397fe9386b905567b0e499dcb9)
DeviceReadBuffer: Deal with device drivers which segment their internal buffers.

Some device drivers segment their buffers into pieces, and will return at
most one "piece" at a time.  For efficent processing, we may need to process
more than one "piece" during each loop.
(cherry picked from commit bbfdaceeefdbfe37de3fcac49f37ccfda7d2aa6c)
ASIStreamHandler: Detect how many driver buffers are available, and attempt
to read 1/4 of them during each pass in DeviceReadBuffer.
(cherry picked from commit ee5ac3d3adb36f4ac7223cd98ae1ed66048f7388)
Cleanup white-space
This is a simplified version of the no-timeout patch.

This prevents MythTV from abandoning a recording when there isn't
a signal for 3 minutes.
See ac554f9 for 0.25-pre version
Extends timeout for caption extraction.

This is probably not the best way to handle this.. The problem is if the recording file stops growing
for a few seconds we time out. This allows you to extend the timeout with the --endtime parameter and
by default sets the endtime to 1 hour after a recording started (if it is using mythtv naming conventions.)
(cherry picked from commit 0112efc046ebf14780503ee12d36fd9ff9228c3b)
Add SRT_TO_ASCII and SRT_TO_LATIN1 defines that change SRT character set.
(cherry picked from commit 659e17af7a2cc3ab24f6adf00b6d7407f0fa64b3)
Merge branch 'fixes/0.26' of github.com:sivchandk/mythtv-stabilize into fixes/0.26
Revert "Add SRT_TO_ASCII and SRT_TO_LATIN1 defines that change SRT character set."

This reverts commit b9e71b1306fd02453dfe8d840ad201df7c58f2fd.  This
functionality has been replaced by UTF-8 support.
Refactor: The two SetNextRecording methods are identical, move to base class.
(cherry picked from commit d945642da6bd23c79a2d7c45e372751dc256f027)
Don't leak nextRecording or nextRingBuffer.

If a recorder was deleted after SetNextRecording has been called it
would leak a RecordingInfo and a RingBuffer. The RecordingInfo is
no big deal but the RingBuffer is holding an open file descriptor
and the application will start to misbehave if after we leak just
a few hundred of those since select() will no longer function
correctly.
(cherry picked from commit c1c09f7dfd1216d1124232d61867d3801c6e4a85)
Make RingBuffer::WriterFlush() only flush data not sync it.

The reason we do syncs of the data is so that Linux doesn't build up too
many bufferred writes and freeze up the system later on writing many
GB to disk at once. However the amount of data typically flushed in
this call is not going to greatly increase the amount of data that will
need to be handled on the next fsync and this sync is causing
DTVRecorder::SetNextRecording() to take several seconds, hence
delaying TVRec::SwitchRecordingRingBuffer() and TVRec::StartRecording().
Since TVRec::StartRecording() blocks the scheduler this can mean
recording on other recorders is delayed by several seconds for
each other recorder starting a recording at the same time.
(cherry picked from commit 2b74a688c41882e373471d54c261642dce05d2c3)