Video stuttering: messages about RingBuf, video buffers

[Kantalias]

/var/log/kern.log

Nothing there either (like dmesg, the last entry is ~20 seconds after boot).

Performance suffers greatly with misaligned partitions.

The alignment looks good:

$ sudo fdisk -lu /dev/sdb

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0001c877

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  3907028991  1953513472   83  Linux

Unfortunately, I can't say the same for the sector size of the partition:

$ sudo xfs_growfs -n /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=32, agsize=15261824 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=488378368, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=238466, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Looks like I'll be redoing the partition...

How about setting your LiveTV Storage Group to somewhere on the SSD and seeing how it goes?

My problem isn't limited to LiveTV. I have issues playing back recordings. It's worse when other recordings are being made in the background, but it still happens (on occasion) when the system is doing nothing else beside playing back what I'm watching.

[nickrout]

putting some recordings or livetv on the ssd was simply for a test. To see if things worked ok on another drive.

[davidryderuk]

On a whim, I watched atop while viewing a recording and another one was being written to disk. I saw this during smooth playback:

Code:

DSK | sdb | busy 17% | read 70 | write 47 | KiB/r 244 | | KiB/w 357 | MBr/s 1.67 | MBw/s 1.64 | avq 1.49 | avio 14.7 ms |

When a playback stall occurred, I saw this:

Code:

DSK | sdb | busy 98% | read 22 | write 7 | KiB/r 302 | | KiB/w 258 | MBr/s 0.65 | MBw/s 0.18 | avq 6.74 | avio 334 ms |

Obviously the busy percentage is a problem. The other obvious issue is avio (far right, you have to scroll over in the code section of the post), which I assume is some measure of access time based on its healthy number.

Have you looked at which processes are reading or writing to disk? atop has a mode for listing processes according to the amount of data they are reading or writting.

Here is the output I get watching a low definition video using mplayer, recorded using mythtv.

atop -d

MEM | tot     3.5G | free  133.9M |  cache   1.8G | dirty   0.1M | buff  136.2M | slab  200.2M |               |              |              |
SWP | tot     3.5G | free    3.5G |               |              |              |              |               | vmcom   4.2G | vmlim   5.2G |
DSK |          sda | busy      1% |  read      24 | write      4 | KiB/r    128 | KiB/w      7 | MBr/s   0.30  | MBw/s   0.00 | avio 3.43 ms |

  PID                     RDDSK                     WRDSK                    WCANCL                     DSK                    CMD         1/2
29994                     3072K                        4K                        0K                    100%                    mplayer
  239                        0K                        8K                        0K                      0%                    jbd2/sda4-8
 2574                        0K                        4K                        0K                      0%

And here is a benchmark for my hard drive.

sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   3524 MB in  2.00 seconds = 1763.12 MB/sec
 Timing buffered disk reads: 226 MB in  3.00 seconds =  75.26 MB/sec

[bbzzdd]

I've got a new Myth install and am experiencing the same issue. It happens intermittently and on live tv only.

Nov 12 21:01:37 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 102ms for video buffers AAfAALAAfAAAAA
Nov 12 21:01:37 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 204ms for video buffers AAfAALAAfAAAAA
Nov 12 21:01:37 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 306ms for video buffers AAfAALAAfAAAAA
Nov 12 21:01:37 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 408ms for video buffers AAfAALAAfAAAAA
Nov 12 21:01:37 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 510ms for video buffers AAfAALAAfAAAAA
Nov 12 21:01:38 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 612ms for video buffers AAfAALAAfAAAAA
Nov 12 21:01:38 dvr mythlogserver: mythfrontend[2447]: N CoreContext mythplayer.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 102ms for video buffers AAAAAfLAAALAAA

Generally video playback is silky smooth. Using VDPAU advanced. Recorded playback is 100% solid. It seems I get these issues strange enough when commercial breaks come up or I start a program. I am not running the commercial detector real-time. This is Myth 0.26 on Mythbuntu 12.04. I'd be happy to provide any info to help diagnose this.

I don't think it's disk-related. I am able to hammer the disk even defragging during playback with no onscreen stutter or PrebufferEnoughFrames log errors. Drive seems fast enough:

sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   6998 MB in  2.00 seconds = 3501.06 MB/sec
 Timing buffered disk reads: 294 MB in  3.00 seconds =  97.86 MB/sec

I ran the 'atop -d' command as described above and no out of the ordinary disk access when the problem happens:

ID           RDDSK           WRDSK           WCANCL           DSK           CMD        1/3
 1502              0K          17344K               0K          100%           mythbackend
  269              0K             12K               0K            0%           jbd2/sda6-8
 1206              0K              4K               0K            0%           mysqld
 2447              0K              0K               0K            0%           mythfrontend.r
 2024              0K              0K               0K            0%           mythlogserver

