Video stuttering: messages about RingBuf, video buffers

[Rotak]

@nickrout:
But why does atop output such a high busy-percentage in the moment it stutters?

Maybe, both problems together cause it: Buffer too small + filesystem too busy!?!

[Kantalias]

Try pausing, let the buffer build up a bit and restart. Should only take a short pause. If that works we have probably at least found the bug, even if the workaround is a PITA. (albeit an easy to implement PITA).

I've heard of this bug and have tried pausing and then resuming play. Pausing, even for seconds, doesn't help my issue. Additionally, please note that I have stuttering in live TV and when playing back a recording (with no live TV involved).

Based on the underlying I/O performance and its correlation to the playback problem this does seem to be a system level issue. If it's not a filesystem problem is it likely lower level (hardware) or higher level (??? what sits between the front end and the filesystem)?

[Rotak]

The kernel and some other stuff is sitting between the backend and the hardware.

Did you think about backup recordings -> format hdd with (e.g.) ext2 -> restore recordings?

[Kantalias]

Did you think about backup recordings -> format hdd with (e.g.) ext2 -> restore recordings?

I am strongly considering doing something like that, yes. Is ext2 the preferred filesystem (over XFS, over ext4)?

[nickrout]

I am strongly considering doing something like that, yes. Is ext2 the preferred filesystem (over XFS, over ext4)?

No, xfs id the preferred. ext2 is ancient and has no journalling.

Is this a combined BE/FE or networked? If so is it wired or wireles. if wireless, that is your likely problem.

[Kantalias]

Is this a combined BE/FE or networked?

I have a combined frontend/backend. (And, incidentally, all networks connections are wired.)

This hardware has worked fantastically for me in various incarnations with different versions of Ubuntu and Myth for several years. These issues seem to have come up with a recent hard drive upgrade brought on by a failing drive. This modification moved me from a single WD20EARS to a Crucial M4 SSD2 for the system and a WD20EARX for recordings. At the hardware level I'm primarily concerned about the "new"(ish) EARX which is a SATA III version of the EARS (SATA II).

I've applied all the Ubuntu and Myth updates as of a week ago hoping to get an updated kernel driver that would support this disk. Since you feel strongly that the filesystem isn't to blame, I'm tempted to move to a different physical disk.

Thoughts?

[nickrout]

I guess it could be the disk. Hard to say, if you can borrow another and try it out, you'd know, but if you have to buy one it's an expensive punt.

anything in dmesg or other kernel logs?

Just thought, you almost undoubtedly have a 4k block disk drive. Do you have the partitions properly aligned? There's a lot of stuff on the net about this issue.

[Kantalias]

anything in dmesg or other kernel logs?

Nothing in dmesg. How do I check kernal logs?

Just thought, you almost undoubtedly have a 4k block disk drive. Do you have the partitions properly aligned? There's a lot of stuff on the net about this issue.

I saw lots about alignment when I was partitioning the drive. I think I checked that, but I'll double check.

[nickrout]

Nothing in dmesg. How do I check kernal logs?

/var/log/kern.log

I saw lots about alignment when I was partitioning the drive. I think I checked that, but I'll double check.

Performance suffers greatly with misaligned partitions.

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

[Rotak]

No, xfs id the preferred. ext2 is ancient and has no journalling.

Hmmm. No journaling is why I preferred ext2. It's fast. And I don't see any benefit of journaling for a recordings HDD on a MythTV box. But I agree, that ext2 is ancient, so ext4 with disabled journaling may be an alternative. I didn't consider it, because when I installed my MythTV box, ext4 was an alpha release.