Prebuffering Pauses

Prebuffering pauses are a generic symptom that results from any of a number of problems or misconfigurations of a MythTV system. Because there are a multitude of causes, the first step in fixing prebuffering pauses is to identify the cause of the pauses. Unfortunately, because the symptom of all these problems is identical, the only way to identify the cause is to recognize a misconfiguration--either by recognizing a similar configuration in a description of a misconfigured system or through a trial and error approach of making configuration changes and observing their effects on video playback. As the former approach is much easier, this page attempts to describe several known misconfigurations to make it easier to diagnose prebuffering pauses.

A prebuffering pause occurs when the MythTV player runs out of audio and/or video to play. The visible/audible effect is playback pausing or pausing, continuing, and pausing (and so on)--creating a stuttering effect. Upon running out of data, mythfrontend will also log a message that looks like:

<date> <time> NVP: prebuffering pause

when configured to log output at the default verbose level. Note that the message may be repeated a number of times each second, depending on how severe the issue is (possibly even comprising a significant portion of the total log file size). If you're not seeing these messages, but see playback issues as described, ensure your log level includes "general".

CPU Starvation

Assumptions

You observe prebuffering pauses when playing back some or all content.
Prebuffering pauses may occur in HDTV or SDTV playback.
When prebuffering pauses occur, the CPU usage (as reported by, for example, top or mpstat) is at or near 100%.

Symptoms

You are experiencing lots of "prebuffering pause" events in your frontend playback of recordings, especially in HDTV and/or interlaced playback. System responsiveness may slow--possibly even making it difficult to stop playback.

Probable Cause

If your CPU usage is maxed out, your system may be too underpowered to play back the content you are trying to play with the playback settings you are trying to use.

Fix

Ensure your system meets the recommended minimum specifications for the type of TV content you plan to play, as described in the "Hardware" section of the MythTV HOWTO.
Ensure your video driver is installed and configured properly. Search the wiki for more information (i.e. by searching for the manufacturer and/or model of your graphics processing unit, NVIDIA or ATI or Intel or ...).
Attempt to use a more appropriate Playback Profile. Using (the default configuration of) Slim will select settings which nearly mirror the settings used by the non-hardware-accelerated playback in MythTV 0.20 and before. If nothing else, try choosing a low-resource, high-performance deinterlacer, such as Kernel or Linear.
Try using XvMC.

I/O Wait

Assumptions

You're using ext2 or ext3 or another filesystem known to have resource-intensive (slow) deletes.
Prebuffering pauses may occur in HDTV or SDTV playback.
Prebuffering pauses occur during LiveTV or when deleting recordings.

Symptoms

You are experiencing lots of "prebuffering pause" events in your frontend playback of recordings when recordings are deleted. Deletion of recordings may happen due to autoexpire when watching LiveTV or when recording.

Probable Cause

Your filesystem is taking too long to delete old recordings and prevents the system from reading the recording/LiveTV you are currently watching.

Fix

Enable the setting, "Delete files slowly," in mythtv-setup under General in the "Miscellaneous Settings" section.

Invalid/Corrupt Seek Table

Assumptions

You observe prebuffering pauses when playing back some or all content.
Prebuffering pauses may occur in HDTV or SDTV playback.
The mythfrontend process may not ever come close to 100% CPU usage during playback.

Symptoms

