Mailing List Archive

What video codec were you using? Is audio compressed?

I've been trying to figure out where the bottleneck would be that would
be causing the delay in switching channels and OSD display, when the
amount of RAM is smaller. My guess is the access to the database, for
the channel info and OSD data. Can you give any more details about how
you were watching TV when you noticed this (30 seconds behind live TV, etc)?

If it is due to the database files getting expunged from the cache in
memory, here are some thoughts about how to reduce/eliminate the delay:
1) Make a ramdisk and keep the database files there (On my system, the
mysql data files in /var/lib/mysql take up less than 5MB)
2) Keep the data in memory, instead of querying it from the database
every time.


About #2... I've been thinking for a while about trying to eliminate
the database dependency entirely from MythTV. There aren't that many
places in the code that do database accesses. Each complex query
(accesses more than one table) would have to be coded manually. The
data would be kept in flat files, and loaded into memory whenever the
file on disk changed. The mythfilldatabase would generate the flat
files. Since it's only a few megabytes, it would be quick to search
through and wouldn't typically be swapped out from memory. It would
make installation easier, since mysql wouldn't be a requirement and you
wouldn't have to fight with the permissions inside the database.

Any comments?



Chris Liscio wrote:

>I just purchased my upgrades for my MythTV box -- CPU upgrade from Duron
>1Ghz to AthlonXP 1700+, and RAM upgrade from 256MB PC100 to 512MB PC133.
>
>So I decided to delay on the CPU installation just to make sure that I
>wasn't wasting my money and just tossed in the new RAM. I did see one very
>important speedup which might be of interest to you specs-watchers.
>
>After installing the RAM I noticed a very large decrease in the time
>required to a) change channels and b) have the OSD display after a channel
>change.
>
>So if any of you out there have CPUs that are happily pumping along at lower
>resolutions (I am a bit of a videophile, I guess you could say...) then you
>might just want to consider a RAM upgrade if you're annoyed with the channel
>change speeds...
>
>Unfortunately, the speed of the 640x480 MPEG4 streams has still not appeared
>to improve. I will be installing the CPU later on tonight and will
>hopefully get some more info for the list.
>
>Hope this helps,
>
>Chris
>
>
>

I basically had settings.txt as it was in the default case, with the
addition of trying 640x480. It was interesting to see the OSD working
quickly, but the video lagging behind. I thought for some reason that they
were related... *shrug*

Personally, I'd vote for keeping the DB back-end. Eventually, I'd like to
see (or add) the ability to search by show title, move to a specific
day/time, etc more easily than what we currently have. This becomes a lot
easier when we have a DB on our side...

Just my 0.02

Chris

-----Original Message-----
From: mythtv-dev-admin@snowman.net
[mailto:mythtv-dev-admin@snowman.net]On Behalf Of rob
Sent: Wednesday, November 20, 2002 5:53 PM
To: mythtv-dev@snowman.net
Subject: Re: [mythtv] Interesting performance improvement


What video codec were you using? Is audio compressed?

I've been trying to figure out where the bottleneck would be that would
be causing the delay in switching channels and OSD display, when the
amount of RAM is smaller. My guess is the access to the database, for
the channel info and OSD data. Can you give any more details about how
you were watching TV when you noticed this (30 seconds behind live TV, etc)?

If it is due to the database files getting expunged from the cache in
memory, here are some thoughts about how to reduce/eliminate the delay:
1) Make a ramdisk and keep the database files there (On my system, the
mysql data files in /var/lib/mysql take up less than 5MB)
2) Keep the data in memory, instead of querying it from the database
every time.


About #2... I've been thinking for a while about trying to eliminate
the database dependency entirely from MythTV. There aren't that many
places in the code that do database accesses. Each complex query
(accesses more than one table) would have to be coded manually. The
data would be kept in flat files, and loaded into memory whenever the
file on disk changed. The mythfilldatabase would generate the flat
files. Since it's only a few megabytes, it would be quick to search
through and wouldn't typically be swapped out from memory. It would
make installation easier, since mysql wouldn't be a requirement and you
wouldn't have to fight with the permissions inside the database.

Any comments?



Chris Liscio wrote:

>I just purchased my upgrades for my MythTV box -- CPU upgrade from Duron
>1Ghz to AthlonXP 1700+, and RAM upgrade from 256MB PC100 to 512MB PC133.
>
>So I decided to delay on the CPU installation just to make sure that I
>wasn't wasting my money and just tossed in the new RAM. I did see one very
>important speedup which might be of interest to you specs-watchers.
>
>After installing the RAM I noticed a very large decrease in the time
>required to a) change channels and b) have the OSD display after a channel
>change.
>
>So if any of you out there have CPUs that are happily pumping along at
lower
>resolutions (I am a bit of a videophile, I guess you could say...) then you
>might just want to consider a RAM upgrade if you're annoyed with the
channel
>change speeds...
>
>Unfortunately, the speed of the 640x480 MPEG4 streams has still not
appeared
>to improve. I will be installing the CPU later on tonight and will
>hopefully get some more info for the list.
>
>Hope this helps,
>
>Chris
>
>
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev@snowman.net
http://www.snowman.net/mailman/listinfo/mythtv-dev

On Wednesday 20 November 2002 05:52 pm, rob wrote:
> About #2... I've been thinking for a while about trying to eliminate
> the database dependency entirely from MythTV. There aren't that many
> places in the code that do database accesses. Each complex query
> (accesses more than one table) would have to be coded manually. The
> data would be kept in flat files, and loaded into memory whenever the
> file on disk changed. The mythfilldatabase would generate the flat
> files. Since it's only a few megabytes, it would be quick to search
> through and wouldn't typically be swapped out from memory. It would
> make installation easier, since mysql wouldn't be a requirement and you
> wouldn't have to fight with the permissions inside the database.

Sorry, but that's not going to happen. The benefits of using a database far
outweigh the any minor setup issues due to requiring one.

Isaac

At 21-11-02 00:26, you wrote:
>On Wednesday 20 November 2002 05:52 pm, rob wrote:
> > About #2... I've been thinking for a while about trying to eliminate
> > the database dependency entirely from MythTV.
(...)
> Sorry, but that's not going to happen. The benefits of using a database
far
> outweigh the any minor setup issues due to requiring one.

In fact I am thinking about implementing a real relational scheme one
withing the SQL database (medium priority or below for me). Improving
indexes, cascaded delete, foreign keys, all validation & default rules in
the database instead of the filling tool, the works.
I must confess that my only database experience is with the big commercial
programs, never ran MySQL before MythTV. But I'd like to have a look at its
support for stored procedures, triggers, etc.

The main reason for all this is that if you run MythTV as TiVo replacement
(settop blackbox) which is my final target, you must be sure all data stays
consistent and the database doesn't end up collection garbage. Dependency
on duplicated database fillingrules in MythTV, mythfilldatabase and
external direct filling tvguide scrapers will then disappear.

Is there any particular reason for the dumb standalone tables in the
current implementation?

Erik