[mythtv-users] 0.27: Stalls and other niggles - diagnosed

Mike Thomas mt3 at pfw.demon.co.uk
Mon Jan 20 10:32:15 UTC 2014


On Sun, 19 Jan 2014 14:21:22 -0500
Jeff Breitner <jtbreitner.lists at gmail.com> wrote:
> On Sun, Jan 19, 2014 at 7:07 AM, Mike Thomas <mt3 at pfw.demon.co.uk>
> wrote:
> 
> > Perhaps if another developer were to talk those of us who are new to
> > the code base through the system as a whole and about the parts
> > which are not-obvious then we could start to address some of the
> > I/O heavy subsystems. It would give MythTV more headroom for newer
> > features.
> >
> 
> ...snip...
> 
> 
> > Like was said later in this thread, this is an architectural matter
> > for the key developers to chew the fat over. Putting my pennyworth
> > into this I feel that we should scotch talk of moving to SQLite or
> > even Postgres. Having a separate SQL server allows users to query
> > the database independently of the application. This allows for the
> > modular application it is today. IMHO making a monolithic
> > application for a questionable performance increase is a step
> > backwards.
> >
> >
> 
> Mike, et al...
> 
> Are you monitoring and graphing your system performance with
> something like Cacti and some of the freely available MySQL graph and
> data templates?

Nope. At this stage I'm still testing 0.27. All I can say is the patch
I supplied fixes my problem. I've flogged my patch quite hard,
including forcing a total rebuild of eit_cache whilst playing live TV
and I've not observed any freezes. Given that the un-patched 0.27 froze
all the time, I rate that a hit. Of course it deserves wider testing.

> Without that, it is difficult to find areas for
> improvement and if changes really are improvements.

I quite agree. It's why I tried to cool down talk of changing the SQL
server on the basis of one problem.

Mike


More information about the mythtv-users mailing list