RC3 Slow EPG (2 Viewers)

[malakudi]

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

So why are you still bothering us?

I really like the concept of mediaportal and I always try opensource solutions. Do I bother you? Reporting a serious problem that is here for some time is now called bothering? You (the core developers) should loose that attitude if you really want to create a project which is bug-free and innovative. You should listen users. Apart from a mediaportal user I am also a developer and I know when a project needs an RDBMS and when it needs a custom DB-like code, specific for an application. I know the RDBMS way is the easy way. You can either listen the criticism, or you can ignore it. This is up to you.

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...).

I know that any SQL RDBMS will be fast enough if done right. So will be a simple custom-made database system. But selecting an RDBMS which requires hundreds of MB to run (M$SQL) just to ease the development is definitely the wrong path. You also chose to offer the mysql alternative, which unfortunately doesn't work (at least for now). Yes, it is the wrong path. What amount of data are we talking here? Let's get the worse scenario, 10000 of channels in some hundeds of groups. What data is that? 1-2 MB? Do you need an RDBMS to filter 10.000 channels? I don't think so. What about EPG? Even if you had weekly EPG for all these 10.000 of channels, it would be something like 700.000 events? You need an RDBMS for that? All enigma/enigma2 STBs handle EPG and thousants of channels by using a simple text database. Do they need an RDBMS?

And it's not the RDBMS usage that is actually the problem but the poor choice of the .net DB framework. Anyone with developer knowledge understands why you (the core developers) chose this. It's the easy path. What I said from the beginning was that there is no meaning to use this easy path if the result in performance is magnitudes worse that using a custom code.

The mysql performance in TVServer is horrible. Is MSSQL any better? I don't really know, because I am not interested in running MSSQL in my HTPC. I think it should not be needed. But if it is better, until someone fixes the performance of mysql in tvserver, you should not offer this option. Releasing 1.0 with this option when you know that it actually doesn't work is not understandable.

 

[rtv]

I won't close this thread even if your ignorant talking is leading nowhere because the main topic is still current.

Just one last meal for the trolls: The mini-epg for my programs (at least 14 days with ratings, comments, etc - serveral hundred MB raw data size) is loaded in 35-50 ms even using MySQL so performance wouldn't be any point in this argument. However since you're still living in stone age using text files I doubt you understand the multi user and plugin approach of MP at all (There is no offense against simple DBs in this - I e.g. respect the guys who developped BerkleyDB - after 10 years it actually working stable even in threaded environments; yet without network access).

That said I feel really pity not to have enough time to move all of MP1's data to network/multi-user-capable databases. Luckily MP2 will share all it's media to clients.

 

[malakudi]

I won't close this thread even if your ignorant talking is leading nowhere because the main topic is still current.

Just one last meal for the trolls: The mini-epg for my programs (at least 14 days with ratings, comments, etc - serveral hundred MB raw data size) is loaded in 35-50 ms even using MySQL so performance wouldn't be any point in this argument. However since you're still living in stone age using text files I doubt you understand the multi user and plugin approach of MP at all (There is no offense against simple DBs in this - I e.g. respect the guys who developped BerkleyDB - after 10 years it actually working stable even in threaded environments; yet without network access).

That said I feel really pity not to have enough time to move all of MP1's data to network/multi-user-capable databases. Luckily MP2 will share all it's media to clients.

I am not trolling. Reporting problems which are there for so many versions is not trolling. Reporting facts is not trolling. Using mysql all DB related functions (channel list management, EPG) take very long time and very high cpu usage. I don't live in stone age. I mentioned text only databases like the ones used in STBs which are based in the opensource enigma/enigma2 project just to illustrate that if fast channel list management and EPG can be done in very low cpu/memory capable architecture (like these STBs have) , it should be no problem for mediaportal. You chose to use a DB framework just to ease your programming, and that's acceptable as long as it delivers the required performance. Since this is not working, drop this and use a custom solution, specifically fine tuned for mysql and mediaportal. And till then at least tell people that this combination (mysql + tvserver) simply doesn't deliver the required performance.

Finally, ethic wise, an opensource project shouldn't require MSSQL at all. It should only depend in opensource components. This is one more reason why you should drop MSSQL support completely and focus on delivering good performance using mysql (or other opensource DB solutions).

 

[cics]

Finally, ethic wise, an opensource project shouldn't require MSSQL at all. It should only depend in opensource components. This is one more reason why you should drop MSSQL support completely and focus on delivering good performance using mysql (or other opensource DB solutions).

Just like you, but for me; I'm not interested in running MySQL on my environments.

(Sorry, off topic)
Mediaportal is an opensource but it has nothing to do with running in MS-Windows, using DirectX or depending on WMP11. And which database engines to use has nothing to do with Mediaportal is an opensource project.

 

[malakudi]

Finally, ethic wise, an opensource project shouldn't require MSSQL at all. It should only depend in opensource components. This is one more reason why you should drop MSSQL support completely and focus on delivering good performance using mysql (or other opensource DB solutions).

Just like you, but for me; I'm not interested in running MySQL on my environments.

(Sorry, off topic)
Mediaportal is an opensource but it has nothing to do with running in MS-Windows, using DirectX or depending on WMP11. And which database engines to use has nothing to do with Mediaportal is an opensource project.

Windows, directx and wmp11 are all requirements of the platform. MSSQL should not be such a requirement. Today MSSQL express is free, but that might change in the future. An opensource project shouldn't depend to commercial products (MSSQL), even if they are now available for free, especially when there are opensource alternatives available (mysql)

 

[tourettes]

Please move the off topic talk to some other thread.