Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 2 years ago

Closed 21 months ago

Last modified 7 weeks ago

#10428 closed Bug Report - General (Fixed)

mythbackend logs RingBuf-messages every few seconds while playing LiveTV

Reported by: kenni Owned by: danielk
Priority: minor Milestone: 0.26
Component: MythTV - Recording Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: yes

Description

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.

Attachments (3)

mythbackend_RingBuf.log (59.1 KB) - added by kenni 2 years ago.
mythfrontend_RingBuf.log (44.3 KB) - added by kenni 2 years ago.
mythbackend_log_while_skipping.log (68.6 KB) - added by kenni 2 years ago.
Log illustrating the issue while skipping back and forward

Download all attachments as: .zip

Change History (15)

Changed 2 years ago by kenni

Changed 2 years ago by kenni

comment:1 Changed 2 years ago by kenni

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

comment:2 Changed 2 years ago by 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?

Changed 2 years ago by kenni

Log illustrating the issue while skipping back and forward

comment:3 Changed 2 years ago by kenni

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.

comment:4 Changed 21 months ago by 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.

comment:5 Changed 21 months ago by 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.

comment:6 Changed 21 months ago by kenni

  • Ticket locked set

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.

comment:7 Changed 21 months ago by danielk

  • Milestone changed from unknown to 0.26
  • Resolution set to Fixed
  • Status changed from new to closed

Fixed by [483e06f6b8a].

comment:8 Changed 8 weeks ago by 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

comment:9 Changed 8 weeks ago by 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)

comment:10 Changed 8 weeks ago by 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

comment:11 Changed 8 weeks ago by 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)

comment:12 Changed 7 weeks ago by 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)

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.