mine wouldn't update either because I was using my own ftp server, and ftping files wouldn't show up in media library for playlisting.
to fix it, I wrote a script that goes through all accounts and runs the centova reindex command on that user,
works after that

this is something that should be built right in, it wasn't that hard to code.
no reason to force people to use a specific ftp server

you had the reindex scanner program already built, just sitting there not being used. I put it to use

mine wouldn't update either because I was using my own ftp server, and ftping files wouldn't show up in media library for playlisting.

... which is the documented and intended behavior, and is unrelated to the topic of the original thread, which is removal of media via the file manager. 

I've split this into its own thread as you seem to have some interesting ideas here, but in future please start separate threads for unrelated issues.

to fix it, I wrote a script that goes through all accounts and runs the centova reindex command on that user,
works after that

Interesting.

this is something that should be built right in, it wasn't that hard to code.

Built right in to what, though?  I trust that you're not suggesting we should just constantly scan the vhosts directory tree for changes, 24 hours/day, 7 days/week (as that would be a braindead approach that's rife with problems) but if you have found a solution for passively detecting changes to a client's media directory as they're made by arbitrary FTP clients, please do share as that would indeed be a great feature to add.

no reason to force people to use a specific ftp server

There's a very good reason -- it's because I'm unaware of any better way to do it passively (read: without perpetually grinding away at the server's HDD or RAID array, or worse, bogging down the NFS server exporting the vhosts directory).

The only kernel mechanism I'm aware of that would make passive monitoring possible is the inotify interface, but that does not support recursive directory watches, and there is a performance penalty for each inotify watch you add which would (so I've read) become prohibitive if we were to manually watch the entire directory tree recursively.

If you're more informed on this topic than I am, your insight would be valuable... it wouldn't be the first time someone has pointed out an application or interface I was unaware of.

vhosts is correct, the FTPd files that are not handled already have different chown and chmod's
detecting that makes the script do nothing 99.9% of the time, and the reindex command already skips ones that have already been indexed
so mostly the script is just looking up an array of vhost names and then doing nothing
I run it every minute, its miniscule. not even 0.01% cpu

vhosts is correct, the FTPd files that are not handled already have different chown and chmod's
detecting that makes the script do nothing 99.9% of the time

Using permissions or ownerships to identify new files is redundant, as that still requires traversing the entire directory tree.  In fact, using permissions/ownerships to identify files would be *slower* than just traversing the directory tree, as it would require a stat() syscall for each and every file.

The problem is the scanning of the directory tree in itself, and your solution doesn't address that.

I run it every minute, its miniscule. not even 0.01% cpu

That's great that on your system it's negligible.  It won't be for everyone.