Re: juk versus hayes

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: juk versus hayes
by Scott Wheeler on Thursday 12/Jun/2003, @16:31

Actually really the slowness for adding directories is because JuK:

- does a recursive scan of that directory
- adds playlists and audio files
- reads all of the tags at once and collects more information than i.e. XMMS
- optimizes for fast loading by doing all of the dirty work up front

Basically the idea behind JuK is to make the thing that you do infrequently (adding files) slow and make the things that you do more often (i.e. start the program) fast. As such, it caches all of the meta information and only updates it if the file is modified. I can load up my playlist of about 2400 files in about 3 seconds -- and aparently there are some people (hi Ian) using JuK with up to 50,000 items. Also I've tried to ensure that the GUI stays responsive while loading files so that JuK can still be used while loading files.

There will be some optimizations before 3.2 (I won't go into the details unless requested), but I would expect things to get 2-3x faster, not say 10-20x.

As compared to Hayes the main difference is that JuK is playlist / collection oriented and assumes that playlists and meta-data to be the primary way of organizing music; Hayes on the other hand assumes that the file system is being used for this. They're both valid takes on the problem and cater to different folks.

(D'oh, I guess I blew the cover; yes, JuK is for geeks too, though a significant motivation is keeping the interface simple and hiding the details that I'm talking about.)

Related Links

·   Articles on Multimedia
·   Also by Scott Wheeler
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: juk versus hayes
by Neil Stevens on Friday 13/Jun/2003, @00:22

I wonder, do you have anyone using JuK over NFS?

Hayes delays as much as possible, and does as little as possible, and I still get NFS complaints.

[ Reply To This | View ]

Re: juk versus hayes
by Scott Wheeler on Friday 13/Jun/2003, @03:01

It's not significantly worse over NFS on a 10 MB/s LAN than on the local file system (Daniel and I did a good bit of testing with this.). The initial scanning is slow -- but after that on load JuK just stats files on start up (and even that is delayed until after the GUI is up and usable in CVS). With stating files over NFS, your bottleneck is still a hard drive's seek time somewhere.

So while if you're loading 10,000 items over NFS it won't be exciting, you only have to do it once. After that you can read all of the items back in a few seconds.

Ian, who to my knowledge has the record for biggest collection in JuK (50k files) is on NFS.

[ Reply To This | View ]

Re: juk versus hayes
by Blue on Friday 13/Jun/2003, @13:45

I do. I have my home directories and MP3s on NFS. Nothing special, a 700MHz P3 with a big disk and a half-gig of RAM. I'm using 2.4.20 with the kernel nfs server on a 100m switched network.

It's perfectly usable. I've been using this setup (with various hardware/disk changes) for many years now without complaint.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Default settings are easy to manage." -- Aaron Seigo
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.