[mav]

Valid filenames in packages (added via DLC) get "lost" (change to some id) when added to Download List from Linkgrabber.

Setting: "LinkCollector: Do Link Check" is disabled

not all the time, also not for all files within a package, haven't found a pattern yet.

examples:
happens with DDownload.com, Katfile.com
didn't happen with Rapidgator.net
same Package, different hosters.
to reproduce: add one dlc, then add package to download list before adding next dlc (3 packages in download list)
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**
**External links are only visible to Support Staff****External links are only visible to Support Staff**

Thanks, mav.

[Jiaz]

@mav: Please know that DLC is no export/import container. It does NOT preserve meta information like folder/filenames or other details. It's a container only for sharing links and JDownloader will have to fully process/crawl through the links again. If you want to move/share lists, please use this method, https://support.jdownloader.org/Know...nkgrabber-list

[mav]

@Jiaz: Please have a look at the attached screenshots of Linkgrabber and Downloads.

After adding the package from Linkgrabber (Source DLC - File / Load Linkcontainer) the filenames look fine.
Context Menu / Add all to Download List -> some of the filenames are correctly added to Downloads, but most are changed to some id.

Thanks, mav.

[Jiaz]

@mav: please send dlc to support@jdownloader.org, so I can check locally and try to reproduce the issue

[raztoki]

for memory this usually happens when the linkchecking cant happen for what ever reason 503/cloudflare for instance, and the Url pattern in the plugin listens up to the uid.

[mav]

link to the container: **External links are only visible to Support Staff****External links are only visible to Support Staff**

[pspzockerscene]

@mav
Hm strange your post #3 shows unchecked links.
As raztoki already pointed out this might be due to Cloudflare.
As expected, I can't reproduce the problem with your example URLs.

Please post your log-ID here | bitte poste deine Log-ID hier.

-psp-

[mav]

Originally Posted by raztoki

for memory this usually happens when the linkchecking cant happen for what ever reason 503/cloudflare for instance, and the Url pattern in the plugin listens up to the uid.

from my original post:
Setting: "LinkCollector: Do Link Check" is disabled

This seems to get overlooked:
In LinkGrabber all is fine. Losing filenames happens when the Package is transferred from LinkgGrabber List to Downloads List.
Any why does it happen only for some Files with a package. As stated above: Link Check is disabled.

[pspzockerscene]

Sorry my bad.

Enable it and your problem will be solved.
Without availablecheck filenames can't be found unless e.g. the links you add contain some we call "weak filenames".
Some of your links look like this:

ddownload.com/xxxxxxyyyyyy

and some like this:

ddownload.com/xxxxxxyyyyyy/someFilename.part1.rar

In the 2nd case, JD will use that filename inside the URL and display it even when linkcheck is disabled. In the first case there is simply nothing available except the internal fileID without checking the link.

[mav]

@psptzocjerscene:
to be clear about the issue and the sequence:

1. Logically LinkGrabber List comes before Downloads List.

2. In LinkGrabber all weak filenames are displayed correctly, so filename is part of the links / DLC for all files.

ddownload.com/xxxxxxyyyyyy/someFilename.part1.rar

Filenames are correct in filecrypt as well - I double checked.

3. Add all to Downloads (see screenshot)

4. now and just now - some weak filenames get lost with the same package but not all. That is the issue.

[Jiaz]

@mav: I will look into this when I got some free time

[pspzockerscene]

I can reproduce this one!
Only one DLC needed. Add it -> Move to Downloadlist -> Filenames gone except for 4 items.

@mav
Thanks for staying on the topic!

[mav]

@all: thanks for taking the time to reproduce (and eventually fix).