[Magi]

I used nopecha.com, but it's not free. They periodically provide 200 points per api key, which won't last long, given that it doesn't recognise all captchas at once. So I wanted to get captchas from my.jdownloader.com and pass them to one or more scripts that can try to recognise them offline and for free.

As for the 9kw.eu service, I don't have time to solve my captchas, let alone help others.

[pspzockerscene]

Okay, understood.

Please wait for another JD developer to answer your initial question.

[Mister Floppy]

Hi,

seit kurzem werden beim "MyJDownloader" v0.9.81 1635350024931 (getestet unter Android 9 und 11 auf verschiedenen POCO F!-Smartphones von Xiaomi mit MIUI-Bedienungsoberfläche) keine Captchas mehr angezeigt, egal von welchem Filehoster die Anfrage stammt (etwa rapidgator und keep2share) - es erscheint allenfalls noch eine Bestätigungsbox "'I'm not a robot", danach passiert nichts weiter!

EDIT: Jetzt funktioniert es wieder.

[Karli]

grüß euch!

nachdem ja sowieso derzeit an der android-app wegen der captcha-popups gewerkelt wird: ist's möglich, eventuell der gesamten app eine dark-mode-option zu verpassen?
ist zwar nicht überlebenswichtig, wäre aber ein nice2have ...

vielen dank im voraus!

[pspzockerscene]

Myjd Threads zusammengeführt.

[neme]

Hi, I didn't understand why there was a web version of MyJdownloader... until I bought a Synology. However, using the Web version after a dozen or so years with the desktop version is inconvenient. I was wondering if it would be possible to simply create an additional profile in Jdownloader2 or create a portable version of JD2 in such a way that after entering the MyJdownloader login data, you could add links, passwords, change settings, which would then be integrated with MyJdownloader Web on demand.

To put it simply: I go to Jdownloader2 on my Windows Desktop and login to MyJdownloader => I add links => click "Synchronize" => links are added in MyJdownloader on my Synology

As always, thank you for your work and I have been supporting it with donations for many years
==
Hallo, ich habe nicht verstanden, warum es eine Webversion von MyJdownloader gibt... bis ich eine Synology gekauft habe. Allerdings ist es unbequem, die Webversion nach etwa einem Dutzend Jahren mit der Desktopversion zu verwenden. Ich habe mich gefragt, ob es möglich wäre, einfach ein zusätzliches Profil in Jdownloader2 zu erstellen oder eine portable Version von JD2 so zu erstellen, dass man nach Eingabe der MyJdownloader-Anmeldedaten Links, Passwörter und Einstellungen hinzufügen kann, die dann bei Bedarf in MyJdownloader Web integriert werden.

Einfach ausgedrückt: Ich gehe zu Jdownloader2 auf meinem Windows-Desktop und melde mich bei MyJdownloader an => ich füge Links hinzu => klicke auf „Synchronisieren“ => Links werden in MyJdownloader auf meiner Synology hinzugefügt

Wie immer danke für Ihre Arbeit und ich unterstütze sie seit vielen Jahren mit Spenden

[pspzockerscene]

Originally Posted by neme

To put it simply: I go to Jdownloader2 on my Windows Desktop and login to MyJdownloader => I add links => click "Synchronize" => links are added in MyJdownloader on my Synology

No, since this would defy the concept of a headless JDownloader instance.

You could use EventScripter scripts to create something that does exactly this though.

EventScripter subforum:
https://board.jdownloader.org/forumdisplay.php?f=52
EventScripter help article:
https://support.jdownloader.org/know...event-scripter

[Jiaz]

@neme: There are ideas about using JDownloader with GUI and "connect" it to headless version for remote control. So you can use all GUI, but the downloads are running/processed remotely on headless instance. But to be honest, at the moment it's just an idea, no work done in that direction yet.

[neme]

Thank you for your answer and great work Jiaz

[cremor]

A few weeks ago I noticed that my headless JDownloader instance, which I have running in my local network, was not using direct connections any more. I tracked the problem down to a DNS lookup error with the DNS server I'm using.
"nslookup 192-168-x-y.mydns.jdownloader.org 9.9.9.11" was suddenly returning an error, but "nslookup 192-168-x-y.mydns.jdownloader.org 9.9.9.9" worked fine.

But the problem isn't reproduceable 100% of the time. Sometimes resolving the domain via 9.9.9.11 works fine too.

9.9.9.11 is the DNS server of Quad9 which has EDNS Client-Subnet enabled.

I contacted the Quad9 support and they responded with this:

