Aubin Paul wrote:
> True... though there will be warning if we change the default, in the
> sense that it will accompany a pretty significant release with lots of
> other changes... and the old behaviour will always be available for
> those who want it.
It is now. And the warning is in the log
"Chris Griffiths" wrote:
> On the tivo you get an arrow next to it if theres a sub-menu to that
> option, but this only works as all navigation can be done via
> up/down/left/right (while rules by the way, you just keep your thumb on
> the joypad-like bit of the remote).
You could set the key RIGH
Aubin Paul wrote:
> I made a small set of preview screenshots to show some of the neat
> stuff in Freevo 1.5 (?) and I'd like to announce it on the website,
> but thought I'd run it by the other devs first:
>
> http://freevo.sourceforge.net/preview/
Looks nice. This you named the mail 'thoughts',
Aubin Paul wrote:
> There are two things I figure should be added to the 'freevo' shell
> script:
>
> i.e.
>
> freevo src/tv/record_daemon.py
> could be
> freevo daemon
> and
> freevo src/tv/epg_xmltv.py
> could be
> freevo processguide
>
> It's not hard to do them, obviously, but s
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, 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, bu
"Krister Lagerstrom" wrote:
> For instance, I have backed up a large number of my legally purchased VHS
> tapes and music CDs to my harddrives. I add harddrives as I need more
> space, but I usually want to browse my movies by genre (comedy, action,
> etc), not by which harddrive they happen to be
> 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
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,
>
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 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: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
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
>
On Mon, Jun 30, 2003 at 03:33:50PM +0200, Dirk Meyer wrote:
> No, maybe I have music videos? Or search for images/videos?
>
>
>
> play_count=max(play_count) limit
> 25
>
Music videos could probably fit into the music table, but I'm not sure
how we'd handle images/videos in the same que
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 s
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
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:
>
>
> play_count=ma
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
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 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 would be nice to h
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_
>> metadat
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 ca
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.
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
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
Aubin Paul wrote:
> On Fri, Jun 27, 2003 at 05:35:17PM +0200, Joakim Berglund wrote:
>> Well... a database has advantages but also disadvantages...
>> It absolutly requiers that you music has a valid and correct mp3 info
>> otherwise it would just be filed in very strange categories.
>> If you are
40 matches
Mail list logo
