Lol 
This is what I have to work with
In the past peeps used to say no one will ever watch have that stuff, yet my server is very active this is just the last 30 days lmao
So for me having it snappy and responsive is really important.
Snappy and Responsive is exactly how I’d describe my Plexiverse.
So, you’re right. A Slow Plex would blow.
1 Like
lol
You did see the “video store worker” stuff right? I’m not “old” perhaps but definitely “older”. 
And maybe the storage availability is part of it … background in managing importance of files vs cost of storage (should I really keep those rosencrantz and guildenstern movie wav files on my floppy?) is still ingrained I think too. Only recently I’ve started keeping things because “why not, I have the space”.
@morpheus2n2 The “when will you ever watch it” I can feel. I used to have 800 VHS\DVD movies (worked in video stores for YEARS) and people would be the same way… and then come borrow movies. It was also a “what if I’m in the mood to watch THAT one though?”
So somewhere between both of your folks examples is probably a bit of perspective shift for me as well that I’m going through right now (I’m keeping more and building more back catalog) so I think that’s where knowing what is or isn’t extensive vs average, particularly for Plex, would be handy for me.
Clearly I’m not pushing any limits though!
I’m running a Synology at the moment but Plex is only managing my Movie and TV Shows (my TV Shows are negligible - just a few hundred files). Photos and Music are on the server just as backup\static storage at this point so I’m definitely not pushing anything.
I expect to expand the movies library but it sounds like my idea of “extensive” isn’t nearly as large as other folks.
Thanks for all the input!
Edit - I also went from early local media server guy to streaming only guy and back to local media server guy.
I was already ‘Past my Prime’ when the first Betamax VCR rolled off the assembly line - and was almost immediately replaced by VHS…unfortunately - BetaMax was way better…lol
My first video store job carried Betamax and VHS. 
I “know” storage is cheap but don’t always feel it if that makes sense?
I also know having lots of options to select from can be daunting so I was keeping my library simple as well. With some of the newer Plex options I feel like I can leverage the larger library more so I think that’s why I’m curious what “extensive” means now for considering efficiency. I could see setting up external SSD drive on my server just to host Plex library if it’s that much of an impact.
Edit: Using Roku\iOS mostly to a standard Synology setup and I know I don’t have my movies org’d exactly efficiently I haven’t noticed any lack of snappiness myself yet.
I guess another reason I have a lot of stuff is I don’t pay to watch advertising.
I’ve never paid for Cable.
I’ve always lived in Fringe Broadcast Areas - so the available and watchable choices were always compromised in some way.
Having something you can touch and feel in your paws was a way of life - so a few thousand Movies in storage ain’t nuthin’ but a thing. Seems totally natural to me.
Also the remaining group of contemporaries I share the server with - dwindling, I might add - have children, grandchildren and now great grandchildren, so I probably keep that in mind. I might not watch it, but an Old Granddad, sipping Old Grandad, can hang out with Grandkids layers deep and watch something they might enjoy - and that can’t be a bad thing.
I often see some media being served that isn’t Grandad Safe - Like Dora or something and I’ll send a text:
“Babysitting?”
“Oh yea, Man - it’s great - thx”…
and that makes it all worth it…
1 Like
What I like to do, once a month, is clean of the plex DB
docker stop plex
cp com.plexapp.plugins.library.db com.plexapp.plugins.library.db.original
com.plexapp.plugins.library.db "DROP index 'index_title_sort_naturalsort'"
com.plexapp.plugins.library.db "DELETE from schema_migrations where version='20180501000000'"
com.plexapp.plugins.library.db "DELETE FROM statistics_bandwidth;"
com.plexapp.plugins.library.db "DELETE FROM statistics_media;"
com.plexapp.plugins.library.db "DELETE FROM statistics_resources;"
com.plexapp.plugins.library.db "DELETE FROM accounts;"
com.plexapp.plugins.library.db "DELETE FROM devices;"
com.plexapp.plugins.library.db .dump > dump.sql
rm com.plexapp.plugins.library.db
"pragma page_size=32768; vacuum;"
"pragma default_cache_size = 20000000; vacuum;"
com.plexapp.plugins.library.db < dump.sql
com.plexapp.plugins.library.db "vacuum"
com.plexapp.plugins.library.db "pragma optimize"
com.plexapp.plugins.library.db "UPDATE metadata_items SET added_at = originally_available_at WHERE added_at <> originally_available_at AND originally_available_at IS NOT NULL;"
com.plexapp.plugins.library.db "UPDATE metadata_items SET added_at = DATETIME('now', '-1 days') WHERE DATETIME(added_at) > DATETIME('now');"
com.plexapp.plugins.library.db "UPDATE metadata_items SET added_at = DATETIME('now', '-1 days') WHERE DATETIME(originally_available_at) > DATETIME('now');"
docker start plex
more often if I see a bunch of slow query messages in the Plex log
1 Like
You might want to leave these 2 lines out if your server version is above 1.23.2
You don’t need to adapt them to the newer server version at all if you use the now integrated SQLite https://support.plex.tv/articles/repair-a-corrupted-database/
Eventually I may move to one of those versions.
If they ever work correctly
Not saying the 1.22.x versions are perfect, but anything above that crashes at least once a day
1 Like
I don’t see the SQLite binary itself mentioned. How is it executed during this process? These pragmas apply to the current session/file, and may not be applied to subsequent or sequential executions.
I’m unsure that the deprecated default_cache_size helps Plex. The cache_size that Plex uses appears to be hardcoded in the Plex app.
I don’t believe vacuum is necessary immediately after a .dump and load. The load already produces a fully compacted database.
That’s not beneficial in this context. PRAGMA optimize can be useful for applications after they’ve been doing normal activity for a while. In this context it won’t have seen any normal queries.
But ANALYZE could be performed. That would regenerate statistics for all indexes. (Neither .dump nor VACUUM do that.)
Just mentioning this for others - not everybody will want to overwrite the added_at values in this way.
I don’t see the SQLite binary itself mentioned.
removed for ease of reading the commands
I don’t believe
vacuumis necessary immediately after a.dumpand load. The load already produces a fully compacted database.
Done lots of tests with and without vacuum, while plex does a vacuum on start up, doing one before starting plex back up speeds up the process considerably. But again, this is what I do and you’re welcome to ignore it
That’s not beneficial in this context.
PRAGMA optimizecan be useful for applications after they’ve been doing normal activity for a while. In this context it won’t have seen any normal queries.
again, from testing across multiple plex containers and with multiple friends testing as well - We’ve seen benefits to running it
Can you quantify that? It may be placebo. When performed after .dump and .read, SQLite "PRAGMA optimize;" doesn’t make any changes to the .db file.
The commands as written won’t be effective at changing page_size.
Each time SQLite is called, it’s a new database connection/session.
For PRAGMA page_size=32768 to be effective, it must be set in the same session as when the database is created. It won’t be effective as written because each command is an independent session.
It’s awkward to do in a single CLI statement. The page_size of a database can also be modified by performing VACUUM in the same session.
This should be effective:
# Create the database by reading the dump:
SQLite com.plexapp.plugins.library.db ".read dump.sql"
# Display the current page_size of the restored DB:
SQLite com.plexapp.plugins.library.db "PRAGMA page_size;"
# Set the desired page_size, disable WAL mode, VACUUM:
SQLite com.plexapp.plugins.library.db "PRAGMA page_size=32768; PRAGMA journal_mode=DELETE; VACUUM;"
# Display the now-changed page_size:
SQLite com.plexapp.plugins.library.db "PRAGMA page_size;"
1 Like
(probably doesn’t count his porn room either) 
2 Likes
I only skimmed the thread, so apologies if this is a repeat;
to make plex data use less space, disable video preview thumb generation.
on large libraries, that causes explosions of plex data size.
otherwise the biggest performance improvement = dedicated to plex only SSD/NVME as already commented several times
2 Likes
Yeah, it’s pretty phenomenal how big they are. I love that feature though.
There are other things you can do to reduce how much space they use.
They don’t slow down Plex during normal use - once they’ve generated, disabling them doesn’t make Plex run any faster.
2 Likes
do you know which folder I can do to to delete the previously created thumbnails?
Edit each Library/Advanced…
Should be a big red button there that’ll do the job:
(RED: NOOOOO!!!..lol)
1 Like
Ah, i just read your link you posted earlier…doing that now. thx
Ooo… bookmarked. Thanks! Switching to 5 second instead of 2 second now.
The 10 second minimal on Roku explains some of the oddities with thumbnail scans not lining up with positions so thank you for clearing that up - such a useful post!
It would be nice if I could adjust this per library. Every 5 for TV shows and every 10 for movies would be perfect for me. Every 2 seconds seems like a lot in general but time scale in multimedia is funny and being able to scrub to very specific points with nice flow in those thumbnails is definitely a QoL benefit.
