[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mythtv-users
Subject:    Re: [mythtv-users] LiveTV: stutter at program start/change
From:       Terjesen Jens Peder <Jens.Peder.Terjesen () devoteam ! com>
Date:       2010-09-30 8:48:13
Message-ID: 6BC89C924FB94D44BE29322D1C56AD34C0AD361E2A () SVCSTCCRMB01 ! devoteam ! com
[Download RAW message or body]

Daniel Born wrote:
----------------------------------------

If you don't mind, I'm going to hijack my own thread back! ;-) there's already low \
enough traffic and interest on this that I'd hate having it go in another \
direction... The problem that I and others are referring to is not caused by channel \
changes: You start listening to a livetv program. It's choppy. pause-unpause and it's \
fine. Then your show ends and a new one begins, same channel. Choppyness starts \
again. pause-unpause. your good again.

Thanks!
Daniel

-----------------------------------------

I don't use live-TV much so not sure if this is related.

I have a combined FE/BE with 6 TB of recordings that worked very well without any \
maintenence of the database or other.

When upgrading MythTV from 0.22 to 0.23 I started a backup of the database to the \
system partition which got filled up and trashed the system. Fortunately I managed to \
make a complete backup to one of the storage disks after this but had to reinstall \
the system, then installed MythTv 0.22 again to verify it was working and that no \
recordings were lost before upgrading to 0.23.

After this reinstall I know that the storage disks are mounted at different \
directories than before but since they all are connected to the same storage group \
MythTV finds all the recordings.

But what I have noticed after this reinstall is that MythTV over time gets very \
sluggish in general and particularly when it comes to starting playback of recordings \
and also fast forward.

My solution when this happens is to run the script for optimizing the database, then \
all is fine for a while. I guess that it is mainly optimization of the recordedseek \
table that solves the problem in my case.

Jens
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


[prev in list] [next in list] [prev in thread] [next in thread]