Hi,
if the configuration (channels, transponders, options) and EPG would be stored in a MySQL-DB other applications could easily use that data instead of doing expensive scans of the files again and again.
Maybe there could be a compiler switch or even a command-line option for VDR to switch between file and SQL mode.
Renne
Rene Bartsch wrote:
Hi,
if the configuration (channels, transponders, options) and EPG would be stored in a MySQL-DB other applications could easily use that data instead of doing expensive scans of the files again and again.
Maybe there could be a compiler switch or even a command-line option for VDR to switch between file and SQL mode.
Could be very usefull if VDR ever evolves to real client/server system. For simple STB, I'm not so sure.
Rene Bartsch wrote:
if the configuration (channels, transponders, options) and EPG would be stored in a MySQL-DB other applications could easily use that data instead of doing expensive scans of the files again and again.
Maybe there could be a compiler switch or even a command-line option for VDR to switch between file and SQL mode.
this could even solve some problems regarding synchronisation/thread safeness. But IMHO this sounds like a feature of VDR 2.0 ;-)
BR,
Christian
On Saturday 09 September 2006 12:09, Christian Wieninger wrote:
Rene Bartsch wrote:
if the configuration (channels, transponders, options) and EPG would be stored in a MySQL-DB other applications could easily use that data instead of doing expensive scans of the files again and again.
Maybe there could be a compiler switch or even a command-line option for VDR to switch between file and SQL mode.
this could even solve some problems regarding synchronisation/thread safeness. But IMHO this sounds like a feature of VDR 2.0 ;-)
It does have the added overheads of running MySQL on what might be a low-power system, slower startup, etc. Then again, reading large amounts of EPG data, etc. from what can be huge flat files should improve things!
Maybe it could be a build-time option...
Laz
It does have the added overheads of running MySQL on what might be a low-power system, slower startup, etc. Then again, reading large amounts of EPG data, etc. from what can be huge flat files should improve things!
Maybe it could be a build-time option...
Maybe embedded SQL can help you?
Renne
Rene Bartsch wrote:
if the configuration (channels, transponders, options) and EPG would be stored in a MySQL-DB other applications could easily use that data instead of doing expensive scans of the files again and again.
Maybe there could be a compiler switch or even a command-line option for VDR to switch between file and SQL mode.
this could even solve some problems regarding synchronisation/thread safeness. But IMHO this sounds like a feature of VDR 2.0 ;-)
For a start one could just use the same DB-tables and structures as the current EPG/configuraton files are. That way the class writing the files could be easily inherited with the writing functions overwritten by functions with MySQL queries. A compiler switch would then select between the two classes at compile time. Unfortunately I don't have enough C++ skills to do it myself.
Renne
Hi,
Am Samstag, den 09.09.2006, 11:51 +0200 schrieb Rene Bartsch:
if the configuration (channels, transponders, options) and EPG would be stored in a MySQL-DB other applications could easily use that data instead of doing expensive scans of the files again and again.
There exits XXV, it store many vdr data at mysql-tables. It could use as http, telnet or soap server.
Enjoy, Andreas
[1] http://xpix.dieserver.de/content [2] http://www.linuxtv.org/vdrwiki/index.php/Xxv [3] http://www.vdr-wiki.de/wiki/index.php/Xxv
-
Andreas Brachold -
Christian Wieninger -
Lauri Tischler -
Laz -
Rene Bartsch