Reduce storage size of 'thumbs' folder (MovPic + TVSeries) (3 Viewers)

[RoChess]

Re: Reduce storage size of MovingPictures 'thumbs' folder -- v2

TMDb expects backdrops to be only 1920 x 1080 or 1280 x 720, trouble is other sizes are uploaded by the contributors. Version 2 of TMDb should be running soon and will have a filter on the upload entry to prevent this, or so I have heard

This script was never meant as a permanent solution, and themoviedb.org isn't the only movie source for MovingPictures, so building in the auto-resize functionality into the plugin isn't going to be a waste of time.

I'm most likely going to keep my script running on my own setup (I got it setup via Task Scheduler), but in a modified version that scans for filesizes. I've noticed some 1920x1080 backgrounds of 1MB in JPEG image format, because they were saved in lossless or almost lossless format. My eyes aren't good enough to notice the difference when I recompress those to 250kB size via lower JPEG quality and some other tweaks.

Same with the covers, no thumbnail image (175x261) needs to be more then 20kB on my setup, and the large versions can be maxed to 200kB as well.

I'll probably also include MP-TVSeries, because I just checked and 213 fanart images are more then 250kB+ in there as well.

 

[lanceuppercu]

Re: Reduce storage size of MovingPictures 'thumbs' folder -- v2

I'll probably also include MP-TVSeries, because I just checked and 213 fanart images are more then 250kB+ in there as well.

woo!

 

[RoChess]

Re: Reduce storage size of MovingPictures 'thumbs' folder -- v2

woo!

All done.

Touched the script I was running myself up a little to make it easier for others to use.

You can even add it to the task scheduler if needed, but a once a week manual run should be more then enough for most users.

 

[lanceuppercu]

i'll give it a stab when i get home

edit: seems a lot better, i like how it skips the files it doesnt need to do without trying to reprocess them.

 

[mortstar]

Doesn't the database need updating as file extensions are being changed?

 

[RoChess]

Doesn't the database need updating as file extensions are being changed?

No file extension is changed for that reason, only the image format inside of the file. Windows and per extension MediaPortal doesn't mind, as it doesn't check if extension matches content.

So my script doesn't fix the MediaPortal skin cache crash, unless MediaPortal skips the PNG files when it detects the JPEG image format, so after v1.0 stable is released, you will have to delete all your PNG images, so that the plugin can obtain a new image with JPG extension and update the database. But at least that way you are still in control as to how many images are downloaded, incase you have a bandwidth cap to deal with.

 

[fforde]

Doesn't the database need updating as file extensions are being changed?

For what it's worth, if the file extension WAS changed Moving Pictures would pick it back up without having to redownload. You may lose the "currently selected cover" and have to cycle to it again, but other than that a changed extension should be fine.

 

[mortstar]

Obviously I love MovingPictures, but I think saving files as .png is/was a *really bad idea*.

I know it was posted earlier that this is not a performance issue but I disagree whole-heartedly. I used MovPics only once whilst I had .png media and I could instantly detect stuttering and the hard-drive grinding trying to keep up with the data pull. (If you check my system spec, you will see it is now a low-powered HTPC).

I got around this issue by re-instating a backup of the MovPics image cache from a backup of mine and running an SQL replace command to swap .png for .jpg in the image location columns. Any new imports I manually intervene by resizing to 1280x720 and saving as jpg. The minute visual improvement in a HTPC GUI that full-fat PNGs provide over say a 90-95% quality JPEGs is not a decent pay off for the performance hit and the waste of disk space.

EDIT: I don't even think themoviedb.com hosts these images as PNGs, so the conversion is superfluous anyway. Like converting a 128kbps mp3 to FLAC - it isn't going to improve the quality.

 

[RoChess]

Obviously I love MovingPictures, but I think saving files as .png is/was a *really bad idea*.

It was originally done to fix the corrupted images, because the error handling for the PNG image format allowed for better detection when things went wrong. Now that the corrupted image problem has been corrected another way, the PNG Image format method was no longer needed.

And v0.7.5 was also saving with PNG image format, it just was using JPG extensions.

And PNG image format has a lot of benefits over JPEG, especially when you have text inside the image. The JPEG image format generates a lot of artifacts then, which you can find ample examples on if you search on the subject. But that relates more to the cover thumbnails which undergo a resize. The backdrops and covers are already obtained in JPEG format, so a direct save-to-disk would be best solution, and that is what I believe is done now via: r1018 - moving-pictures - Project Hosting on Google Code

But you would need to compile SVN yourself to get that functionality now, or be patient till developers think it is time for beta3/RC1 to be released.

 

[bug1802]

Ran this on my media box and now browsing my movies list is very much noticeably FASTER... Instead of it trying to load a massive 6mb file it only loads something very smaller and very quickly.

This has saved me a heap of room as well considering i have over 700 movies and TV Shows, so at least a couple gig, wish i had found this earlier.

Thanks, and hopefully next versions of Moving pictures will not use such over sized and not needed files or attempt to render them smaller.