[TGU]

I would like to fetch some of the Dynamic variables (https://support.jdownloader.org/en/k...the-packagizer) via the API some of the information is not available when using the queryLink & queryPackage endpoints, for example the "<jd:orgpackagename>" or "<jd:prop:PROPERTYID>"

It appears to be possibly available? via the "/ui/invokeAction" or using the UI under the mod manager "(Submenu) More Actions..." > "Copy Information", however this would? copy it to the clipboard which isn't ideal.

Thanks.
//TGU

[Jiaz]

@TGU: No such api does exist and the "/ui/invokeAction" sounds like ai/chatgpt dreaming
<jd:orgpackagename> is only available during linkcrawling/packagizer as only then the information is available. after the link has *landed* in linkcollector, all those temp. information are no longer available
what exactly do you have in mind/want to achieve?

[TGU]

The API endpoint should be located right here https://my.jdownloader.org/developers/#tag_337

I wasn't aware of the limitations on the <jd:orgpackagename>, I was hoping to somehow use the Copy Information (right click context action) to receive more data than what was available within the API endpoints for querying. For example the {jd:prop:yourWishedProperty}

note: {} and <> should be replaced depending on what context they are actually used in.


There are properties within the Copy Information that aren't available when using the queryLink & queryPackage API which would be nice to somehow be available, for example the queryLink only gives you the {url.content} BUT I would like to also see the {url.container} available as this will more or less give me the original file URL used, or tell me if that the URL has multiple files.

The newly discovered (to me) "<jd:subfolderbyplugin>" I was hoping to fetch this on the package itself to find if this data was available to figure out if the filepath has been modified when using the Packagizer adopt folder structure, or have the ability to do it myself without the Packagizer while the link is still within the LinkGrabber. Same with the <jd:orgpackagename>.

In my case every link that passes through the MyJD API has their package names will have additional data referencing the source prepended "sitename_id_subid_"+packagename after the link has been added, and the package save paths will be modified with similar data. Allowing access to the get the contents of "<jd:subfolderbyplugin>" and other variables would help in this case.

I can somewhat extract the <jd:subfolderbyplugin> by trimming the saveTo prefix with my default save directory ("F:\jdownloader" or "F:\jdownloader\<jd:packagename>"), and checking if anything is remaining.


For the copy information I set the Pattern for Links to: ["link":{"type":"{type}","path":"{path}","comment":"{comment}","filesize":"{filesize}","filesize_kib" :"{filesize_kib}","filesize_mib":"{filesize_mib}","filesize_gib":"{filesize_gib}","name":"{name}","p ackagename":"{packagename}","host":"{host}","name_noext":"{name_noext}","ext":"{ext}","hash":"{hash} ","url":"{url}","url_container":"{url.container}","url_content":"{url.content}","url_origin":"{url.o rigin}","url_referrer":"{url.referrer}","archive_password":"{archive.password}"}]

["package":{"type":"Package","path":"F:\jdownloader\akari3","comment":"","filesize":"136306099 B","filesize_kib":"133111.42 KiB","filesize_mib":"129.99 MiB","filesize_gib":"129.99 MiB","filesize_raw":"136306099","name":"akari3","packagename":"akari3"}]
["link":{"type":"Link","path":"F:\jdownloader\akari3","comment":"","filesize":"136306099 B","filesize_kib":"133111.42 KiB","filesize_mib":"129.99 MiB","filesize_gib":"129.99 MiB","name":"akari3.mp4","packagename":"akari3","host":"mega.co.nz","name_noext":"akari3","ext":"MP4 ","hash":"","url":"","url_container":"","url_content":"**External links are only visible to Support Staff**,"url_origin":"","url_referrer":"","archive_p assword":""}]


Update:
I suppose the best way to handle this might be for a new api endpoint for packages and links which take an input for "{jd:prop} <jd:packagename>" and it would simply return the result as json for each variable given as the key.
"/linkgrabberv2/getLinkProperty", "/linkgrabberv2/getPackageProperty", "/downloadsV2/getLinkProperty", "/downloadsV2/getPackageProperty" Also to keep the "temp. information" available while the link/package is still within the LinkGrabber.

This would greatly expand the ability of interacting with JD dynamically outside of the EventScripter, especially for people like me who script outside the EventScripter (using the RemoteAPI).

[Jiaz]

Originally Posted by TGU

The API endpoint should be located right here https://my.jdownloader.org/developers/#tag_337

Sorry, totally forgot about this one...old man's memory

I have not read rest of post yet and will read/answer by tomorrow but are you planing to use the api locally, in context of the eventscripter, or remotely via network? asking because some information can be access via eventscripter that is not possible (yet) via api.

[TGU]

No problem, I understand as I only recently implemented most of the full ~210 endpoints API interface in a Golang Client, I exclusively utilize the "RemoteAPI".

I use the "https://api.jdownloader.org" API with /my/connect, /my/disconnect, /my/reconnect, /my/listdevices, /device/getDirectConnectionInfos, then all device requests will use the given getDirectConnectionInfos IP/Ports ("http: 127.0.0.1:123/t_456_789/linkgrabberv2/queryPackages").

I suppose this feature could more easily implemented within direct connection device itself, and then at a future time allow it to be called from "https://api.jdownloader.org"

[Jiaz]

Can you explain what information in special you are really needing? for example filesize is the *raw* value while others like filesize_mib/filesize_gib..are simple to String conversions.

You would help me a lot if you can list all properties/information you would like to be able to get hands on and then I can think of best approach, for example adding new getLinkProperty/getPackageProperty or, my preference, update query methods so you can specify additional properties/information you would like to query and then will be part of response. much better/faster than doing this on per link/package getXYProperty call.
with list of wanted information, I can check those and also check the availability scope of those.

[Jiaz]

Originally Posted by TGU

No problem, I understand as I only recently implemented most of the full ~210 endpoints API interface in a Golang Client, I exclusively utilize the "RemoteAPI".

That's nice to read. something you will make public available? or just private playground/stuff?

[TGU]

Originally Posted by Jiaz

That's nice to read. something you will make public available? or just private playground/stuff?

Soon™ I hope to rebuild some of the little messy stuff with the URL builder + server vs device, it's 95% there and once that's ready I'll let you know. I still have to do a lot of the various error handling and acting upon JD dynamically based on events, but that's really just going to take time and understanding of what to expect.

I've spend more than enough hours to get this all working and implemented it would be a shame not to share it. It has been on my todo list since where the first initial code getting the sever and device connections at least working.

The worse part has been the encoding of parameters within the post body, and just getting the BAD_PARAMETERS error sadly most of that was due to documentation and really understanding what it's expecting. However enabling logging within the https://my.jdownloader.org really helped. (by any chance is there an non-minified jdapi.js available anywhere?)

[TGU]

Originally Posted by Jiaz

Can you explain what information in special you are really needing? for example filesize is the *raw* value while others like filesize_mib/filesize_gib..are simple to String conversions

Honestly the short version of what I "need" is to be able to access the same information as the Event Scripter & Packagizer without using it (I "event script" on the golang aka API client side). I don't have a full understanding at what's available and what's not; However over the years I have understood that there are simply data that's accessible within the Event Scripter & Packagizer which is unavailable within the Remote API.

here is some of the properties I know about which is accessible at one point or another [<jd:orgpackagename>, <jd:subfolderbyplugin>, {url.container}, {url.origin}, {url.referrer}, {jd:prop:yourWishedProperty}] and jobId that I would like to reference. (url.origin is already available via the queryLinks url property}

edit: looks like /getDownloadUrls will actually give you the url.* properties, however the case still stands for adding these into the new query parameter as "much better/faster than doing this on per link/package"

The little stuff like {filesize_} in which you can calculate yourself based upon other data available aren't required.

I think you are correct with updating the query methods with additional optional fields would be a good option as any developer who implements them within the request understands the additional fields within the response JSON without really having to change the version number.
Example:
Req: CrawledLinkQuerySortableV2{"startAt": 0, "maxResults":-1, "packageUUIDs":[1234], "jobUUIDs":[123456789], "url":true, "props": ["jobId", "url.content", "url.container", "jd:prop:yourWishedProperty", "jd:prop:non-existant-property"]}
------
Resp: CrawledLinkSortablesV2[{"packageUUID": 1234, "name":"package name", "url":"**External links are only visible to Support Staff** "props":{"jobId":123456789, "url.content": "**External links are only visible to Support Staff**,"url.container": "**External links are only visible to Support Staff**, "jd:prop:yourWishedProperty":"wished property value"}}]





While this could be in a different discussion it somewhat relates to the Event Scripter and "replacing" it on the client side:

I use the API "/events/listen" to listen to JD events (and keep the 5 min SessionToken alive, as /my/reconnect doesn't work), the ones that I know of are ["^captchas", "^linkcrawler", "^extraction", "^dialogs", "^downloadwatchdog", "^linkcollector", "REFRESH_CONTENT"] however even with this I'm unable to get a full picture of what's happening, and still in the process of writing code to fully handle the response.

Take for example moving a package from linkgrabber to downloads
[{"eventid":"CONTENT_REMOVED","publisher":"linkcollector"},{"eventid":"STRUCTURE_REFRESH","publisher" :"linkcollector"}]

I'm assuming that the Event Scripter has access to the actual package/link within the script, where as I listening to the events are left with "hey something changed, just query all the packages/links and try to find it"

I know that the eventdata within the same response is sometimes populated, however the structure is different depending on the publisher and eventid; I have not dug into the JAVA code (yet) to have an understanding of what publisher -> eventid -> eventdata data/structure.

Thanks for coming to my TED talk.
I suppose this thread should now be moved to the Suggestions & Requests.