Well, merge it! Everything in CVS is unstable right now, so it's ok if
you just want testing.
But lots of big changes have taken place. If you're on Debian, use my
apt source for mmpython since it's always recent CVS and contains
bugfixes for most problems.
Aubin
On Sat, Jul 05, 2003 at 09:32:
Aubin Paul wrote:
That's ok for now. It would be nice to have a web interface for all
the query stuff, e.g. I write the select for the mp3 playlist (or all
images from 'siena') and the webinterface will give that playlist to
Freevo and freevo displays/plays it.
If Rob is working on a 'drop' down
On Wed, Jul 02, 2003 at 04:27:05PM -0500, Krister Lagerstrom wrote:
> Are you sure about this? I found this in the source, but nothing about
> column sizes:
I'm trying to remember where I saw that. Of course, that is bytes per
row, but it's still a lot to work with if you have narrow columns.
>
> Aubin wrote:
> First, sqlite by default has a maximum column width of 320bytes. It can
> be recompiled to do up to 16mb, but it's not really worth it.
Are you sure about this? I found this in the source, but nothing about
column sizes:
/*
** The maximum number of bytes of data that can be put i
On Mon, Jun 30, 2003 at 11:24:22AM -0500, Krister Lagerstrom wrote:
> I can see how it would be useful to have a SQL DB to support file
> navigation. Most users would probably start using Freevo with the regular
> folder/file structure, and playlists in standard text formats. But for
> more advance
> On Mon, 30 Jun 2003, Aubin Paul wrote:
>
>> On Mon, Jun 30, 2003 at 04:40:41PM +0200, Thomas Schueppel wrote:
>> >The idea of mmpython is to retrieve a common set of
>> >information from these files. Hence using a common
>> >table for wmv/avi/ogm would be feasible. If I would
>> >
On Mon, 30 Jun 2003, Aubin Paul wrote:
> On Mon, Jun 30, 2003 at 04:40:41PM +0200, Thomas Schueppel wrote:
> > The idea of mmpython is to retrieve a common set of
> > information from these files. Hence using a common
> > table for wmv/avi/ogm would be feasible. If I would
> > layo
On Mon, Jun 30, 2003 at 04:40:41PM +0200, Thomas Schueppel wrote:
> The idea of mmpython is to retrieve a common set of
> information from these files. Hence using a common
> table for wmv/avi/ogm would be feasible. If I would
> layout the mmpython class structure into table
On Mon, Jun 30, 2003 at 04:06:25PM +0200, Thomas Schueppel wrote:
> I consider wrapping up other languages inside xml
> characterdata evil but defining an XML query language
> for this may become a little painful.
> I will check if there is some easy xquery interpreter tha
> But because most of these data types are distinctly different, we
> should treat them differently. The only special case I can think of is
> music videos, but wmv/avi/ogm files have pretty different information
> in them so we'd have to use something else.
The idea of mmpython is to retr
On Mon, Jun 30, 2003 at 09:02:20AM -0500, Krister Lagerstrom wrote:
> It would be nice if the security is layered outside of the database and
> the queries. I don't think it will be possible/desireable to parse all SQL
> queries to find "bad" code. It is better to restrict access to the machine
> i
On Mon, 30 Jun 2003, Aubin Paul wrote:
> On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
> >
> > select songs from music where
> > play_count=max(play_count) limit 25
> >
>
> Actually, allowing a proper SQL query would be a security hole, so it
> should be something like this
> On Mon, Jun 30, 2003 at 08:34:44AM -0500, Krister Lagerstrom wrote:
>> What would the security hole consist of, other than the user deleting
>> his own tables?
>
> Mainly, yeah. And you're correct, subselects are allowed, though
> that's not something I would want to cripple, because, coming from
On Mon, Jun 30, 2003 at 08:34:44AM -0500, Krister Lagerstrom wrote:
> What would the security hole consist of, other than the user deleting his
> own tables?
Mainly, yeah. And you're correct, subselects are allowed, though
that's not something I would want to cripple, because, coming from
MySQL, a
> On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
>>
>> select songs from music where
>> play_count=max(play_count) limit 25
>>
>
> Actually, allowing a proper SQL query would be a security hole, so it
> should be something like this:
>
>
> play_count=max(play_count) limi
On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
>
> select songs from music where
> play_count=max(play_count) limit 25
>
Actually, allowing a proper SQL query would be a security hole, so it
should be something like this:
play_count=max(play_count) limit
25
The '
On Sun, Jun 29, 2003 at 12:10:52AM +0200, Thomas Schueppel wrote:
> Okay, I get the point. Although BPM should be stored
> in the file. In fact there is an id3v2 field for that. :)
Well, we could store that, but I'd like to operate under the
assumption that the directories accessed by
On Sat, 28 Jun 2003, Aubin Paul wrote:
> On Sat, Jun 28, 2003 at 05:34:24PM -0400, Aubin Paul wrote:
> > By putting tag/filename data into a sqlite database, which is
> > essentially a single file with no daemon or anything, you can generate
> > smart playlists on the fly, like the examples I sugg
On a somewhat related note, I have to say that sqlite is very
impressive. The entire python module plus shared objects for sqlite is
less than 200k. I was able to create a database, a table, and perform
queries in around 15 lines of Python.
What would be really cool is if we made "Freevo Smart Pla
I agree with you.
MMpython use sqlite to store its cache is a viable options, and if we
have a way to relate things, like you've mentioned: last played, played
times and more we can do very good job...
Gustavo
--- Aubin Paul <[EMAIL PROTECTED]> escreveu: > On Sat, Jun 28, 2003
at 05:34:24PM -0
On Sat, Jun 28, 2003 at 05:34:24PM -0400, Aubin Paul wrote:
> By putting tag/filename data into a sqlite database, which is
> essentially a single file with no daemon or anything, you can generate
> smart playlists on the fly, like the examples I suggested. Doing that
> via cache files doesn't make
21 matches
Mail list logo
