[Nimboid]

I'm trying to segregate incoming links based on a link Property: 'Date' provided by the plugin, so that links before a given date are directed to a different package than those on or after the date, which continue to the default package for the job.

callAPI("linkgrabberv2", "addLinks"

doesn't work for me unless its destination package exists; it doesn't error, just ignores. I can create a new package with

callAPI("linkgrabberv2", "movetoNewPackage"

for the initial link.

Question is, how to efficiently check whether package:<packageName> exists within the link grabber table, so that I call the "movetoNewPackage" version only once? Or is it possible to write a flag to an environment variable perhaps? I can see a getEnv(myString), but no equivalent setEnv().

[mgpai]

Use 'packagizer hook' trigger.

if (state == "BEFORE") {
    compare link date property

    if (link date property is before date) {
        check if "old package" exists in "allCrawledPackages()"
        
        if ("old package" exists) {
            set package name "old package";
        )
    }
)

[mgpai]

Originally Posted by Nimboid

... how to efficiently check whether package:<packageName> exists within the link grabber table

function packageExists(str) {
    return getAllCrawledPackages().some(function(package) {
        return package.name == str;
    })
}

//usage
alert(packageExists("before date"));

[Jiaz]

Originally Posted by Nimboid

callAPI("linkgrabberv2", "addLinks"

Should work just fine as the package will be auto created if not existing. Can you please provide a working example? or show the full addLinks method call? Most likely some error in using it.

Originally Posted by Nimboid

Question is, how to efficiently check whether package:<packageName> exists within the link grabber table, so that I call the "movetoNewPackage" version only once? Or is it possible to write a flag to an environment variable perhaps? I can see a getEnv(myString), but no equivalent setEnv().

Instead of packageName you should use packageID as that lookup/use will be fast and will ensure that the correct package will be used. names may not be unique
And getEnv is for System Environment variables. You want to use

getProperty and setProperty with global=true

[Nimboid]

Here's a minimal script:

//Trigger: A new link has been added

log('Trigger: A new link has been added');
log('getName(): ' + link.getName());

var myCrawledLink = crawledLink;
var linkURL;
linkURL = myCrawledLink.getContentURL();

try {
    // Next only works if the package already exists!
    // Otherwise, package with name supplied in 'Analyse and Add Links' dialog is created.

    callAPI("linkgrabberv2", "addLinks", {
        "links": linkURL,
        "overwritePackagizerRules": true,
        "packageName": "Date - before"
    });

} catch (err) {
    log("API call failed");
    log("Error: " + err + "");
}

I now suspect that the package is|has already been created with the externally-supplied package name when this is called, then the 'addLinks' call creates a new link on the queue, which gets discarded as a duplicate. I notice the crawler icons in the status bar increase in number. If I'm quick enough to delete the initial package from the link table, links still in progress do get re-added to a package with the script-supplied name.

However, if I manually rename the generated package to the script-supplied one, and delete some of its contents, then re-submit the same test links via the 'Analyse and Add Links' dialog, all the non-duplicates are deposited in the renamed package, the behaviour described in the previous paragraph does not occur.

I've tried the above with a Packagizer Hook trigger, as suggested earlier in the thread, link crawl jobs appear to get created recursively, and I have to restart to regain control.

The test links used were direct links to jpeg images.

[Nimboid]

Originally Posted by Jiaz

And getEnv is for System Environment variables. You want to use

What is the scope and lifetime of a Property set with global=false, please?

[mgpai]

Originally Posted by Nimboid

I've tried the above with a Packagizer Hook trigger, as suggested earlier in the thread, link crawl jobs appear to get created recursively, and I have to restart to regain control.

You don't need to use 'addLinks' or 'moveToNewPackage' with the 'packagizer hook' script. The script is executed before the links are processed by the packagizer and will set the package name only if you condition is matched, else it will use the default package name (if it is set by the plugin) or the one generated by the packagizer.

[Nimboid]

I'm still working on this! Is there a way to determine from a script, whether the "Information overwrites packagizer rule" checkbox on the "Analyse and Add Links" dialog was set or unset?

[mgpai]

Originally Posted by Nimboid

I'm still working on this! Is there a way to determine from a script, whether the "Information overwrites packagizer rule" checkbox on the "Analyse and Add Links" dialog was set or unset?

function isAddLinksDialogOverwritesPackagizerRulesEnabled() {
    var interfaceName = "org.jdownloader.gui.views.linkgrabber.addlinksdialog.LinkgrabberSettings";
    var key = "AddLinksDialogOverwritesPackagizerRulesEnabled";

    return callAPI("config", "get", interfaceName, null, key);
}

[Jiaz]

Originally Posted by Nimboid

What is the scope and lifetime of a Property set with global=false, please?

global = true -> all script can *see* the property value with key X
global = false -> only the script itself can *see* the property value with X

[Jiaz]

Originally Posted by Nimboid

I'm still working on this! Is there a way to determine from a script, whether the "Information overwrites packagizer rule" checkbox on the "Analyse and Add Links" dialog was set or unset?

With next core update, you can check this via

isOverwritesPackagizerRulesEnabled

method on the CrawlerJobSandbox