MP2, plugins, and multiple clients. (2 Viewers)

[tourettes]

Re: AW: Re: MP2, plugins, and multiple clients.

Which kind of download are you referring to? Download of images/media items from their original storage location inside the MP2 system or download from a remote location somewhere in the internet?

I think he was referring to the things like FanArt or movie covers. I think those should be handled as a metadata for the movie files itself, stored centrally on the server (data blobs out of the DB itself).

 

[mbuzina]

I would also recommend to setup a caching mechanism for such metadata images at the client. You could use a defined size on the local storage to cache thumbnails, fanart and others to improve browsing experience.

 

[funkstar]

Thanks for the detailed explanation Albert, it sounds like there has been a lot of thought put into the mechanisms that will allow great flexability in MP2.

The future's bright, the future's... blue ish.

 

[Baboonanza]

Re: AW: Re: MP2, plugins, and multiple clients.

Which kind of download are you referring to? Download of images/media items from their original storage location inside the MP2 system or download from a remote location somewhere in the internet?

Perhaps he means things like music/movie/TV show fanart and thumbs that are downloaded from the internet. It would make sense for these images to be stored at the same location as the media they are associated with, so if a movie is on the server the fanart for it is there also, if it is local to the client then the fanart is local too.

 

[Truri]

AW: Re: AW: Re: MP2, plugins, and multiple clients.

Which kind of download are you referring to? Download of images/media items from their original storage location inside the MP2 system or download from a remote location somewhere in the internet?

Perhaps he means things like music/movie/TV show fanart and thumbs that are downloaded from the internet. It would make sense for these images to be stored at the same location as the media they are associated with, so if a movie is on the server the fanart for it is there also, if it is local to the client then the fanart is local too.

I think that would be really useful.

At least a way, that all the downloaded Covers,Posters, Fanart is only stored and downloaded once and not on and for every client.

 

[Guzzi]

AW: Re: MP2, plugins, and multiple clients.

I would also recommend to setup a caching mechanism for such metadata images at the client. You could use a defined size on the local storage to cache thumbnails, fanart and others to improve browsing experience.

agree ... while I think it's great and necessary to hold metadata (and thumbs) centrally on the server, please don't forget to integrate some caching mechanism - today (according filemon) - some screens need substantial time to read inside the thumbs folders - especially, when there are several thousand thumbs inside. Assuming, that in 1-2 years, most people will have their htpc client on a SSD, this will substantially speed up browsing (when reading from local drive) - and that should be supported by local caching and not slowed down by reading everything over the network ....

 

[Baboonanza]

Re: AW: Re: MP2, plugins, and multiple clients.

I would also recommend to setup a caching mechanism for such metadata images at the client. You could use a defined size on the local storage to cache thumbnails, fanart and others to improve browsing experience.

agree ... while I think it's great and necessary to hold metadata (and thumbs) centrally on the server, please don't forget to integrate some caching mechanism - today (according filemon) - some screens need substantial time to read inside the thumbs folders - especially, when there are several thousand thumbs inside. Assuming, that in 1-2 years, most people will have their htpc client on a SSD, this will substantially speed up browsing (when reading from local drive) - and that should be supported by local caching and not slowed down by reading everything over the network ....

Good points. I have been thinking about possible image caching strategies recently but I hadn't considered that local SSD storage. The problem is that there isn't any 'correct' solution because results will vary greatly across systems. The options are:

Server RAM cache - Compressed images stored in RAM to reduce latency.
Client HDD cache - Compressed images (whose original source is the server) stored on local HDD. This would only really be useful if you had an SSD. Could be persistent between sessions maybe?
Client RAM cache - Compressed images stored in RAM on the client.

In practice there is no point in using both client-side caching mechanisms - If you have an SSD you'd cache to disk, otherwise RAM. I'm not sure there is much point in server-side caching unless you have clients with no local caching so I probably won't bother with that. Client-side caching will clearly have to be configurable.

 

[tourettes]

Re: AW: Re: MP2, plugins, and multiple clients.

Server RAM cache - Compressed images stored in RAM to reduce latency.
Client HDD cache - Compressed images (whose original source is the server) stored on local HDD. This would only really be useful if you had an SSD. Could be persistent between sessions maybe?
Client RAM cache - Compressed images stored in RAM on the client.

In practice there is no point in using both client-side caching mechanisms - If you have an SSD you'd cache to disk, otherwise RAM. I'm not sure there is much point in server-side caching unless you have clients with no local caching so I probably won't bother with that. Client-side caching will clearly have to be configurable.

I would say that the is no point ins server side caching (unless you consider the download + save to HDD as a caching ).

