Repository: beetbox/beets

Issue:
Slowdown with beet web - regression
There is a massive slowdown in queries with python2 and python3 when using the beet web interface. 

When large queries are run, i.e. 'format:flac' on a flac only library, the web interface posts queries 10x slower than before the regression.  To clarify that does seem to be a relative time based on the length of time originally taken by the query. 

This is caused by a regression in the commit. 
https://github.com/beetbox/beets/commit/5e8ac9e4a5d06de791fe051a419ba070bbdd5bec

beet stats 
Tracks: 43913
Total time: 51.4 weeks
Approximate total size: 976.18 GiB
Artists: 7345
Albums: 12004
Album artists: 1800



Discussion:
@cobra2 said that with this commit included it takes 80-100 seconds, and with the change reversed it's about 10 seconds.

Thanks for the report. @maxammann, you added this path field—how necessary is it really? We could consider just exposing the real file path, which should be much faster, although I'm not 100% sure why we need the path here at all.

@sampsyo : probably this https://github.com/maxammann/music-cyclon

"Android app to synchronize music or files over network by using the beets web server""

EDIT: definitely that.  it says "Waiting for pull request: https://github.com/beetbox/beets/pull/2050 " . That's the change that introduced this.

Got it; thanks. I'm just not 100% sure why it needs us to generate paths… couldn't that happen client-side?

Anyway, we could make it a config option to decide whether to expose real file paths. (Off by default for privacy's sake.)

Should we consider this a blocker bug?

Maybe we should just roll back the change and call it good? If @maxammann is interested in adding it back, that's of course cool but not worth blocking release.

So what about https://github.com/beetbox/beets/issues/2177 ?  You mention that PR as the solution

Yeah, I'm not exactly sure what's going on there. It's not entirely clear to me that they need the path in the web API---in any case, it shouldn't be hard to add back if necessary.

This is also in the changelog, so if it does get backed out, it'd have to be removed from there too.

Currently traveling for this month but I'll look into it when I come home again. For now just revert that commit if it makes trouble. 

I think its still a valuable feature. Maybe we should add a flag to toggle "expensive" output? 

Yeah, absolutely—I do think it should be an option.

Back at home, going to fix this and push a pull request in a few days. Is it urgent right now, because it's a blocker? Or does the new release take a few more weeks?

@maxammann : which route are you gonna take for a fix?

@jrobeson sorry, had some family related problems the past week, I'll introduce a new flag to disable the expensive output.

a flag to disable? shouldn't it be a flag to enable? In the future, it shouldn't nearly be so expensive, so hopefully we can can drop the flag all together.

Only @sampsyo can say how urgent this is. I'm not sure when he's ready to push a new release.

@jrobeson yeah, sorry, I mean a flag to enable :P


Resolving patch:
diff --git a/beetsplug/web/__init__.py b/beetsplug/web/__init__.py
--- a/beetsplug/web/__init__.py
+++ b/beetsplug/web/__init__.py
@@ -37,7 +37,7 @@ def _rep(obj, expand=False):
     out = dict(obj)
 
     if isinstance(obj, beets.library.Item):
-        out['path'] = obj.destination(fragment=True)
+        del out['path']
 
         # Get the size (in bytes) of the backing file. This is useful
         # for the Tomahawk resolver API.


Test patch: