>>>>> Andy Grundman <[email protected]> writes: > Oh, yeah, the time is definitely proportional to the amount of tag > changes. It does not run the same thing as a "look for changes" scan.
> The goal is to support playlist changes in seconds, yes. No need to > merge artists as you say. This is absolutely great news Andy, thank you!! I think I caught elsewhere that you're also squashing the remaining issues where a "changes" scan gives different results than a "wipe and rescan", so this will rock.. > There's not much else I can say other than to invite you to use > Devel::NYTProf to profile a scan and get an idea for the bits that are > slow. It's almost all DBIx::Class code. I plan to work with those > guys to try and improve performance, but not for this release. That's a fine answer; I've been planning to go grovel around in there for a few years now, so maybe after your stuff gets merged to 7.4 trunk I'll play around with it. Thanks for the pointer to the profiler - perl's not really a primary language for me so that should save me some time. greg _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
