[mythtv-users] mythtv-users Digest, Vol 131, Issue 14

Kevin Johnson iitywygms at gmail.com
Wed Feb 5 16:35:58 UTC 2014


>
> simply reply at the bottom of the answer, not the top
>
> > On Tue, Feb 4, 2014 at 5:55 PM, Kevin Johnson <iitywygms at gmail.com>
> wrote:
> >> It seems like the frontend is waiting for info from the backend.  But I
> >> really cant figure out what to look for.  And google search of  the
> above
> >> errors shows very little.
> >>
> >> Could this be a i/o error with one of the drives?  If so, how do I test?
> >> If not, any ideas where I should start looking?
> >> Thanks to all.
>
> Having been through this myself, I can guarantee you that it is always
> disk related....
>
> When you are playing from liveTV there are two things happening
> simultaneously from the backend.
>
> First is the recorder writing to the disk: that's thread #1
> Then you have thread #2 handling request from the frontend and
> requesting data; that is reading the data from the disk.
>
> So one process of the backend write on disk, while another process
> read from disk. You have a long delay occurring there, from your log,
> it takes over 6s between the time the backend write to the disk, and
> the reader reads that data. That's way too much. For information, you
> get a warning that it's too low if it takes more than 0.2s.
>
> After 10s waiting for sufficient data the reader on the backend will abort.
> If it takes more than 16s to read a block of data, it will also abort.
>
> Now how the frontend handle it when the backend abort is very poor.
> The frontend usually will just appear to be locked. After a little
> while you can exit it by pressing the exit key.
>
> I guess, optimisation could be done, so if the frontend is watching
> liveTV we don't have to wait for the backend to finish writing data to
> disk before reading from disk once again and directly transfer it
> right away to the client.
>
> But at this stage, the design doesn't allow for it.
>
> In the mean time, you need to identify where the bottleneck is. If you
> are using NFS , check the mounting option (that's the issue I was
> having), if using a RAID array, check the smart status to make sure
> you don't have a disk dying that is slowing everything down.
>
> Make sure your database isn't on the same disks where you are writing
> your recordings and not on a RAID array. that has proven to often be
> the reason for having massive speed slowdowns with disks
>
>
I am using nfs on the backend machine.  But mythtv does not access it for
anything.  I only use nfs to share folders over my network.
I am not using raid.
My database is on one of the 3 drives I use to store recordings.  I did
remove that directory, /var/lib/mythtv/livetv and
/var/lib/mythtv/recordings from mythtv to test if that would improve the
issue.  It did not improve.
I currently have my recording going to 3 separate drives.  Only one of
those drives does have the database on it.

One dirve has the nfs share folder along with mythtv recordings.
One drive has the database on it along with mythtv recordings.
The last drive stores videos from zoneminder and has myth recordings.

Could the nfs be bottle necking my system?  If so, how would I find out?

Also, this happens when zoneminder is not running.  So I do not believe
that zoneminder is at fault.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140205/0ac43ceb/attachment.html>


More information about the mythtv-users mailing list