Troubleshooting:Prebuffering pause

From MythTV Official Wiki
Jump to: navigation, search

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".

Known Possible Causes

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.

Another cause could be problems in one of the drivers you are using. Known examples are:

  • Using the NVidia 180 driver with certain modelines
  • Using the ALSA:Default sound driver. Try selecting the NULL device to see if it has significant effect on the CPU.

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 ...).
  • The NVidia proprietary driver is recommended over the open source ones
  • 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.
  • Use a different audio driver.
  • check realtime or process priority

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.
  • Your Master Backend runs MySQL and/or the OS on the same physical drive as your recordings. You may even have only 1 drive.

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. You may be seeing the prebuffering pause messages in your frontend logs especially while your Backend is recording and usually with HD content.

Probable Cause

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

2)Your Backend cannot handle running the OS, Database and storing new recordings all while efficiently streaming content to your frontend. There may not be enough IO available for all of this activity on 1 physical drive.

Fix

1)Enable the setting, "Delete files slowly," in mythtv-setup under General in the "Miscellaneous Settings" section. Alternatively, switch to using a filesystem which does not journal the deletion of large files in unnecessary detail (like XFS or JFS).

2)Add a drive to handle the recordings alone. Once mounted use mythtv-setup to add it's path to Storage Groups. You could also mount it at /var/lib/mythtv or wherever your main storage is.

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 hang 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

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 the hardware buffer size is set to a reasonable amount.
    • Check the hardware buffer size:
      • (assuming using ALSA card 0, device 3)
      • cat /proc/asound/card0/pcm3p/sub0/prealloc_max will show the maximum allowed
      • cat /proc/asound/card0/pcm3p/sub0/prealloc will show the currently allocated
    • Set the hardware buffer size:
      • for SPDIF: minimum recommended size is 128kB: echo 128 | sudo tee /proc/asound/card0/pcm3p/sub0/prealloc
      • for Analog or HDMI 5.1 up to 48kHz (most common usage): minimum recommended size is 320kB: echo 320 | sudo tee /proc/asound/card0/pcm3p/sub0/prealloc
      • for Analog or HDMI 5.1 up to 192kHz: recommended size is 900kB: echo 1152 | sudo tee /proc/asound/card0/pcm3p/sub0/prealloc
      • for Analog or HDMI 7.1 32 bits, 192kHz (this includes DTS-HD and TrueHD bitstreaming): recommended size is 3072kB: echo 3072 | sudo tee /proc/asound/card0/pcm3p/sub0/prealloc
  • Ensure your audio settings are properly specified in MythTV's settings (General and TV Playback settings).
    • Try using "Audio output device" "ALSA:default" and "Mixer Device" "ALSA:default" in Utilities/Setup|Settings|General
    • Set "Speakers configuration" to "Stereo" in Utilities/Setup|Setup|General
    • Disable "Upconvert stereo to 5.1 surround" in Utilities/Setup|Setup|General
    • Disable the setting "Enable AC3 to SPDIF passthrough" in Utilities/Setup|Setup|General
    • Disable the setting "Enable DTS to SPDIF passthrough" in Utilities/Setup|Setup|General
  • Ensure other, related settings are properly specified in MythTV's settings (General and TV Playback settings).
    • Enable the setting "Extra audio buffering" in Utilities/Setup|Setup|TV Settings|Playback
    • Disable the setting "Aggressive Sound card Buffering" in Utilities/Setup|Setup|General
  • Try using a different sound card.
  • Try using the "Slim" Playback profile with no deinterlacers
    • If using a software encoder, try the "Uncompressed" audio codec in Recording Profiles.

Network I/O Related Issues

Preliminary 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.

Further Reading

http://www.gossamer-threads.com/lists/mythtv/users/181123#181123

Network Configuration

Assumptions

  • You are using a network hub (not a switch or router)

Symptoms

You are experiencing lots of "Prebuffering pause" events in your frontend playback of recordings, even for Standard Definition video

Probable Cause

Most network hubs are listed at 10/100 mbps devices, however that is their total bandwith for all ports. A 10base-T hub may not have enough bandwidth to support MythTV if other devices are making more than minimal use of the network at the same time. A 100base-T hub (although rare, they do exist) may also fail if other devices are putting a demanding load on the hub at the same time. If you see the activity light lit solid and the collisions light in almost the same state, your network is overloaded.

Fix

Replace your 10/100 hub with a 100base-T switch. Replacing any 10base-T cards remaining on your network with newer 100base-T cards as the presence of these can prevent some of the more inexpensive switches from running at full speeds, and that 100base-T (Fast Ethernet) switch will do you no good if your network is composed of only 10base-T devices.

Assumptions

  • Your network cables are garbage/miswired.

Symptoms

Abysmal network throughput, more than a handful of RX/TX errors listed in the output of ifconfig for that particular interface (on all machines involved).

Probable Cause

Cables which have been chewed on by housepets (broken), swung on by small children (stretched), pinched in doorways (cut), wired to a standard other than T568A or T568B on both ends (lunatics), or exposed to the elements without waterproof conduit (hillbillies).

Fix

Replace your network cables using store-bought ones or proper cat5/6/6e cable pinned according to the T568B specification at http://en.wikipedia.org/wiki/TIA/EIA-568-B.

Kernel Scheduler Misconfiguration

Assumptions

  • Your frontend machine is running multiple non-Myth processes (such as MySQL server or Apache HTTP server/MythWeb) 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.

Further Reading

http://www.gossamer-threads.com/lists/mythtv/users/349300#349300

Failing Hard Drive

Assumptions

  • Prebuffering pauses may occur in some or all recordings, regardless of whether they are HDTV or SDTV.
  • All affected recordings exist on the same hard drive.

Symptoms

You are experiencing lots of "prebuffering pause" events in your frontend playback of certain recordings. All affected recordings are stored on the same hard drive (though it's theoretically possible that multiple drives may be failing at the same time). When trying to copy one of the affected recordings to another hard drive, the copy takes significantly longer than copying a different (unaffected) equally-sized recording. System log files and/or hard drive testing/monitoring tools (such as smartmontools) may report disk errors.

Probable Cause

Your hard drive may be failing or contain bad sectors. When trying to read and re-read sectors (and possibly reallocate bad sectors), the drive is unable to supply the recording data at sufficient speed to allow real-time playback.

Fix

Replace the hard drive and copy as many recordings as possible to the new hard drive. Ensure the directory on the new hard drive that contains the recordings is specified in the same storage group that the old directory was (or just use the same mount point/directory name for the new drive). If unable to copy some recordings to the new drive, delete them from MythTV using the Watch Recordings or Delete Recordings screen (and confirm the delete when told the file does not exist).