RC3 Slow EPG (1 Viewer)

[Eabin]

update:
from mysql logfile:
5 Change user
5 Query SHOW VARIABLES
5 Query SHOW WARNINGS
5 Query SHOW COLLATION
5 Query SET NAMES utf8;SET character_set_results=NULL
5 Init DB tvlibrary
5 Query select idCanceledSchedule, idSchedule, cancelDateTime from CanceledSchedule where idSchedule = 408

 

[rtv]

update:
from mysql logfile:
5 Change user
5 Query SHOW VARIABLES
5 Query SHOW WARNINGS
5 Query SHOW COLLATION
5 Query SET NAMES utf8;SET character_set_results=NULL
5 Init DB tvlibrary
5 Query select idCanceledSchedule, idSchedule, cancelDateTime from CanceledSchedule where idSchedule = 408

Why look at one single command when just the ugly code produces thousands of useless queries?

 

[Eabin]

because i don't have the code at the moment

if both issues can be fixed, the TVGuide might eventually become blazingly fast.

edit: to be clear: the above sequence happens for _every single_ query. with a better client, only the actual query should be sent to mysql each time.

edit2: i just realized that for whatever reason all the indizes in the Programs table had the same name. this way mysql cannot use them. so i dropped all indizes and re-created them, and now the tvguide is much faster. the problem with lost of scheduled recordings persists, though. but i guess this is due to the massive amount of statements.

 

[malakudi]

There is only one solution. Stop using a generic use database framework and create a specific mediaportal solution. Using RDBMS which requires hundreds of megabytes (M$SQL) just to have EPG, channel and recording management is a totally wrong approach. These are features that any set top box with limited memory and CPU power can do. Support mysql correctly, or even better, drop completely RDBMS and use a database solution that will be fine tuned to the requirements of mediaportal.

 

[rtv]

Was there anything useful along that blah blah blah?

 

[tourettes]

There is only one solution. Stop using a generic use database framework and create a specific mediaportal solution. Using RDBMS which requires hundreds of megabytes (M$SQL) just to have EPG, channel and recording management is a totally wrong approach. These are features that any set top box with limited memory and CPU power can do. Support mysql correctly, or even better, drop completely RDBMS and use a database solution that will be fine tuned to the requirements of mediaportal.

Why wont you just download an another DVB program and use it instead?

 

[malakudi]

Actually I have already done this months ago (bought DVBViewer)

It's a pitty you developers don't realise the wrong path you have taken about this DB thing. I like mediaportal and test it from time to time, but there are so many problems unresolved for so many months that I now think they will never get fixed. And the reason for this is that as long as you don't accept there is a problem, you'll never going to solve it. MySQL support IS a problem whether I use mediaportal or not. If you don't like that getting reported, just drop mysql support.

 

[Infinity]

Hi,

I have the same problem malakudi described before. Mediaportal 1 final is perfect for watching Movies but for TV it is to slow. My 60Mhz DBOX2 with Linux (Neutrino) switches Channels in 0.5. to 1 Second. Mediaporal needs 3-4 Seconds on my 20 times faster Setup.

I think that the use of a Database like MySQL in a Mediacentersoftware is not the Problem. It semms to be the way it is used. Normally the Database has all the Data in Memory because the Mediaportal-Tables are VERY small (1500 Channels, some Groups, ...) Even if no Indexes are available, selects should be extreme fast because no Harddiskaccess is needed.

BUT what I don't understand

While changing from one TV-Channel to another the MySQL process and the Mediaportal TV-Serverprocess take both 50% Processortime for 8 Seconds! What the heck is Mediaportal doing with the Database while changing a TV-Channel?
Maybe this could be the same reason for slow EPG.

Regards
Andreas

 

[malakudi]

BUT what I don't understand

While changing from one TV-Channel to another the MySQL process and the Mediaportal TV-Serverprocess take both 50% Processortime for 8 Seconds! What the heck is Mediaportal doing with the Database while changing a TV-Channel?
Maybe this could be the same reason for slow EPG.

Regards
Andreas

I've had EXACTLY the same behaviour in my system. Very high cpu usage in every channel change.

 

[tourettes]

Actually I have already done this months ago (bought DVBViewer)

So why are you still bothering us?

It's a pitty you developers don't realise the wrong path you have taken about this DB thing. I like mediaportal and test it from time to time, but there are so many problems unresolved for so many months that I now think they will never get fixed. And the reason for this is that as long as you don't accept there is a problem, you'll never going to solve it. MySQL support IS a problem whether I use mediaportal or not. If you don't like that getting reported, just drop mysql support.

The path is not wrong, its just buggy code in EPG / channel database handling that causes the INSANE/HUGE SQL query load on the MySQL server. Something that will be fixed at some point.

Just get the SQL basic facts right and you'll see that ANY SINGLE SQL database will be fast enough to server all EPG related needs (when the code itself isn't buggy and wont generate millions of unnescessary SQL queries...).