Clearing nStream's UPNP cache

Posted by: Hook on 21 July 2013

I've noticed that over the course of a couple of months or so, nStream performance will start to degrade.  When it becomes noticeable, I simply clear the UPNP cache and...viola, nStream becomes lightning fast once again.

 

This strikes me as counter-intuitive.  Isn't the purpose of caching to improve performance by storing information about devices, indexes, and so on, locally on the iPad/Pod/Phone? I would have thought that the longer one went without clearing the cache, the faster nStream should run, because it would need to fetch information from the server less often.

 

Could this be a bug in nStream, where old data is not aging out and being deleted?  Is the cache just becoming too large and unwieldy over time?

 

Thanks for helping me to understand how this works!

 

Hook

Posted on: 21 July 2013 by Doc

Hook - I have noticed the same problem

Posted on: 21 July 2013 by Dungassin

Another problem I have noticed is that after a few additions, Asset will sometimes give incorrect album art or title when using nStream.  this is cured by clearing the upnp and image caches in nStream.  Don't know which program is at fault.

 

John

Posted on: 21 July 2013 by Bart

Hopefully a programmer can chime in, as I'm curious too but know nothing of the substance.  This seems not so rare, at least in concept, that caches need to be cleared.  Years ago it was common to be able to improve browser performance (in Windows) by clearing the cache.  I suppose that software is done better these days, as the need to do that, or to defrag a hard drive, etc etc, seems to come up less.  "Database maintenance" still seems to exist somewhat it seems, however.  But maybe only on legacy systems(??)

 

Specifically with nServe and iOS, I wonder if it's how nServe was written or if it's an iOS issue.

Posted on: 21 July 2013 by Hook

If we don't see any replies from Phil or anyone else at Naim by end of tomorrow, I'll shoot support a quick email.

 

Like Dungassin, I too am using Asset, and around the same time things start to slow down, I too will see an occasional mis-match of artist/album title to the actual tracks listed In the library view.  Have done a bit of google searching, and so far I have not been able to find any similar issues with Asset and/or other control point apps.  But who knows...

 

My guess is that both of these problems are related to bugs in nStream's cache management logic. Not a big deal, since the cache is easily reset, but it would be nice to see this fixed in a future release.

 

ATB.

 

Hook

Posted on: 21 July 2013 by DaveBk

Just speculation... We know from previous threads on playlists that the uPnP protocol does not guarantee that any of the internal index references remain static. When you browse the directory tree, uPnP returns its own shorthand reference URLs that are just character strings, with no human readable information. nStream caches all these internal references to avoid searching the directory each time and therefore speeds up access and also allows the alphabetic quick index feature.

 

From time to time (usually when you rip a new batch of CDs) the uPnP server can reorganise its internal reference data. As there is no 'contract' within the protocol that these references will remain static, this is not a bug, rather an inconvenient feature from the perspective of anything that has cached the information.

 

Most cache architectures expect there to be changes and updates to the master data, so implement cache refresh strategies to try and keep the cache clean. These can be time based, so for example only trust a cached entry if it is less than say 30 minutes old, or based of detecting an error where the cached result no longer matches whatever was expected.

 

Have no idea what kind of cache refresh strategy nStream uses, but from my own experience it is not perfect (nor can it be, as it's very difficult to solve and always requires a compromise). Over time, it does seem to degrade and produce the odd error - I've just got into the habit of manually refreshing from tIme to time.

 

Maybe as a career long IT professional I have just become too tolerant of these kind of scenarios as they are devilishly difficult to solve.

Posted on: 21 July 2013 by Hook

Excellent post Dave -- thank you very much for your insights!

 

I am a little surprised to hear that there isn't a stronger set of rules governing UPNP cache coherency. But then, given the consequences aren't that severe, and given how easy it is to clear the cache, I suppose this makes some sense. I imagine, given that control point apps have to run on small devices like iPhones, that the code needs to stay very lightweight.  Spend too many cycles trying to keep the local cache perfect, and I suppose you could introduce new performance problems.

 

A long time ago, a crusty old computer systems engineer told me "hardware will eventually break, and software will eventually work". It does seem to take Naim a long time to deliver software updates, but at least their hardware runs trouble free for long periods of time.  Got to give them credit for consistent use of the word "eventually".   ;-)

 

ATB.

 

Hook

 

Posted on: 21 July 2013 by Harry

Good tip Hook. I do this myself. Although nStream is fairly nifty, nServe is much crisper, particularly when resuming from my iPad's sleep state. Hopefully this will be addressed in due course.

Posted on: 23 July 2013 by DQ
Hey Does clearing the cache do anything to playlists or do they endure past a cache clearing? Cheers