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
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 Paul wrote:
On Sun, Jun 29, 2003 at 10:19:09AM +0200, Dirk Meyer wrote:
Cool, than try to change cache.py in mmpython to a new caching
model. Maybe make a cache_sqlite.py so that the current cache can be
used if you don't have sqlite. Maybe with sqlite we can cache _all_
metadata, right
On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
freevo
smart_playlistselect songs from music where
play_count=max(play_count) limit 25/smart_playlist
/freevo
Actually, allowing a proper SQL query would be a security hole, so it
should be something like this:
freevo
Aubin Paul wrote:
On Mon, Jun 30, 2003 at 12:40:21PM +0200, Dirk Meyer wrote:
I just started and looked into musicsqlimport.py. Looks very easy to
me. Is it possible to add 'data', too? With data I mean no string or
integer, but maybe images (thumbnails from images and covers from
mp3). It
Aubin Paul wrote:
On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
freevo
smart_playlistselect songs from music where
play_count=max(play_count) limit 25/smart_playlist
/freevo
Actually, allowing a proper SQL query would be a security hole, so it
should be something like
On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
freevo
smart_playlistselect songs from music where
play_count=max(play_count) limit 25/smart_playlist
/freevo
Actually, allowing a proper SQL query would be a security hole, so it
should be something like this:
freevo
On Mon, Jun 30, 2003 at 03:31:48PM +0200, Dirk Meyer wrote:
They are part of the information about the file. When I query for all
images with the location 'siena' (some from my last vacation), I want
to get a list of all images including everythin mmpython knows about
the file. And a very
On Mon, Jun 30, 2003 at 03:33:50PM +0200, Dirk Meyer wrote:
No, maybe I have music videos? Or search for images/videos?
freevo
smart_playlist type=(audio|video|image)play_count=max(play_count) limit
25/smart_playlist
/freevo
Music videos could probably fit into the music table,
Aubin Paul wrote:
On Mon, Jun 30, 2003 at 03:31:48PM +0200, Dirk Meyer wrote:
They are part of the information about the file. When I query for all
images with the location 'siena' (some from my last vacation), I want
to get a list of all images including everythin mmpython knows about
the
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, 30 Jun 2003, Aubin Paul wrote:
On Mon, Jun 30, 2003 at 09:04:27AM -0400, Aubin Paul wrote:
freevo
smart_playlistselect songs from music where
play_count=max(play_count) limit 25/smart_playlist
/freevo
Actually, allowing a proper SQL query would be a security hole, so it
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
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
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 that
On Mon, Jun 30, 2003 at 03:56:13PM +0200, Dirk Meyer wrote:
OK, I meant it this way. But mp3 files can have covers inside. Should
we support them?
Like APIC data?
No, every 'type' of media should have an extra table: audio, video,
images. Maybe extra handling for 'discs'.
Oh, so like we
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 tables I
Aubin Paul wrote:
On Mon, Jun 30, 2003 at 03:56:13PM +0200, Dirk Meyer wrote:
OK, I meant it this way. But mp3 files can have covers inside. Should
we support them?
Like APIC data?
Yes, this little APIC field :-)
No, every 'type' of media should have an extra table: audio, video,
images.
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
layout the
On Mon, Jun 30, 2003 at 06:01:17PM +0200, Dirk Meyer wrote:
Yes, this little APIC field :-)
I think we should cache them somewhere; but putting them in the
database isn't such a good idea.
First, sqlite by default has a maximum column width of 320bytes. It
can be recompiled to do up to 16mb,
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 advanced
Aubin Paul wrote:
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.
Cool, than try to change cache.py
On Sun, Jun 29, 2003 at 10:19:09AM +0200, Dirk Meyer wrote:
Cool, than try to change cache.py in mmpython to a new caching
model. Maybe make a cache_sqlite.py so that the current cache can be
used if you don't have sqlite. Maybe with sqlite we can cache _all_
metadata, right now we don't cache
On Sat, Jun 28, 2003 at 09:58:37PM +0200, Dirk Meyer wrote:
Like Thomas said, mmpython does caching. When I integrate the whole
set of features of mmpython we can fast access all metadata from
files. Not only mp3 id tags, also informations in videos (I was
suprised to see what avis and mov
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
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
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
28 matches
Mail list logo
