2010/4/5 PCMan <[email protected]>:
> Actually this is correctly handled.
> On startup, lxmusic cache branch load track info from our local cache
> and show them to the users. Then, it still queries data from medialib.
> Later, medialib will return the requested data. LXMusic then compares
> the mtime of retrived entires and the one in our cache. If the ones in
> medialib are newer, it replace current track info with the newer one,
> and later the new info is writen to cache, too. If the retrived
> entries are not newer, then LXMusic prevents unnessary UI updates.
> That's how it works. So the users can still get the latest info in
> medialib. Nothing will be broken.
Thus all IPC traffic will still happen. Cache (maybe outdated) will be
used to show tracklist metadata on startup, while still all "up2date"
metadata is requested via IPC to fix invalid Client-side data.
A real cache-aware XMMS2 Client would require a client function like this:
xmmsc_medialib_get_info_if_newer (xmmsc_connection_t *c, int id, int lmod)
^^^^^^^^^^
Again: Instead of creating workarounds the following options should be used:
1. Support new medialib backend developed by upstream: Most likely all
performance issues will be gone.
2. Implement cache-aware xmms2-client functions upstream.
I prefer "1" to keep LXMusic lightweight as the name implies.
Jürgen
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
