I don't get it, why would NZBGet get involved with PostProcess script functions and configuration? The destination directory is defined by NZBGet and PostProcess script variables, what options are missing and where are they missing (NZBGet or the script)? If you don't want PostProcess to extract files, what do you want it to do and when? Wouldn't that be a PostProcess function and shouldn't the script already know when to use that function? I haven't thought of password protected archives (won't touch them myself) but I'd think it'd be easier for PostProcess to deal with those directly, e.g. look for a password file.hugbug wrote:I can imagine following usage for pp-parameters:
Define the output-directory (your request);
Tell the script if unpack files or not;
Specify password for protected rar files.
KaraokeStu wrote:I was wondering if it would be possible to alter the destination for a group of NZBs
The general configuration (common destination directory, etc.) is made via pp-script config. That's OK, pp-parameters are not intended to replace that configuration.dalrun wrote:I don't get it, why would NZBGet get involved with PostProcess script functions and configuration? The destination directory is defined by NZBGet and PostProcess script variables, what options are missing and where are they missing (NZBGet or the script)? If you don't want PostProcess to extract files, what do you want it to do and when? Wouldn't that be a PostProcess function and shouldn't the script already know when to use that function? I haven't thought of password protected archives (won't touch them myself) but I'd think it'd be easier for PostProcess to deal with those directly, e.g. look for a password file.
Yes it does, but *not* for nzbget.KaraokeStu wrote: These are all in the Video/TV category.
The post-process script then outputs them all to /mnt/disk1/share/Video/TV/[nzb file name]
What I want to do is actually have them all moved to /mnt/disk1/share/Video/TV/Dr Who
Does this make more sense?
Wouldn't those be better attached to NzbProcess? Upload form switches and file-name flags are the easiest ways I can think of for giving special treatment to a single nzb. This gives me an excuse to complain about special character replacement by NZBGet. It would be nice if the AppendNzbDir name always matched the nzb-file base-name. The underscore replacement has bothered me before, but now its putting a crimp in file-name flags (need a special character to define the flag portion).hugbug wrote:combobox with specific values like "yes", "no"
Interesting. Is that configurable, e.g. TV/Series/episode.ext or TV/episode.ext or Video/episode.ext?doctorvangogh wrote:/yourpath/tv/<seriesname>/season <x>/<someepisode>.avi|mkv
Rename files using special rules? That's indeed the easiest way, but it's not very friendly and you cannot change the parameters after the file was added to queue. Actually that technique can be allready used without any changes in nzbget or nzbgetweb.dalrun wrote:Wouldn't those be better attached to NzbProcess?
Upload form switches and file-name flags are the easiest ways I can think of for giving special treatment to a single nzb.
It matches already. Only few characters (":*?\"><'\n\r\t), that make troubles on windows are replaced. It's necessary even for servers running on linux, because they can share downloads for windows-computers. That's what most optware-users do.dalrun wrote:This gives me an excuse to complain about special character replacement by NZBGet. It would be nice if the AppendNzbDir name always matched the nzb-file base-name.
Not yet - the tv episode categorization seems to be new in the beta versions of ydrol's unpak.sh script (take a look at the last lines of the AUTO_CATEGORY_FROM_FILENAMES_SERIES function). The lastest published version seems to be from the beginning of october. I had to make two minor modifications to get the feature to run on my regular linux box.dalrun wrote: Interesting. Is that configurable, e.g. TV/Series/episode.ext or TV/episode.ext or Video/episode.ext?
Code: Select all
$series="Series name with all dot and space characters replaced by '+'"
wget -U "" "http://www.google.com/search?q=allintitle%3a+%22$seriesname%22+%22episode+list%22+site%3aimdb.com&btnI=745" # &btnI=745 triggers I'm feeling lucky button
Now egrep (or sed) that with
"<h3>.*Season.*([[:digit:]]{1,2}).*Episode.*([[:digit:]]{1,2}).*<a.*>(\w+)</a>.*</h3> "
and \1,\2,\3 will have your season number, episode number and episode title - just have to lookup the downloaded title now
Adding additional (optional) parameters per collection is a great idea. They could be used by postprocessing scripts to modify certain actions on the target (extract/don't extract/only extract X, categorize to A/B/C).hugbug wrote: But don't you like the idea of more comfortable feature as I descibed in the second post?
No, nzbget will not bother with understanding of pp-parameters. Nzbget/nzbgetweb will only provide a way for users to define parameter values. The values will be passed to pp-script after the download is completed. It's totally up to pp-script how to deal with pp-parameters.doctorvangogh wrote: Adding additional (optional) parameters per collection is a great idea. They could be used by postprocessing scripts to modify certain actions on the target (extract/don't extract/only extract X, categorize to A/B/C).
But trying to solve some categorization properties (possibly automated) from within nzbget (which I understand primarily as a download client), doesn't seem like the right way to do it.
You'd have to implement a ton of logic in nzbget itself, which might not produce a result that everybody likes as implemented. And since there's already the postprocessing script option available, which are easy to reconfigure or even modify, I'd really not go to all that trouble.
Users browsing this forum: No registered users and 49 guests