RC3 Slow EPG (1 Viewer)

Eabin

Retired Team Member
  • Premium Supporter
  • September 18, 2006
    465
    43
    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

    Retired Team Member
  • Premium Supporter
  • April 7, 2005
    3,622
    301
    Osnabruck
    Home Country
    Germany Germany
    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

    Retired Team Member
  • Premium Supporter
  • September 18, 2006
    465
    43
    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

    Portal Member
    January 28, 2007
    22
    0
    Home Country
    Greece Greece
    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.
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    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

    Portal Member
    January 28, 2007
    22
    0
    Home Country
    Greece Greece
    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

    Portal Member
    January 30, 2007
    15
    0
    47
    Hamburg
    Home Country
    Germany Germany
    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

    Portal Member
    January 28, 2007
    22
    0
    Home Country
    Greece Greece
    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

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    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...).
     

    Users who are viewing this thread

    Top Bottom