Hi PyToners! I just uploaded a pre-release for the next major PyTone version. It can be found under http://www.luga.de/pytone/download/PyTone-2.3.0-pre1.tar.gz Please test extensively as there are many, partially rather invasive, changes included in this release. In particular, a new database version requires an update. You, thus, should backup your song databases before running the new release for the first time and ensure that there is enough disk space for the upgrade. Included is a C version of the output buffer which needs the header files of the libao library for building. A detailed list of changes is attached. Enjoy, Jörg 2005-08-23 Jörg Lehmann <joerg@luga.de> * Add error reporting to bufferedao extension module. 2005-08-22 Jörg Lehmann <joerg@luga.de> * Disabled automatic closing of help window by default. * Added changeable play speed support (many thanks to Richard A. Smith <smithbone at gmail dot com> for providing the patch). 2005-08-21 Jörg Lehmann <joerg@luga.de> * Merged item-rework branch, which contains a new filter code. The new code makes the unfiltered case a special case of the filtered one. As a result, more than one filter can be applied, e.g., filtering for all songs in a certain genre of a given decade and with a given rating is now possible. Furthermore, every index now contains a (nearly) full directory hierarchy, thus allowing things like showing the top-played songs of a certain genre. 2005-08-19 Jörg Lehmann <joerg@luga.de> * Get rid of multi-file database layout: - convert old layout automatically - leave configuration file switches basename and dbfile intact but warn the user when they are non-empty - in a next step, we will set the default value of the basename switch to an empty value (when presumably all databases have been converted) - finally as a final step, we remove the switches and require that the users change their config files * Database version 5: do not longer index by years but by decades which removes many special code paths at various places in the db code. 2005-08-11 Jörg Lehmann <joerg@luga.de> * bufferedao.c: New C extension module corresponding to services/players/interal/buffereddevice with an ao device. The advantage of the C module is that it does not have to rely on holding the GIL when doing the output, which should help preventing sound dropouts. * services/players/internal.py: Make use of new extension module bufferedao. 2005-08-10 Jörg Lehmann <joerg@luga.de> * services/songdbs/internal.py: Checkpoint database regularly during registering of songs to prevent oversized transaction logs. * services/songdbs/internal.py: Replace quadratic in number of songs algorithm by a linear in time version to avoid huge system loads at the end of the song registering process. * services/players/internal.py: Do not open audiodevice without need. 2005-08-09 Jörg Lehmann <joerg@luga.de> * help.py, helpwin.py, statusbar.py: Introduced getkeyname function which has a fallback solution for unnamed keys (thanks to Troels Vognsen <bashfalcon at gmail dot com> for reporting this problem). 2005-08-03 Jörg Lehmann <joerg@luga.de> * Normalize all paths in config files. * Rework dbstats system. 2005-08-02 Jörg Lehmann <joerg@luga.de> * services/songdb.py. Measure cache size not by number of stored requests but by the number of objects the requests refer to. * services/songdb.py: rename resultcache -> requestcache. * conf/pytonerc, config.py, services/songdb.py: Add new section database with currently only one option requestcachesize, which allows one to configure the maximal number of objects contained in the cache. * item.py: Create genres/ratings/etc. instances only once to permit the caching of the requests involving them. * statswin.py, config.py, conf/pytonerc: New window for statistical information about databases and the request cache (accessible via "%"). * Various updates in German PyTone.po. 2005-07-16 Jörg Lehmann <joerg@luga.de> * plugin.py: Use thread-local channel in threadedplugin to make it actually a threaded plugin. * log.py: Add time and current thread to debugging output and prune common path from module name. 2005-07-16 Jörg Lehmann <joerg@luga.de> * filelist.py. Update window contents in filelistjumptosong(). * plugin.py. Daemonize threaded plugins, in order to prevent a blocking of misbehaved plugins on shutdown. * Initial checkin into Subversion repository. 2005-06-30 Jörg Lehmann <joerg@luga.de> * plugin.py: Use init() method instead of start(), which has a different meaning for threads. The plugins currently distributed with PyTone have been changed in this regard. * plugins/audioscrobbler/scrobbler.py: Fix typos in backlog code. 2005-06-28 Jörg Lehmann <joerg@luga.de> * config.py: Be more liberal concerning the accepted section names (patch by Dag Wieers <dag at wieers dot com>).
On Tue, 23 Aug 2005, Joerg Lehmann wrote:
Please test extensively as there are many, partially rather invasive, changes included in this release. In particular, a new database version requires an update. You, thus, should backup your song databases before running the new release for the first time and ensure that there is enough disk space for the upgrade.
Hi, First report: + At first the error was not clear that I had to convert my database from: ~/.pytone/music2a.db -> ~/.pytone/music2a/db only when checking what pytone did to have an empty database I noticed the dbname/db file. I love this change though, makes configuration much easier. + 450MB free diskspace was clearly not enough to convert a 7MB database from v4 to v5. And it only did 2500 records out of 3500. After making room, it used 820MB for 3440 records, and it seemed to slow down the longer it takes and diskspace usage is not directly related to number of records. (It seems to require progressively more) + The 920MB was not enough for my biggest database, it got stuck at 3500 records out of 3799 and consumed the complete 920MB free space. I had to free up 1.1GB for a 7MB database with only 3799 records. + After doing the last database, I noticed it said: 4 years, no clue what that means :) + Also it did not play automatically, just like before. The only way to make it play music is by starting it with -d test (and in return have a debug file that grows and grows :)) Don't know how to debug this though :/ PS Changing the speed is so funny :) It would be nice to have a window showing how much it is increased (much like the volume actually). Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
PS Changing the speed is so funny :) It would be nice to have a window showing how much it is increased (much like the volume actually).
I'm glad you like it. And even better I'm glad it works! A small indicator should be fairly easy. Each keypress is roughly 1%. The exact percentage would require some math between the different sample rates. -- Richard A. Smith
On Tue, 23 Aug 2005, Dag Wieers wrote:
On Tue, 23 Aug 2005, Joerg Lehmann wrote:
Please test extensively as there are many, partially rather invasive, changes included in this release. In particular, a new database version requires an update. You, thus, should backup your song databases before running the new release for the first time and ensure that there is enough disk space for the upgrade.
First report:
Second report: + The default settings (with my hardware) using /dev/dsp makes the playback freeze when switching songs. device = /dev/dsp bufsize = 100 crossfading = on crossfadingstart = 5 crossfadingduration = 6 I don't know if this was the case before, but I know it was changed to a bufsize of 500 by me previously. I am now also using a crossfadingstart of 3 and crossfadingduration of 3 with only a bufsize of 300. Need to see if this makes the manual song switching more interactive. + I am interested in translating pytone to Dutch, if someone has good pointers where to start. I also need to investigate what terminology is used in Dutch, as I always use programs in English :/ + I'm wondering whether it makes sense to make 'w' also a shortcut to search by default. I'm often mistaken because I confuse it with the pine option for searching, I know that's not a good excuse, but maybe others have the same problem ? (and yes I already configured it like this for myself :) + Also would it be possible to keep the search window in place when pressing enter, and move to the next song when pressing enter again. The escape key (or a time out) could get you out of the window, it seems more natural to me than having you window disappear on you on the first match (which almost never was what I was looking for). + The extended search was interesting, even though I'm not quite clear how it should be extended :) However an XMMS like 'jump to song' functionality (based on both artist and songtitle) is still on my wishlist and provides a very interactive interface to quickly find what you were looking for. + I love the statistics :) + I was wondering if it was possible to put the Artists also in a seperate level instead of the root level. + In order to simplify the configuration, would it be possible to default to a dbenvdir like ~/.pytone/<dbname>/ so that it is not mandatory. Also not make basename not mandatory (I now have it as an empty option) and make type = local the default Thanks Joerg ! Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi Dag! On 23.08.05, Dag Wieers wrote:
On Tue, 23 Aug 2005, Joerg Lehmann wrote:
Please test extensively as there are many, partially rather invasive, changes included in this release. In particular, a new database version requires an update. You, thus, should backup your song databases before running the new release for the first time and ensure that there is enough disk space for the upgrade.
Hi,
First report:
+ At first the error was not clear that I had to convert my database from:
~/.pytone/music2a.db -> ~/.pytone/music2a/db
only when checking what pytone did to have an empty database I noticed the dbname/db file. I love this change though, makes configuration much easier.
Yes, this was a mess in the first place. I hope the conversion doesn't lead to too many problems, though.
+ 450MB free diskspace was clearly not enough to convert a 7MB database from v4 to v5. And it only did 2500 records out of 3500. After making room, it used 820MB for 3440 records, and it seemed to slow down the longer it takes and diskspace usage is not directly related to number of records. (It seems to require progressively more)
+ The 920MB was not enough for my biggest database, it got stuck at 3500 records out of 3799 and consumed the complete 920MB free space. I had to free up 1.1GB for a 7MB database with only 3799 records.
Sounds familiar to me. Maybe, we should checkpoint the database in between. I didn't do that because during the whole upgrade, we're in a single transaction (in order to avoid breaking the whole db, when something goes wrong during the upgrade). Ok, I just tried that and it didn't help :-(
+ After doing the last database, I noticed it said: 4 years, no clue what that means :)
Not too much, just that you had 4 different years in your database. Didn't there appear a "Done" afterwards?
+ Also it did not play automatically, just like before. The only way to make it play music is by starting it with -d test (and in return have a debug file that grows and grows :))
Don't know how to debug this though :/
Have you tried -d /dev/null. Note, however, that debugging leads to a noticeable performance degradation. Otherwise, the only thing I can suggest is to add log.info calls in the player code in order to find out where it hangs.
PS Changing the speed is so funny :) It would be nice to have a window showing how much it is increased (much like the volume actually).
Yes, I also noticed that. And I also would suggest that we make the change "multiplicative" and not "additive" as it currently is. This corresponds much more to the way human perception works. Jörg
PS Changing the speed is so funny :) It would be nice to have a window showing how much it is increased (much like the volume actually).
Yes, I also noticed that. And I also would suggest that we make the change "multiplicative" and not "additive" as it currently is. This corresponds much more to the way human perception works.
That would be a pretty trivial change. I have it the way it is for specific reasons although they don't make any difference to pytone since its more of a novelity rather than a feature. Perhaps the people using pytone for DJing might find it useful. What factor would you use? -- Richard A. Smith
+ 450MB free diskspace was clearly not enough to convert a 7MB database from v4 to v5. And it only did 2500 records out of 3500. After making room, it used 820MB for 3440 records, and it seemed to slow down the longer it takes and diskspace usage is not directly related to number of records. (It seems to require progressively more)
+ The 920MB was not enough for my biggest database, it got stuck at 3500 records out of 3799 and consumed the complete 920MB free space. I had to free up 1.1GB for a 7MB database with only 3799 records.
Sounds familiar to me. Maybe, we should checkpoint the database in
I don't know a whole lot about berkely db. Why does it take +450MB to convert over a 7Mb database? Thats about 64 times larger. -- Richard A. Smith
Hi Richard! On 24.08.05, Richard Smith wrote:
+ 450MB free diskspace was clearly not enough to convert a 7MB database from v4 to v5. And it only did 2500 records out of 3500. After making room, it used 820MB for 3440 records, and it seemed to slow down the longer it takes and diskspace usage is not directly related to number of records. (It seems to require progressively more)
+ The 920MB was not enough for my biggest database, it got stuck at 3500 records out of 3799 and consumed the complete 920MB free space. I had to free up 1.1GB for a 7MB database with only 3799 records.
Sounds familiar to me. Maybe, we should checkpoint the database in
I don't know a whole lot about berkely db. Why does it take +450MB to convert over a 7Mb database? Thats about 64 times larger.
Hey, good question. I think the transaction log file format is not too efficient. Jörg
Teilnehmer (3)
-
Dag Wieers -
Joerg Lehmann -
Richard Smith