MOC slow on remote file systems

Submitted by Nidan on Sat, 2012-12-29 02:58

Forums:

Hi,
I've been using moc for a while now (at least a year) and I like it.

However I noticed the client takes a lot longer to start if the files in the playlist are on a remote file system. During this startup time moc is unresponsive.

Stracing a starting client shows that it stat()s every file in the playlist 4 times. Why? (ReadTags was set to no, command line was ./mocp -D, build from current svn)

With ReadTags set to yes loading a playlist (obviously) slows down more. Is it possible to expand the ReadTags option to include additional values like "visible or "played" which only request tags for files currently visible on the screen or currently playing?

jcf

Sat, 2012-12-29 07:27

I did note that MOC performs multiple (and sometimes redundant) stat()s but thought it was easier to let the OS cache the files' metadata than to provide local caching. However, in the case of remote filesystems it does obviously become an issue. I'll place it on the TODO list.

If stat()ing cannot be reduced sufficiently for remote file systems it might be possible to trade off (by option) some functionality against liveliness.

As to the additional ReadTags option values, the tags cache (if it's local) should take care of it for files already played but the multi-client architecture of MOC could make them difficult to implement otherwise.