The authoritative DNS server is not EDNS compliant, so I'm not surprised it can't be resolved on .11, but can on .9. The domain administrator needs to fix this in the authoritative DNS server configuration:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

[Jiaz]

@cremor: For me both are working/failing randomly (..9.11 and ..9.9) with nslookup
but working stable/reliabe with dig command
But I will look into this when I find time

[Jiaz]

Originally Posted by Jiaz

@cremor: For me both are working/failing randomly (..9.11 and ..9.9) with nslookup
but working stable/reliabe with dig command
But I will look into this when I find time

The authoritative DNS server is not EDNS compliant,

doesn't make much sense to me?!
because the test result shows that edns works fine.

edns=ok ednsopt=ok edns512tcp=ok

DNS Server only does not respond correctly to wrong requests as expected but I expect Quad9 not to do invalid requests.

[cremor]

I don't know anything about the technical details of EDNS Client-Subnet, but from the linked result page it seems like "edns1" and "edns1opt" failed.

[Jiaz]

@cremor: Yes, but both are tests on invalid requests

Unknown Version Handling (edns1)

and

Unknown Version with Unknown Option Handling (edns1opt)

All other tests with edns are successful and working with dig command
I don't think that the issue comes from DNS server not responding correct to invalid requests as I expect Quad9 not to do invalid requests in first place.

[cremor]

You are right, it doesn't make sense that real DNS requests fail just because invalid requests are not handled correctly.

No idea what's the problem then, sorry.

[cremor]

Something is very weird right now with mydns.jdownloader.org DNS lookups. And it affects multiple DNS servers, so maybe the problem is actually caused by a recursive (or root) DNS server?

If I try "nslookup 192-168-x-y.mydns.jdownloader.org <server>" with my specific private IP address and different DNS servers right now I get these results:

1.1.1.1: Very slow (1-2 timeout messages for a 2 sec timeout), but returns the IP address
8.8.8.8: Very slow (1-2 timeout messages for a 2 sec timeout), but returns the IP address
9.9.9.9: Returns error "Non-existent domain"
9.9.9.10: Returns the IP address (fast)
9.9.9.11: Returns the IP address (fast)

But those results differ if I try other private IP addresses in the subdomain part. This also leads me to think that the problem is with recursive/root DNS servers and it just works (or works fast) for private IP addresses that happen to be cached at the DNS server.

I don't know about 8.8.8.8, but 1.1.1.1 and 9.9.9.9 do not support/forward EDNS Client-Subnet, so it's not related to what we discussed in the previous few posts.
Maybe there was never an EDNS Client-Subnet related problem, but it just happened to affect 9.9.9.11 previously while it affects more/other DNS servers now?

[Jiaz]

@cremor: nlookup will check for IPv4 and IPv6. You have to specify -q=A parameter. Working perfectly fine/fast/reliable here, without any problems.
Do you have something in your system/setup/environment that intercepts DNS lookups? Also check that no firewall/av do block rebind DNS as this may be the cause for you. Please try the lookups with IP range different of yours and see if issue persists

[cremor]

I get the same results with or without the -q=A parameter.
Right now 9.9.9.9 also behaves correctly for me. But 1.1.1.1 and 8.8.8.8 are still slow.

Before I noticed that multiple DNS servers are affected I thought this was a Quad9 problem, so I contacted their support. This is their reply that I got just 30 minutes ago:

I just replicated this using my ISP's DNS servers as well (when the authoritative nameserver didn't time out, which it did several times).

I'm going to say this is an issue on the authoritative DNS side. It doesn't make sense that our recursive DNS servers are just "choosing" to return NXDOMAIN for no reason. It is not a blocklist issue. This subdomain (mydns) is served by a single authoritative DNS server run by the domain administrator, so they should review their logs and/or do a packet capture to see what's going on.

And here is their dig output they also sent, which shows the NXDOMAIN error:

$ dig a 192-168-178-200.mydns.jdownloader.org

; <<>> DiG 9.20.6 <<>> a 192-168-178-200.mydns.jdownloader.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35155
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;192-168-178-200.mydns.jdownloader.org. IN A

;; Query time: 69 msec
;; SERVER: 10.37.204.172#53(10.37.204.172) (UDP)
;; WHEN: Thu Mar 20 18:26:30 CET 2025
;; MSG SIZE rcvd: 55

[Jiaz]

@cremor: "their dig" command is against their DNS SERVER: 10.37.204.172#53(10.37.204.172) and not ours.
I'm not able to reproduce any issues with dig, nor with nslookup. working fine at multiple location (tested two different home ISP and two different datacenter provider)
results of nslookup against all those servers.
A records do work fine, AAAA return NXDOMAIN as expected
pastebin.com/VrHfTNNR

