mythbackend logs RingBuf-messages every few seconds while playing LiveTV

[Kenni Lund [kenni a kelu dot dk]]

After upgrading from 0.24-fixes to master/0.25, the backend continuously writes out RingBuf? log messages about it waiting for data:

mythbackend[9601]: RingBuf(/data/mythtv/livetv/1001_20120310153618.mpg): Waited 1.0 seconds for data #012#011#011#011to become available... 130980 < 196608

While it does this, LiveTV works fine with no stuttering. The issue seems consistent on all channels in LiveTV and playing back recordings does NOT give the RingBuf? logs. Eg. playing back any recording - even the just-recorded LiveTV recording from the recordings menu - does NOT cause the backend to write out these messages.

Logs from ~5 minutes of LiveTV playback is attached. If more verbose logs are required to identify the issue, I'll be happy to provide them.

The tuner is a European HDHR dual DVB-C tuner. The backend is a 3.4GHz Core i5 with 12GB RAM and database+OS on a SSD, so it seems unlikely that this is a local performance issue.

[Kenni Lund [kenni a kelu dot dk]]

I forgot to add that disabling barriers on the ext4 file systems have no impact on the issue.

[danielk]

I think perhaps we are reading too close to the end of the file.

Does this occur if you skip back a few seconds after LiveTV starts?

i.e. start Live TV, wait 5 seconds, hit the back arrow. Do any new RingBuffer? messages occur in the next minute or so?

[Kenni Lund [kenni a kelu dot dk]]

Log illustrating the issue while skipping back and forward

[Kenni Lund [kenni a kelu dot dk]]

Heh, this is interesting :) When I start LiveTV the playback is 4-5 seconds behind according to the OSD. If I skip back once, it's 10-11 seconds behind, but still spits out the log-messages with the same rate as before. If I skip back once more, it is now 15-16 seconds behind and the log-messages disappear completely. I've uploaded a new log file, mythbackend_log_while_skipping.log, which illustrates this behaviour.

[Daniel Thor Kristjansson <danielk@…>]

In 483e06f6b8a9066f66cef3fcf0a5f844519f51f9/mythtv:

Refs #10428. Fix off-by-1000 error in RingBuffer?.

The estimated bit rate is in kilobits not bits...

Also increase the seconds of buffering from 0.25 to 0.35
for a better LiveTV experience.

[JoeB@…]

Hi danielk,

How do we apply this fix? Will it be in an update upstream in the MythTV PPA repository or do we have to do any configuration?

Thanks,

JoeB.

[Kenni Lund [kenni a kelu dot dk]]

JoeB, please use the mythtv-users mailing list for questions, not our bugtracker. The commit has been committed to master/pre0.26, and it will therefore at least be part of the soon-to-be-released MythTV 0.26. The commit might be backported to 0.25-fixes, if so, you'll see the 0.25-fixes commit here and you should be able to pick it up from the Mythbuntu autobuilds.

[danielk]

Fixed by [483e06f6b8a].

[Jean-Yves Avenard <jyavenard@…>]

In 43cba6537fae95cef0ff5ce6ba7352c52abcd947/mythtv:

Never attempt to read more than in 512kB blocks

Also increase the threshold at which we increase the read block size.
512kB ought to be enough to read a file smoothly (famous last words)

This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read.

Refs #10428

[Jean-Yves Avenard <jyavenard@…>]

In 801df9ec4c55df348ec821caf7fc0035300ea2a6/mythtv:

Never attempt to read more than in 512kB blocks

Also increase the threshold at which we increase the read block size.
512kB ought to be enough to read a file smoothly (famous last words)

This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read.

Refs #10428

(cherry picked from commit 43cba6537fae95cef0ff5ce6ba7352c52abcd947)

[Jean-Yves Avenard <jyavenard@…>]

In 1cfdfa3f56876eb20170f33e9592b5c7ffd05064/mythtv:

Never attempt to read more than in 512kB blocks

Recalculate the threshold and read block size when we've encountered EOF several times in a row.
512kB ought to be enough to read a file smoothly (famous last words)

This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read.

Refs #10428

[Jean-Yves Avenard <jyavenard@…>]

In 24aa672b0486ef723c1e4ee15fe66dc3a2334c48/mythtv:

Never attempt to read more than in 512kB blocks

Recalculate the threshold and read block size when we've encountered EOF several times in a row.
512kB ought to be enough to read a file smoothly (famous last words)

This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read.

Refs #10428
(cherry picked from commit 1cfdfa3f56876eb20170f33e9592b5c7ffd05064)

[Jean-Yves Avenard <jyavenard@…>]

In 57c32eacfa87783b75412184cc98c6a46dea99c0/mythtv:

Never attempt to read more than in 512kB blocks

Recalculate the threshold and read block size when we've encountered EOF several times in a row.
512kB ought to be enough to read a file smoothly (famous last words)

This reduces the amount of unnecessary verbosity. When watching a SD 3Mbit/s DVB stream, it will take over a second to get 1MB of data, leading to a warning entry in the log for every single read.

Refs #10428

(cherry picked from commit 1cfdfa3f56876eb20170f33e9592b5c7ffd05064)