You are experiencing lots of "prebuffering pause" events in your frontend playback of recordings. Some recordings may play back without issues, while others play back with prebuffering pauses. Prebuffering pauses may be more frequent when (or may occur only after) skipping or jumping forward or backward in the recording. Skipping and jumping may take longer than usual (possibly causing mythfrontend to appear to hand for 10 seconds or 30 seconds or longer with each skip.

Probable Cause

The seek table for the recording is probably corrupt. This may be due to a crashed MySQL table and/or due to invalid data in the table.

Fix

Repair the seek table for the affected recording(s).

Audio Issues

Assumptions

You observe prebuffering pauses when playing back some or all content.
Prebuffering pauses may occur in HDTV or SDTV playback.
Playback of audio works without issue in other programs. Playback of MythTV recordings may even work without problems in other media players.

Symptoms

You are experiencing lots of "prebuffering pause" events in your frontend playback of recordings. The "prebuffering pause" messages may also be accompanied by other messages, such as:

<date> <time> NVP::AddAudioData():p1: Audio buffer overflow, audio data lost!

and/or:

<date> <time> WriteAudio: buffer underrun

Audio may sound normal when playing back; audio may play back too quickly, making voices sound like "chipmunks", or there may be no audible audio.

Probable Cause

Improper audio configuration may cause the sound card to read and play back audio data too quickly, which can exhaust the buffer, causing playback to pause while waiting for additional data.

Fix

Ensure your sound card drivers are properly installed and configured.
Ensure your audio settings are properly specified in MythTV's settings (General and TV Playback settings).
Try using a different sound card.

Network I/O Related Issues

Assumptions

You are using separate frontend and backend machines.
Your backend machine serves the location of your recording files via some network filesystem (NFS, CIFS, or other network filesystems)
Your frontend machine has network mounted the location of your MPG files

Symptoms

You are experiencing lots of "Prebuffering pause" events in your frontend playback of recordings, especially in HDTV or other high-bitrate content.

Probable Cause

If your frontend has the video files accessible through NFS. As of about MythTV 0.18, mythfrontend will attempt to use the network mounted filesystem to access recording files before requesting a stream delivery. If your network filesystem has any hiccups in delivering the bytes from the recording file then you will get a pause in video playback and a "Prebuffering pause" event in the logs.

Fix

Enable the setting:

Always stream recordings from the backend
Enable this setting if you want MythTV to always stream files from a remote backend 
instead of directly reading a recording file if it is accessible locally.

Kernel Scheduler Misconfiguration

Assumptions

Your frontend machine is running multiple non-Myth processes as various different users.
Your kernel is configured with Completely Fair Sharing (CFS) and GROUP_SCHED and USER_SCHED. You can verify whether this is the case by running:

if [ -d /sys/kernel/uids ]; then
  echo USER_SCHED is enabled.
else
  echo USER_SCHED is not enabled.
fi

Symptoms

You are experiencing lots of "Prebuffering pause" events in your frontend playback of recordings, especially while other CPU-hungry processes run. The mythfrontend process may not ever come close to 100% CPU usage, and only "background" or low-priority (niced) processes are using CPU time not used by mythfrontend.

Probable Cause

Completely Fair Sharing (CFS) is a kernel process scheduler that allows administrators to share CPU allocation (bandwidth) with more fine-grained control than simply using the POSIX niceness settings. GROUP_SCHED, the "Group CPU scheduler" ("This feature lets CPU scheduler recognize task groups and control CPU bandwidth allocation to such task groups.") can be configured with USER_SCHED as the value for "Basis for grouping tasks", where USER_SCHED means, "This option will choose userid as the basis for grouping tasks, thus providing equal CPU bandwidth to each user."

Therefore, a kernel configured with CFS using GROUP_SCHED and USER_SCHED will ensure that different users get their share of bandwidth, so even when running a "high-priority" process, such as mythfrontend with a nice setting of 0 as one user and another low-priority process, such as BOINC/SETI@home with a nice setting of 19 as a different user, the scheduler will ensure each user gets appropriate bandwidth, meaning that the niced process may actually prevent mythfrontend from getting the amount of CPU bandwidth it needs.

Similarly, running a combined frontend/backend system with this configuration where the MySQL server runs as a different user from the frontend and/or where the frontend and backend run as different users may cause priority issues which can result in playback (or even recording) problems.

Fix

Allocate appropriately small bandwidth to the user whose process is interrupting mythfrontend playback. Note that doing so will affect all processes run by that user. You may alter the user's bandwidth allocation with:
```
echo 2 > /sys/kernel/<uid>/cpu_share
```
replacing <uid> with the user's numeric ID and replacing the cpu_share value (here, "2") with an appropriate number, relative to the cpu_share allocated to the user running mythfrontend, which can be determined with:
```
cat /sys/kernel/uids/`id -u mythtv`/cpu_share
```
replacing mythtv with the username of the user running mythfrontend.
Recompile the kernel and select, CGROUP_SCHED as the "Basis for grouping tasks." (CGROUP_SCHED is "Control groups", meaning, "This option allows you to create arbitrary task groups using the 'cgroup' pseudo filesystem and control the cpu bandwidth allocated to each such task group. Refer to Documentation/cgroups.txt for more information on 'cgroup' pseudo filesystem."). In so doing, all processes will be started in the default control group, and, therefore, CPU bandwidth allocation will be determined exclusively by nice value.
- To further control prioritization with CGROUP_SCHED (as described above), allocate a sufficiently small cpu.share to the process (or parent of several processes) that is interrupting mythfrontend playback. So, for example, to ensure BOINC/SETI@home never interferes with MythTV execution create a control group, such as "background" and assign background cpu.shares a value of 2 and ensure the process ID of the boinc process (or the script that started the boinc process) is specified in the background/tasks. Note that the /dev/cpuctl filesystem will be re-created at each boot, so cgroup configuration must be done in an appropriate init script.

Troubleshooting:Prebuffering pause

Contents

Prebuffering Pauses

CPU Starvation

Assumptions

Symptoms

Probable Cause

Fix

I/O Wait

Assumptions

Symptoms

Probable Cause

Fix

Invalid/Corrupt Seek Table

Assumptions

Symptoms

Probable Cause

Fix

Audio Issues

Assumptions

Symptoms

Probable Cause

Fix

Network I/O Related Issues

Assumptions

Symptoms

Probable Cause

Fix

Further Reading

Kernel Scheduler Misconfiguration

Assumptions

Symptoms

Probable Cause

Fix

Further Reading

Navigation menu

Search