Currently, just the logger plugin uses it... it simply tracks the
number of times a music file is played, as well as the last date it
was played and allows you to rate music from 1-5...
On Tue, Feb 03, 2004 at 10:04:58AM +0800, Wan Tat Chee wrote:
> Hi Aubin,
>
> On Sat, 31 Jan 2004, Aubin Paul w
Hi Aubin,
On Sat, 31 Jan 2004, Aubin Paul wrote:
> Those versions are fine, though "needed" is far too strong. SQLite
> support is in CVS, but since it isn't used for anything other than one
> (non-interactive) plugin, it's not something to stress about.
Ok. Which plugin is SQLite meant for? I s
Those versions are fine, though "needed" is far too strong. SQLite
support is in CVS, but since it isn't used for anything other than one
(non-interactive) plugin, it's not something to stress about.
On Fri, Jan 30, 2004 at 10:10:25AM +0800, Wan Tat Chee wrote:
> Hi,
> Since we appear to be headin
Hi,
Since we appear to be heading for SQLite for the next release,
I'd better make some preparations wrt. RPM support.
Can someone confirm that the following is what's needed?
SQLite library: http://www.hwaci.com/sw/sqlite/ (version 2.8.11)
Python wrapper: http://pysqlite.sourceforge.net/ (versio
Ahh, sweet, have to try to use that instead of postgres then, and see
if I can get the CVS thingy to work as well :)
// MickeM
Joakim Berglund wrote:
Hi there
Well since sqlite handles locking on
file level there is no problem in accessing the same file (aka db) from
sev
Hi there
Well since sqlite handles locking on file level
there is no problem in accessing the same file (aka db) from several threads or
programs at the same time. Ive have used this extensivly in a coding project Im
in 3 diff programs and each having 5+ thread open to the same db file
Aubin Paul wrote:
On Mon, Jan 26, 2004 at 12:45:43PM +0100, Michael Medin wrote:
I think that it would be pretty nice to have the option to have an
external database accesable from other systems. Just such a simple
thing as my media library is remote means I would like to
On Mon, Jan 26, 2004 at 12:45:43PM +0100, Michael Medin wrote:
>I think that it would be pretty nice to have the option to have an
>external database accesable from other systems. Just such a simple
>thing as my media library is remote means I would like to have my
>database remote.
Aubin Paul wrote:
On Fri, Jan 23, 2004 at 07:48:32PM -0500, Michael Ruelle wrote:
Having gone through in my professional service the transition from one
database to another I would advise against this. I was going to bring
this up with dischi, but will state my piece here.
On Fri, Jan 23, 2004 at 07:48:32PM -0500, Michael Ruelle wrote:
> Having gone through in my professional service the transition from one
> database to another I would advise against this. I was going to bring
> this up with dischi, but will state my piece here.
Considering most of the db stuff has
On Sat, 2004-01-24 at 01:48, Michael Ruelle wrote:
> On Fri, 2004-01-23 at 17:08, Richard van Paasen wrote:
> > Consider this just a incentive to keep the database related code
> > separated from the freevo code so that e.g. mysql or postgresql can
> > replace sqlite. I've seen projects that incorp
On Sat, 2004-01-24 at 04:07, Rob Shortt wrote:
> Michael Ruelle wrote:
> I agree with this as well, keep DB code and Freevo code seperate. The
> use of plugins could play a great role here. It might be a great idea
> to start by creating a dbplugin object for any potential database
> plugins t
On Fri, 2004-01-23 at 22:07, Rob Shortt wrote:
> 2) client / server sqlite. we could wrap plugin #1 up in a helper and
> xmlrpc server, this plugin shovels requests off to it. this would reuse
> the code in plugin 1.
I would also like to see us NOT use the twisted persistence framework on
this.
Robert Rozman wrote:
I think that mysql would be better long term decision. Scenario below
"describes" mythtv features. It's already done to certain level. If you ask
me, I'd go with mythtv (or their code and acrhitecture backend/several
frontends) for Live TV and recording and Freevo for the rest.
Michael Ruelle wrote:
On Fri, 2004-01-23 at 17:08, Richard van Paasen wrote:
Consider this just a incentive to keep the database related code
separated from the freevo code so that e.g. mysql or postgresql can
replace sqlite. I've seen projects that incorporate sql statements
directly into the pro
On Fri, 2004-01-23 at 17:08, Richard van Paasen wrote:
> Consider this just a incentive to keep the database related code
> separated from the freevo code so that e.g. mysql or postgresql can
> replace sqlite. I've seen projects that incorporate sql statements
> directly into the program code...
several
> frontends) for Live TV and recording and Freevo for the rest...
>
> Regards,
>
> Robert.
>
> - Original Message -
> From: "Richard van Paasen" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 23, 2004 11:0
..
Regards,
Robert.
- Original Message -
From: "Richard van Paasen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 23, 2004 11:08 PM
Subject: [Freevo-devel] SQLite
>
> I've read about the plans for using SQLite. While browsing
I've read about the plans for using SQLite. While browsing the homepage
of sqlite, I noticed that it operates directly on files w/o a running
server, correct?
I know some of freevo's architecture, but not that much... Maybe the
need will rise in the future to run and connect several freevo boxes,
Would it make sense for the plugin which increments playcount to
intercept the 'AUDIO_PLAY_END' event (after a song finishes)? We make
a plugin which accepts that event and then increments the database
information...?
Aubin
---
This SF.Net emai
20 matches
Mail list logo