About the client side caching I think we need to have some persistent caching mechanism between the sessions (or for example the fan art browsing would be quite slow since the life time of a client run time might allow only once or twice the same fan art to be displayed). It wont hurt if there is for example 5 GB worth of fan art on a client's HDD (or even on SSD), it would be worth the speed improvements what such are giving. This cache doesn't need that much optimization, just store all thumbs / fan art etc. that the client sees.

For the RAM cache there is also a need since it will provide much more seamless / faster fan art change times - since the load from SSD / HDD and image decoding time will take few it's own time (multiple rendering passes at least). This cache should have some optimized caching algorithms to decide what to keep in RAM / GPU memory. It might be quite tricky to find the optimal algorithm (not sure if there is any that would fit all the use cases).

 

[mbuzina]

Re: AW: Re: MP2, plugins, and multiple clients.

Server RAM cache - Compressed images stored in RAM to reduce latency.
Client HDD cache - Compressed images (whose original source is the server) stored on local HDD. This would only really be useful if you had an SSD. Could be persistent between sessions maybe?
Client RAM cache - Compressed images stored in RAM on the client.

In practice there is no point in using both client-side caching mechanisms - If you have an SSD you'd cache to disk, otherwise RAM. I'm not sure there is much point in server-side caching unless you have clients with no local caching so I probably won't bother with that. Client-side caching will clearly have to be configurable.

I would say: combine the caches.
* Server RAM Cache: cache the most frequently used thumbs. Use a fixed size buffer that can be changed in settings or allow a buffer to use a dedicated portion of the available RAM. Test if this gives speed improvements.
* Client HDD: Yes, you would need that. TV Channel Icons / Thumbs, Album thumbs & Picture thumbs could be cached in seperate caches (so that browsing a huge picture library does not throw out the more regularly used Album thumbs or TV Channel). So have a cache for each group and do a LRU algorithm on that. Check Updates in intervals (thumbs do not update often). Fan Art for me would be optional, I don't mind waiting a 1nd for the one image, but I mind waiting 0.01 second per thumb if I am browsing >1000 items (= 10 seconds!).
* Client Memory: Yes, for some this might also help. Probably cache the thumbs of the current "module" / "view" / "window" or "Plugin" (or whatever). You would probably go forward, backward a few times, so caching them in memory speeds up as well.

Also allow the caching to be "invisible". If you have an interface called the "

ThumbsProvider

" (method would be

tp.GetThumb(mediaItem);

or

tp.GetThumbs(mediaItemList);

) you could create a class called

localRAMCacheThumbsProvider

(which takes a normal ThumbsProvider in its constructor) and a class called

localHDDCacheThumbsProvider

(which also has such a constructor), you could call:

tp = new localRAMCacheThumbsProvider(new localHDDCacheThumbsProvider(new fromServerThumbsProvider)));

if you wanted all caches or leave one out.

Just my 2 cents.

 

[Baboonanza]

Re: AW: Re: MP2, plugins, and multiple clients.

About the client side caching I think we need to have some persistent caching mechanism between the sessions (or for example the fan art browsing would be quite slow since the life time of a client run time might allow only once or twice the same fan art to be displayed). It wont hurt if there is for example 5 GB worth of fan art on a client's HDD (or even on SSD), it would be worth the speed improvements what such are giving. This cache doesn't need that much optimization, just store all thumbs / fan art etc. that the client sees.

I don't know. Would there really be a significant difference between loading from disk on the client and loading from disk on the server and then sending to the client? I would say the difference would be very small unless your network is slow or the client has an SSD. In any case I think I will implement disc caching and we can experiment.

For the RAM cache there is also a need since it will provide much more seamless / faster fan art change times - since the load from SSD / HDD and image decoding time will take few it's own time (multiple rendering passes at least). This cache should have some optimized caching algorithms to decide what to keep in RAM / GPU memory. It might be quite tricky to find the optimal algorithm (not sure if there is any that would fit all the use cases).

The problem with fan art caching is 2 fold:
- Prediction of what is required is impossible to do without addition information suppllied by whatever controls the fan art. Even then it's very difficult, you can't load everything and the user could traverse 100s of movie items in a few seconds. What to pre-load? What to lose when the cache is full?
- Large file sizes limit what can be cached (although 20mb will buy you quite a lot of compressed files)
The idea is really aimed at thumbs and graphics used for skins, with the primary goal being to reduce window transition time to the bare minimum. Fanart can be loaded asyncronously if necessary but UI graphics must be syncronous and fast.

GPU memory will also be dynamically managed. In fact due to the vector nature of the SkinEngine (ie less bitmaps) complicated caching methods may not even be necessary since there will be less textures demanding VRAM.

Unitl we have a full-featured skin this is all a bit vague though. I can implement the systems but I can't really tell how aggressive caching should be, or even if it's necessary, until more complicated skins are available.