El año pasado he publicado acerca de mejorar el rendimiento de Media Browser. En el extremo de que el intento arrojaron resultados decepcionantes. sin embargo, Recientemente he estado experimentando con diversas formas de mejorar el rendimiento como el tamaño de mi biblioteca aumenta.
- The sqlite performance of Media Browser is now noticeably better than when it was first enabled and I was very pleased with the results I got from enabling it with the new 2.2.8 lanzamiento.
- I will be experimenting with the result of moving the sqlite database file onto the RAM Conduzco Ya utilizo para mi WMP database y se actualizará de acuerdo con este post
The above changes have yielded some benefits, but really I was in search of a bit more. Whilst benchmarking a new USB Memoria USB I checked the size of my media browser image cache and noticed that it had grown substantially — to over 600 y, with an average image size of about 600k. Given the typical display size of the images in question this seemed rather a lot and I wondered what else could be done. I remembered seeing a post about reducing the image cache on TheHTPC, which is one of the blog feeds I keep a half-eye on quite regularly and decided to dig the article in question up. I was delighted to see that the author (otro Jon) has tried various of the things I had already done, and had some excellent advice for reducing image size.
- Recompress all the JPEGs (en mi caso a 80%). Esto ahorró más 350meg
- Resize all the movie cover images (I followed the advice to use 600×400). This saved an additional 230meg.
I would like to echo Jon of TheHTPC in endorsing FastStone Image Viewer for the above operations. It was free and easy to use.
- I also decided to limit the number of backdrops per movie to a maximum of 2. This saved an additional (post compression) 60meg. I considered reducing the maximum to just 1, but this would only save an additional 14mb — which I decided isn’t worth it for the moment.
In total I have reduced the number of images by approx 250, y el tamaño total de 640mb.
- I also checked to see if any backdrops were larger than 1920×1080 with the intention of resizing any that were. Sadly (or sensibly) none were. But I was able to identify 4 corrupt (1kb) backdrop files which I also removed.
- I have also switched off “use internet providers” in the Media Browser config (inside media center, not the start menu config utility) altho I don’t expect this to have any effect as I already have complete meta-data that I manage with Medios Cen-ter Maestro
Todavía tengo 189mb de PNG’s and decided to try compressing them further with PNGOUTWin, which I selected based on a comparison of various png compression tools. Despite the original comparison giving PNGOUT rather unfavourable performance in terms of time to complete, I found the windows version, which has been optimised for multicore cpu’s, performed well, completing most images in under 10 segundos, with an average compression to 94%. Extrapolated to all my images this would save just 12mb. Sadly PNGOUTWin isn’t free, and I decided saving 12mb just wasn’t worth paying for.
Overall I have now reduced the average size of a file in my ImageCache folder to just under 220kb — only 37% the original average. Once the entire cache is rebuilt I expect (y la esperanza) this will result in a new cache size of under 250mb, which should offer a very substantial speed boost.
Qué piensas? envíanos un comentario más abajo! Si desea suscribirse por favor utilice el enlace de suscripción en el menú en la parte superior derecha. También puede compartir esto con tus amigos mediante el uso de los enlaces sociales inferiores. Aclamaciones.
Deja una respuesta