Re: [xwax-devel] Beta release 1.1-beta2
Brought to you by:
hills
Menu
▾
▴
Re: [xwax-devel] Beta release 1.1-beta2
|
From: Olivier G. <ol...@os...> - 2012-01-29 17:49:04
|
On 29/01/12 09:37 AM, Mark Hills wrote: > On Sat, 14 Jan 2012, Mark Hills wrote: > >> On Fri, 13 Jan 2012, Olivier Gauthier wrote: >> >> [...] >>> Patch 2 simply address an hassle that I had with xwax since the >>> beggining. It simply adds a File extension filter passed to "find" >>> command in the scanner. This removes any non-audio files from the >>> library interface, allowing quicker track selection. I tested xwax 1.0 >>> with more than 280 Gb of music collection, counting around 15000 >>> tracks. >> >> Cool, this came up a while ago and I think it's probably a good thing. Is >> there a way to shorten the syntax to for readability and editibility? >> >> The best I could come up with was: >> >> find -regextype posix-egrep -regex '.*\.(flac|mp3|ogg|aac)' >> >> but I'm not sure these regex flags are widely available. > > Anyone able to take a look at this? If I can be sure we've looked at all > the options then I can merge the best one. > > I'd like to keep the import script as tidy as possible, as it's something > that new users customise and modify. I just made different tests with both find options. I wanted to compared the speed of both and that it output the same exact list. Both were tested against my music library on my server, which is mounted with CIFS and served with Samba through a gigabit link. Egrep method returned a result set containing 38177 music files, -iname method returned a result set containing 38194 music files. The discrepancy was illustrated using Diff, and it showed that the egrep is not case insensitive. I tried to put both extensions, upper case and lower case in the regex string, but I missed the case were extension are written in camel case. I.e. ".Mp3" or ".mP3". This caused to miss a entire album. I had two other lines that were properly listed using the -iname option but not using egrep. > 12854a12870 >> /net/kickbass/home/oligau/public/musique/friends/jf/Electro/--Ambian - Minimal--/BUDDHA BAR/Cafe del Mar - Vol 1 - (Full Album) Buddah Bar.mp3 > 26726a26743 >> /net/kickbass/home/oligau/public/musique/incoming/tekno! 12gb emule/DJ Cess - [Neutral Korp] Mixtape Tekos.2002 -[www Noizemule Zik Mu] [found via www.FileDonkey.com]/DJ Cess' Neutral.Korp mix-tape tekos 2002 complet[www.noizemule.zic.mu]freeparty hardtek tekno tribe .mp3 I cannot say why there werent caught by egrep, but I would say that the regex is not liking weird path that contains multiple extensions and spaces. Performance wise, I used time utility to time each iteration. I made 10 iterations the make to eliminate the file system caching factor. We can see that egrep method is faster for the first 3 iterations, and then both seems on par with each other. Maybe the best option would be to make xwax-scan script look in a configuration file to build the filter option on the fly. The xwax front-end I'm trying to put up in pygtk will be using a key/value configuration file that'll be stored in ~/.xwaxfe/. Vincze Péter is also working a xml file format to be able to store cuepoints in your library folder. I suggests that skining, cuepoints and configuration could all share the same reader/writer code in the xwax codebase. Suggestions are welcome here... Ultimately, I'm working to be able to feed my library from a external component, like MPD. I don't know if I'll continue to use the actual xwax-scan script as it is right now. > Time took by posix-egrep > 0.44user 1.18system 0:10.46elapsed 15%CPU (0avgtext+0avgdata 5456maxresident)k > 632inputs+10312outputs (4major+636minor)pagefaults 0swaps > Time took by -iname filter > 0.66user 1.48system 0:19.89elapsed 10%CPU (0avgtext+0avgdata 5040maxresident)k > 200inputs+10320outputs (2major+613minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.56user 1.28system 0:15.48elapsed 11%CPU (0avgtext+0avgdata 5440maxresident)k > 0inputs+10312outputs (0major+638minor)pagefaults 0swaps > Time took by -iname filter > 0.82user 1.62system 0:25.69elapsed 9%CPU (0avgtext+0avgdata 5040maxresident)k > 248inputs+10320outputs (4major+608minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.59user 1.06system 0:11.69elapsed 14%CPU (0avgtext+0avgdata 5440maxresident)k > 80inputs+10312outputs (1major+638minor)pagefaults 0swaps > Time took by -iname filter > 0.66user 1.33system 0:16.88elapsed 11%CPU (0avgtext+0avgdata 5024maxresident)k > 248inputs+10320outputs (4major+608minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.53user 1.28system 0:15.30elapsed 11%CPU (0avgtext+0avgdata 5456maxresident)k > 0inputs+10312outputs (0major+642minor)pagefaults 0swaps > Time took by -iname filter > 0.65user 1.27system 0:14.51elapsed 13%CPU (0avgtext+0avgdata 5040maxresident)k > 248inputs+10320outputs (4major+608minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.48user 1.03system 0:10.11elapsed 15%CPU (0avgtext+0avgdata 5456maxresident)k > 0inputs+10312outputs (0major+641minor)pagefaults 0swaps > Time took by -iname filter > 0.70user 0.86system 0:08.40elapsed 18%CPU (0avgtext+0avgdata 5040maxresident)k > 0inputs+10320outputs (0major+612minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.48user 0.90system 0:06.88elapsed 20%CPU (0avgtext+0avgdata 5440maxresident)k > 64inputs+10312outputs (1major+637minor)pagefaults 0swaps > Time took by -iname filter > 0.61user 0.94system 0:07.55elapsed 20%CPU (0avgtext+0avgdata 5024maxresident)k > 16inputs+10320outputs (1major+610minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.54user 0.78system 0:05.63elapsed 23%CPU (0avgtext+0avgdata 5456maxresident)k > 80inputs+10312outputs (1major+639minor)pagefaults 0swaps > Time took by -iname filter > 0.68user 0.96system 0:09.80elapsed 16%CPU (0avgtext+0avgdata 5040maxresident)k > 0inputs+10320outputs (0major+612minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.50user 0.81system 0:05.59elapsed 23%CPU (0avgtext+0avgdata 5440maxresident)k > 80inputs+10312outputs (2major+635minor)pagefaults 0swaps > Time took by -iname filter > 0.66user 0.83system 0:06.29elapsed 23%CPU (0avgtext+0avgdata 5040maxresident)k > 48inputs+10320outputs (2major+612minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.45user 0.86system 0:05.05elapsed 25%CPU (0avgtext+0avgdata 5440maxresident)k > 0inputs+10312outputs (0major+638minor)pagefaults 0swaps > Time took by -iname filter > 0.65user 0.78system 0:05.26elapsed 27%CPU (0avgtext+0avgdata 5024maxresident)k > 0inputs+10320outputs (0major+611minor)pagefaults 0swaps > > > Time took by posix-egrep > 0.47user 0.96system 0:07.75elapsed 18%CPU (0avgtext+0avgdata 5440maxresident)k > 0inputs+10312outputs (0major+637minor)pagefaults 0swaps > Time took by -iname filter > 0.64user 0.84system 0:06.63elapsed 22%CPU (0avgtext+0avgdata 5024maxresident)k > 16inputs+10320outputs (1major+610minor)pagefaults 0swaps |