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