CPU is generally nil on playback with ~97% idle time according to nmon. No processes are spiking.

I am wondering if it's an issue with the source? I am using digital cable clearqam channels and the Hauppauge 1213 WinTV-HVR-2250.

[Kantalias]

I've got a new Myth install and am experiencing the same issue. It happens intermittently and on live tv only.

Generally video playback is silky smooth. Using VDPAU advanced. Recorded playback is 100% solid.

This issue with Live TV only has been "managed" by many with the practice of pausing plackback for a few seconds at the start of watching Live TV.



I've redone the partition on my disk to fix the sector size:

$ sudo xfs_growfs -n /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=32, agsize=15261825 blks
         =                       sectsz=4096  attr=2
data     =                       bsize=4096   blocks=488378390, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Immediately afterwards I got stuttering on Live TV with the typical error messages. I tried the pause trick but it didn't work. I'm going to keep an eye on it to see if there is any change in the rate of incidence.

I'm really starting to think these WDxxEARX drives are no bueno on existing kernels. If I've still got trouble my next step is to put my last, "legacy" WDxxEARS drive in.

[bbzzdd]

I'm really starting to think these WDxxEARX drives are no bueno on existing kernels. If I've still got trouble my next step is to put my last, "legacy" WDxxEARS drive in.

Yipes!

sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       WDC WD20EARX-00PASB0                    
	Serial Number:      WD-xxxxxxxxxxxx
	Firmware Revision:  51.0AB51
	Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

Seems like a common thread...

[bbzzdd]

One thing I noted in my original post and I am monitoring and noticing now is this seems to happen right around the start and end of commercial breaks. I know it's the oddest thing ever but this info sort of has me leaning toward the source. I don't know enough about broadcast to speculate what may be going on but all I can say is the program playback itself is smooth and the vast majority of PrebufferEnoughFrames issues seem to happen around either the start or end of breaks, intermittently.

I also notice this one around the start of a show which is most likely due to flipping the ringbuffer:

Nov 13 07:00:01 dvr mythlogserver: mythfrontend[2447]: N CoreContext avformatdecoder.cpp:783 (SetEof) AFD: Resetting byte context eof (livetv 1 was eof 0)
Nov 13 07:00:02 dvr mythlogserver: mythfrontend[2447]: E Decoder ringbuffer.cpp:271 (Reset) RingBuf(/var/lib/mythtv/livetv/1041_20121113120000.mpg): RingBuffer::Reset() nonzero readpos.  toAdjust: 1 readpos: 289432 readAdjust: 2548077928
Nov 13 07:00:02 dvr mythlogserver: mythfrontend[2447]: N Decoder avformatdecoder.cpp:783 (SetEof) AFD: Resetting byte context eof (livetv 1 was eof 0)

Might symlink /var/lib/mythtv/livetv to my WD7501AALS to rule out the WD20EARX but starting to think it's not disk related. Still maddening.

[Kantalias]

Yeah, I'd say there's some similarity in HDDs:

$ sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       WDC WD20EARX-008FB0                     
	Serial Number:      WD-xxxxxxxxxxxx
	Firmware Revision:  51.0AB51
	Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

One thing I noted in my original post and I am monitoring and noticing now is this seems to happen right around the start and end of commercial breaks.

In my case the stuttering happens randomly in the middle of watching a recording or Live TV. There's no correlation to commercial skipping (in the case of recordings) or breaks (in the case of Live TV).

I didn't have this problem until I got the EARX. I've used MythTV for several years with multiple different hardware setups (including a hardware change under 12.04). This stuttering had never occurred before. As soon as I work up the motivation to deal with copying 1 TB of data again I'll put an EARS back in.

[nickrout]

Yeah, I'd say there's some similarity in HDDs:

$ sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       WDC WD20EARX-008FB0                     
	Serial Number:      WD-xxxxxxxxxxxx
	Firmware Revision:  51.0AB51
	Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

In my case the stuttering happens randomly in the middle of watching a recording or Live TV. There's no correlation to commercial skipping (in the case of recordings) or breaks (in the case of Live TV).

I didn't have this problem until I got the EARX. I've used MythTV for several years with multiple different hardware setups (including a hardware change under 12.04). This stuttering had never occurred before. As soon as I work up the motivation to deal with copying 1 TB of data again I'll put an EARS back in.

That drive (ie the new one) will have 4k sectors and if your patitions are not aligned properly it WILL have performance issues.

You may have already taken that into account and I have not read the whole thread, sorry if this has already been dealt with.

[bbzzdd]

Just grasping at straws here but have you tried disabling the WD head parking on that drive?

http://idle3-tools.sourceforge.net/

I disabled it and it did not make a difference in my case but it seems you timeouts are much more dramatic than mine. Mine are < 1000ms and yours are well over.