Yes, this system only has one DNS server but that is no problem for that use case and working perfectly fine since 2016.

In my case the timeouts come from my 2nd DNS(router fritzbox), nslookup will ask all DNS servers.
When I query via nslookup host server, nslookup will ask server AND All the system DNS servers.
in my case I can see wireshark queries going to server (fast response) and fritz-box (causing timeout)
this is because nslookup will try to expand host with known dns search lookup, in my case fritz.box

adding a fake DNS that always responds with NXDOMAIN in local network, nslookup always returns NXDOMAIN for me.

using nslookup -type=A -nosearch... will disable this and wireshark shows that only server is queried and fast response, no timeout.

Also, see learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup

If the computer to find is a name and doesn't have a trailing period, the default DNS domain name is appended to the name.

nslookup host. server will also result in only the server being queried (as seen in wireshark)

I recommend to use wireshark (filter for udp.port == 53) and look out for the stream that is causing the issue.

my guess is that some dns server (eg server or router) on your setup/environment takes longer and causing the delay.
and it depends what DNS wins first. if you have multiple DNS, the fastest DNS that responds wins, meaning that when your local/environment DNS answers NXDOMAIN first , nslookup/ping will use NXDOMAIN. DNS does not work (at least not by default) that every DNS is queried. First/fastest DNS answer wins.

[cremor]

Thanks, this explains a lot.

I also use a FritzBox as my local router and I can confirm that the timeouts go away when I either use -nosearch or a trailing dot on the domain name. The -debug flag also reveals that it first tries to resolve "x.mydns.jdownloader.org.fritz.box". Stupid default behavior of nslookup...

But that still doesn't explain why my browser couldn't resolve the DNS name in the My.JDownloader web interface, does it? I'd assume the browser doesn't do such funny things.
Anyway, I don't have a problem in the browser right now. So I'll do some tests again when the problem reappears.

[Jiaz]

Originally Posted by cremor

Thanks, this explains a lot.

You're welcome!

Originally Posted by cremor

But that still doesn't explain why my browser couldn't resolve the DNS name in the My.JDownloader web interface, does it?

It does, because by default FritzBox does block rebind dns and not resolve those domains. First comes first wins, meaning when your browser asks the DNS system, and fritzbox answering first, then you will get NXDOMAIN.
You need to allow rebind on those domain, see https://support.jdownloader.org/de/k...-mode-fritzbox
then your fritzbox dns will correctly answer dns query and any other setup dns as well. all dns should always answer the same, else you encounter situations like yours where it randomly fails.

Solution: allow rebind dns on your fritzbox as explained

[cremor]

I've already configured that DNS rebind protection setting in my FritzBox. Without that setting the browser could never establish a direct connection. It worked fine for years. But now it sometimes (but not always) fails since about 4 weeks ago.

[cremor]

Right now my browser can't establish a direct connection again. nslookup with all the parameters returns NXDOMAIN. But that still doesn't connect directly to your authorative DNS server, does it?

>nslookup -type=A -nosearch -debug 192-168-178-200.mydns.jdownloader.org 9.9.9.9
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        9.9.9.9.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  9.9.9.9.in-addr.arpa
        name = dns9.quad9.net
        ttl = 33808 (9 hours 23 mins 28 secs)

------------
Server:  dns9.quad9.net
Address:  9.9.9.9

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        192-168-178-200.mydns.jdownloader.org, type = A, class = IN
    AUTHORITY RECORDS:
    ->  mydns.jdownloader.org
        ttl = 3329 (55 mins 29 secs)
        primary name server = api.jdownloader.org
        responsible mail addr = wilhelm.appwork.org
        serial  = 2016012101
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)

------------
*** 192-168-178-200.mydns.jdownloader.org wurde von dns9.quad9.net nicht gefunden: Non-existent domain.

edit: 1,5 hours later and it's working again.

[raztoki]

dns caching on quad9 side? kinda sounds like it

[cremor]

Of course they are caching, that's one of the main features of a recursive DNS server. But if they have a NXDOMAIN error in their cache this would mean that at one point the actual authorative DNS server of JDownloader replied with a NXDOMAIN error. This NXDOMAIN error was then cached for the duration of the TTL (one hour it looks like from the above output). At least that's how I understand it.

[raztoki]

has anything changed on your routers end like new firmware/hardware? as Jiaz indicated nothing has changed setup wise on their side.

Else I have heard of ISPs in the past 'dropping packets/injecting different response/or poisoning response' to external providers for example on port 53, and not just their own servers (usually assigned by dhcp). Highly doubt that be this situation though