On 2013/10/20 09:22, Jean-Francois Dockes <j...@dockes.org> wrote: > The second part of the patch changes the file db/ProxyDatabasePlugin.cxx. > This file was a skeleton, containing mostly empty methods. What the patch > does is just add implementation where there was none, there are very few > modifications of existing code (a few additional parameters to calls > internal to the file). Because the original file was almost empty, I think > that it would be simpler to look at the patched result than to discuss the > patch itself. > > The existing ProxyDatabase plugin is not configured in the default mpd, and > not usable anyway.
Why do you think so? I've been using it for a while. > I am not claiming that the patched version is ready for production, > but it does supply a viable implementation for testing. > > To come back to the more general issue, I have now experience in > implementing two Database plugins: > > - The one in the patch, which uses the database from a remote mpd. > > - A second one, which uses an UPnP MediaServer as the remote. This one is > currently working for browsing the Content Directory and playing songs > (accessed through the curl input plugin), but the search parts are not > implemented, mostly because of issues in the plugin interface. However > if someone wanted to give it a try, I was getting ready to supply the > current version. It would be interesting to try it with other > MediaServers, because I have only tested MediaTomb and minidlna at this > point. > > The Database plugin interface currently assumes that a recursive walk of > the database can generally be done, and that it can be used for > searching. Why makes you believe that? What part of the DatabasePlugin API does that? > However, in the case of a remote mpd, it is highly inefficient to > walk the tree for performing a search, something like 100 times > slower than a local search. > > For the "VisitUniqueTags" method, I was able to delegate the search to > the remote mpd, and this is what necessitated the opening of the > SongFilter class described above: I have to get at the search criteria > so that I can build a search for mpd_search_db_tags() to remotely > perform. > > In the case of a song search, I appear to be bound, because the Visit() > API method seems to require a recursive tree walk and the songs are > filtered during the walk. No, you don't even need a recursive tree walk there. You can still pass all the criteria to MPD - all but one: the base URI, because the MPD protocol can't limit a search to a sub directory. So you have two choices: - start walking recursively at the specified base URI and do matches locally (what ProxyDatabasePlugin does currently) OR - pass the criteria to the other MPD, i.e. let it match - and discard all results that are outside of the base URI and maybe a third choice: - implement support for base URI matching in MPD, so this one can be passed, too - allowing our MPD to marshal the whole DatabaseSelection object into a request to the other MPD > In the case of a remote UPnP MediaServer, a tree walk is mostly > impossible: And you don't need it. Max ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
