Following up on this, but I fear the answer is no, since it doesn't work for me and the last comment by someone who appears to be a dev was almost two years ago!!!
Turbo scan doesn't quite meet my (admittedly specialized/advanced) need. Being able to pass a file name so as to add just the one file to my library, rather than having to scan the whole section each time (7.2TB across several drives) would be the perfect solution.
Thank you.
Turbo scan doesn't quite meet my (admittedly specialized/advanced) need. Being able to pass a file name so as to add just the one file to my library, rather than having to scan the whole section each time (7.2TB across several drives) would be the perfect
If your need is rather specialized, consider writing a new (possibly virtual) scanner.
There's no way to add just one file to the library, it's not a very common use case.
First off, elan, thank you for your response, I appreciate it!
If your need is rather specialized, consider writing a new (possibly virtual) scanner.
There's no way to add just one file to the library, it's not a very common use case.
I guess the "issue" I have here is that, on " 05:02, 22 June 2011," "Boots2x" updated the CLI documentation (aka Terminal Commands) to show that this is a supported feature *and* doing a --help when running the PMS says similar!
The documentation from http://wiki.plexapp.com/index.php/PlexNine_AdvancedInfo#Terminal_Commands:
Items to which actions apply:
-c, --section A library section ID.
-o, --item An item ID.
-f, --file A file.
The help output with the latest version of the PMS, v0.9.7.17-1f0b170:
Items to which actions apply:-c, --section A library section ID.-o, --item An item ID.-d, --directory A directory path.-f, --file A file.
So, that's why this is a "why doesn't this work" thread, rather than a "feature request" thread. It seems that, at some point, this was in the roadmap for the application but was delayed. IMO, to eliminate confusion, if it has truly been deprecated as a feature (boo!), the referenced documentation and help output should be updated accordingly.
Thanks for a good discussion, though!
Peter
P.S. This thread has more of the backstory - http://forums.plexapp.com/index.php/topic/63568-one-file-multiple-locations-multiple-libraries/#entry372187 In that thread I've determined that there's at least one other individual with a massive library...
P.S. This thread has more of the backstory - http://forums.plexapp.com/index.php/topic/63568-one-file-multiple-locations-multiple-libraries/#entry372187 In that thread I've determined that there's at least one other individual with a massive library...
The value in scanning a file or a directory rather than an entire section really comes to light when indexing. I'm indexing via the command line to nice the process. I'd like to index a couple hundred files during the wee hours of the morning (at a time)...
i can confirm that the --directory flag isnt working for me either (and --file as well), so i guess it bugged, or maybe just not yet implemented.
however, when it does get working, you should be aware that you will most likely need to specify the library section ID ( -c flag) in addition to the directory/file. i believe correct usage will be like this (where 4 is the ID # of my tv section) :
$ ~/Library/Application\ Support/Plex/Plex\ Media\ Server.app/Contents/MacOS/Plex\ Media\ Scanner -s -r -c 4 -d "/Volumes/Drobo/TV/NCIS"
EDIT: the powers that be inform me that yes, the --file and --directory flags are not yet implemented.
Turbo Scan isn't as fast as if the --file and --directory flags would work. Please reconsider implementing them
I am willing to put some time into a scanner for this, but I think I need a point in the right direction.
I've been skimming through the source files in Scanners.bundle and they all seem to have a Scan(path, files, mediaList, subdirs, root) function. I am guessing that Plex Media Scanner is taking the --section option, looking at the configured paths and generating the a list of files and directories, determining which Scanner is configured for the section, and then calling Scan() on the appropriate Scanner.
If I were to make something that scanned a single file, it would have to be implemented in Plex Media Scanner, would it not? For instance, if I had a file with the path:
/mymoviesection/mymovie.mp4
I would want to use the path to determine which section(s) are affected (optionally we could demand that --section be specified along with --file). Then I would want to figure out the correct Scanner, as I'm sure Plex Media Scanner already does. Then I would call Scanner.Scan("/mymoviesection", ["/mymoviesection/mymovie.mp4"], mediaList, []). Scanner.Scan() looks perfectly well prepared to process a single file already.
How is it that you think a custom scanner could help, elan?
Is Plex Media Scanner closed source? I'd be happy to work on it if I could find the source.
I'd also be interested to see how your watchpath/inotify/whateverwindowshas stuff works, when we choose to keep the library up to date automatically. Do you just watch the paths registered to each section and then do a full section scan when one of them registers a change event? Or do you do something more efficient?
I am relatively new to plex and just getting my collection ripped with Handbrake to Roku friendly, trancode free formats and I realized I got no preview thumbnails while scrubbing. Searching found this had been implemented recently and I just had to index.
I did the first folder one-at-a-time using the the web UI and "Analyze" selection but I have ~275 movies ripped so was looking to do this easier and with more feedback than using the web UI but found and confirmed here that the --file option is not supported.
You can index by sections - use the "--list" options to get the section numbers
then use "-p -b -c "
That is what I did on the next section to be indexed.
Then I started on the primary movie folder/section.
My server re-booted last night about 3am after kicking off indexing for my primary section and I found only 14 movies had been indexed. I was afraid I would have to re-do all that work but the Scanner found the completed index (.bif) files and skipped the ones it had already done.
So, it seems you can kickoff an index scan overnight and just kill it if you need to get some work done on the CPU and then just re-run the scan of the section and it picks up where it left off.
Just thought I would share this info so others are aware of the behavior and that it's not so bad not having the --file option (in this case).
Any update on this?
The reason why I need this:
My storage is on NFS, my Plex Media Server is on a VM. I automatically download new content based of RSS feeds when it's available. Since the storage is remote, plex can't detect a change to the fs, so it can't rescan based on that. I have to schedule rescans (which takes about 2-3 hours to complete for all my libraries) which means I always have to wait for content to be available in plex, or manually refresh.. which most often leads to booting up my old xbmc player instead.
All of my friends share this issue with plex.
The option seems to still not work in 0.9.11.1
It is working for me, I had help in the ninja-forum from another member.
It still takes 20-40 seconds to run, but I can live with that. Also, when I run it against say a single episode directory, it also refreshes about 6-7 other episodes from a bunch of other shows. They are the same ones each time I run it, and it makes me think there is something wrong with those specific episodes. I'm going to have a look at those individually and see if I can determine why they are acting up. My guess is, they do the same after each full scan aswell, refreshing metada on each run. See below for syntax on windows. I run it on ubuntu, and its the same apart from the .exe extension.
"Plex Media Scanner.exe" --scan --refresh --section ## --directory "full path to folder"
Is there any update to this? I would love to get the --file working but am getting “Error: Cannot select a file and something else.”
Thanks,
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
