faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
juk versus hayes
by ik on Thursday 12/Jun/2003, @15:12
|
i tried both noatun+hayes and juk, and i still prefer hayes (altough juk is nice) (http://www.freekde.org/neil/hayes/hayes.png), but that is probably a matter of taste. I really like the filesystem-based concept of hayes..
juk also has some problems that need to be sorted out: 'add directory' takes a loong time here (it takes more than a minute, xmms loads the same directory in a couple of seconds). xmms only loads id3 tags when they are shown, maybe that has something to do with it (but i don't think its the only reason). but kde3.2 is not released yet offcourse |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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.)
|
[
Reply To This | View ]
|
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 )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
