MP2, plugins, and multiple clients. (1 Viewer)

[tourettes]

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

* 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.

I would leave up the server side caching to the file system cache itself. Double caching such would only lower the performance since the available RAM for caching would be reduced.

* 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.

Client memory will always be many times faster than the SSD.

Also allow the caching to be "invisible".

I guess you mean to cache the "nearest" items as well, beyond the current visibility range? Yes, it definitely needs to be done since other wise page up/ down etc. transitions look really bad when the screen is first shown only with some default icons (or place holders - yuck).

 

[tourettes]

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

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.

There is most likely going to be a performance difference. Also we dont want to saturate the network with something dummy as 2nd client fetching fan art while 1st client is playing a blu-ray image over network (bandwidth is already an issue here in many networks).

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.

I would say that the skins itself (or their textures) aren't going to be the issue, but the DVD / bluray covers and fan art. We can easialy fill the GPU ram with few large textures 1920x1080 Of course that wont apply to the current skin...

 

[craige1]

Yes I meant images downloaded from the internet, E.G, fanart/banners/posters/ and other image types. The local caching of images sounds like an excellent idea.

With the information on other clients, I was thinking of HDD disk space on other machines, and to work out which machine is best to do CPU intensive tasks.

 

[mbuzina]

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

* 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.

I would leave up the server side caching to the file system cache itself. Double caching such would only lower the performance since the available RAM for caching would be reduced.

Could be the case. Thats why I recommended testing here. One thing that may help (but only implement that if really really needed) is to create larger bitmaps containing multiple images to reduce the amount of small files sent of the NW (there is a term for that, ehhhmm... ah: packedgfx is what you guys use I guess).

* 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.

Client memory will always be many times faster than the SSD.

Sure, but SSD / HDD will be permanent and still be there when a new session is started and could hold more data.

Also allow the caching to be "invisible".

I guess you mean to cache the "nearest" items as well, beyond the current visibility range? Yes, it definitely needs to be done since other wise page up/ down etc. transitions look really bad when the screen is first shown only with some default icons (or place holders - yuck).

Yes that is what we should do, but no, that was not what I meant ;-)

What you describe is similar to the pre-fetch algorithms in windows. It caches the data you probably need in the near future. A pre-fetch might really be easily implemented, as you would generally start getting thumbs with the ones visible and then get the ones further away from the current view-point, probably preferring forward direction over backward.

What I meant is making the caching mechanism transparent to the code. Similar as stream handlers can be stacked, one stream delivering to the next stream. This way you can start developing without caching and then insert a caching algorithm when needed. So neither the code fetching the thumbs from the server, nor the code using the thumbs should be dependant on any caching functionality and the interface between them should be fixed. You can then insert the cache if it consumes the same interface that it produces (as in my sample pseudo-code).

Regards
Marc

 

[JoeSmith]

AW: MP2, plugins, and multiple clients.

I don't think images should only stay on the server and be send to the clients dynamically. Today HDDs have become so big that for most (not all) users the additional 1-5 gigs are not really relevant. I don't know a lot of people that run HDDs with less than 40gigs and Windows 7 (I'd say that most people i know have at minium 250gb on there win 7 machines). I know that there are some who use very small ssds, but how many are that compared to the "masses". For me thats the price to pay when you want nice fanart and fast loading. Once movies (i'll take that example now) are added to the server fanart, posters, metadata,... will be stored on the server and if a client connects to the server both will sync the needed data.
The same goes with client side caching. Most people have a lot of ram these days, so it would be really nice if mp would use that free ram, maybe adjustable in setup. If my machine has 2 or 4gb ram and is just used as a client, why not take a gig or even more for caching. As long as it extends the experience i'm fine with it - but it needs to be configurable or a lot of people will start whining ;-)
Everybody needs to consider that mp2 will most likey "need" win 7 and take another year minimum.

The only place where i really think that images should stay on the server are mobile devices. The question is whether mp2 will be designed to "talk" to later added mobile device plugins from the beginning.

To much talk on my side - i'm shure the devs know what they are doing - i'm always impressed when they talk about the infrastruce of mp2, really seems well thought.

 

[zicoz]

One thing I got to think of when setting up MP 1.1.0 in my network is that the best solution for stability and to avoid degeneration of the client over time would be to have a "locked down image" that loads each time you boot up, the only problem with this would be that it would have to import all the data dating back to the creating of the image each time it boots up, but if this data was stored on the server and pushed/pulled to the client this would not be a problem. Will such a setup be possible in MP2? Imo this would open MP up to a much larger market with set-top-boxes.

edit:

Come to think of it another solution would be to make it possible to store the databases on another partition.