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

[Thomas Mashos]

On Wed, Feb 5, 2014 at 8:35 AM, Kevin Johnson <iitywygms at gmail.com> wrote:
>
>
>>
>>
>> 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.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

If you plan on subscribing to and sending emails to the MythTV mailing
list, please do not use the list in digest mode. All of your replies
are going into a digest thread and not following the other threads
that you are actually replying to.

http://www.mythtv.org/wiki/Mailing_List_etiquette

Thanks,

Thomas Mashos