[koningx]

Package includes link we add by clipboard normally

However i was thinking if a Feature of sub package can be made to group

links for same type of content with different mirror links , under one group

it would be greatly helpful.

and it must be upon user to add files to sub package.

--------------
or better yet if the current package thing can remain so on intact , for it may effect links already added if architecture of adding links is changed.

Instead above the package thing , there can be "Group package" thing can be implemented, so that it acts as Parent package , and the original package can act as subpackage.


Benefit : it can be greatly useful to group content with different mirror links (with added comments on side ) in a package(which behaves as a subpackage) and then those packages of similar contents can be Grouped into
another Upper level package called "Group Packages"

Present Hierarchy is like :

package>mirror links

New Hierarchy becomes then like :

Group packages>packages>mirror links

and it can be beneficial in sometimes to seperate content of same types with grouped mirror links.


it like this in tree structure -

Content from/of 1 same entity( 1 Group Package)>>
_______________>>Package of 1st type same content of 1 entity>>
_______________________>>mirror links grouped under one package
_______________>>Package of 2nd type same content of 1 entity>>
_______________________>>mirror links grouped under one package
_______________ >>Package of 3rd type same content of 1 entity>>
______________________ >>mirror links grouped under one package

and so on....


I hope you are getting the idea what i am trying to convey !:)

[pspzockerscene]

I don't completely get it - does this mean we'd need sub-packages?
We will not implement sub-packages.

About the downloadpaths or "categories":
Please use the packagizer for such things.

[raztoki]

I don't see us adding nested packages, this is what this request basically entails

packagiser allows for powerful rules to be set, and jd default packing should group according to filename patterns.

[Lyranx]

Made a similar request bout this last month.
Would like to see it too.

Not sure if this is how "user feedback required" works.

[koningx]

What i mean is existing packages should remain as so they are and working right now by
default as do now. so jd default packing should group according to filename patterns.

like @raztoki said

However
there should be some kind of feature so that OPTIONALLY if one wants to Group similar type of packages belonging to/about a same thing or content ,
these exitsing package can then be grouped together into under a PARENT/FATHER package.

it will help in distinguishing similar kinds of download stuff belonging to one thing/entity.


For example: when i download pr0n sometimes , lol , almost everybody does

i would like to group all her packages containing mirror links into one PARENT package.

Babe's package(PARENT PACKAGE)
>>Packages that are right now existing , which group
files as per filenames and mirrors into one.
Every package may have different mirror links in them.
i.e. like One Package of One Video file/sets with mirror links.

and later these package can be grouped into a PARENT PACKAGE inculding existing package.

Thus things remain simplified and less messy looking.

i hope you are getting.

This will help a lot in seperating the stuff with mirrored links also grouped together in a package which inturn is grouped into PARENT PACKAGE.

[koningx]

it's like to explain more :

Babe 1 or any content 1 like: (PARENT PACKAGE)(grouped later
-----------VIDEO1(EXISTING PACKAGE as they work right now)
-----------------------VIDEO1 link 1
-----------------------VIDEO1 link 2(mirror)
-----------------------VIDEO1 link 3(mirror)
-----------VIDEO2(EXISTING PACKAGE as they work right now)
-----------------------VIDEO2 link 1
-----------------------VIDEO2 link 2(mirror)
-----------------------VIDEO2 link 3(mirror)

Babe 2 or any content 2 like: (PARENT PACKAGE)(grouped later
-----------VIDEO1(EXISTING PACKAGE as they work right now)
-----------------------VIDEO1 link 1
-----------------------VIDEO1 link 2(mirror)
-----------------------VIDEO1 link 3(mirror)
-----------VIDEO2(EXISTING PACKAGE as they work right now)
-----------------------VIDEO2 link 1
-----------------------VIDEO2 link 2(mirror)
-----------------------VIDEO2 link 3(mirror)

Babe 3 or any content 3 like: (PARENT PACKAGE)(grouped later
-----------VIDEO1(EXISTING PACKAGE as they work right now)
-----------------------VIDEO1 link 1
-----------------------VIDEO1 link 2(mirror)
-----------------------VIDEO1 link 3(mirror)
-----------VIDEO2(EXISTING PACKAGE as they work right now)
-----------------------VIDEO2 link 1
-----------------------VIDEO2 link 2(mirror)
-----------------------VIDEO2 link 3(mirror)

Here each videos belong to respective babes or any content/category.

[Jiaz]

Wont happen that fast(or at all) because the current backend/controlling is all designed for package-children structure. adding additional levels requires major code rewrites/changes.

[Jiaz]

I'm sorry but this feature is declinded. Absolute no manpower/time to handle this rewrite/change.

Instead an additional level it would make more sense to give labels to downloads which can be used for filtering/view?

[koningx]

Nevermind ! i can understand dear , absolutly no prob, everyone remains busy with something or other. work is priority based.

though i thought it might've been useful for other users too as a feature.

but since you say it'll require major code rewrites/changes, as i also assume it will

alter the entire architecture so let it go.

[Jiaz]

What about labels? Would those help you *organize* your lists?

[pspzockerscene]

And by the way - some users already tell us that JD would be too complicated.
This change would indeed make it complicated!

[koningx]

No i don't think so it will complicate the existing structure.

i know the feature has been declined for now.BUT it can be considered in for FUTURE UPDATES. like for JDOWNLOADER 3 with a new better architecture.

i think it will be worth the effort in future.

BUT What i was trying to says is that exactly -

the JD2 current structure is like this below-

(since package name is taken from the filename for same filetypes
with different mirror links.)

------Movie1(package)
-------Movie1(filename)----------**External links are only visible to Support Staff** -------Movie1(filename)----------**External links are only visible to Support Staff** -------Movie1(filename)----------**External links are only visible to Support Staff** ------Game1(package)
-------Game1(filename)----------**External links are only visible to Support Staff** -------Game1(filename)----------**External links are only visible to Support Staff** -------Game1(filename)----------**External links are only visible to Support Staff** ------BabeFile1(package)
-------BabeFile1(filename)----------**External links are only visible to Support Staff** -------BabeFile1(filename)----------**External links are only visible to Support Staff** -------BabeFile1(filename)----------**External links are only visible to Support Staff** ------Movie2(package)
-------Movie2(filename)----------**External links are only visible to Support Staff** -------Movie2(filename)----------**External links are only visible to Support Staff** -------Movie2(filename)----------**External links are only visible to Support Staff** ------Game2(package)
-------Game2(filename)----------**External links are only visible to Support Staff** -------Game2(filename)----------**External links are only visible to Support Staff** -------Game2(filename)----------**External links are only visible to Support Staff** ------softFile3(package)
-------softFile3(filename)----------**External links are only visible to Support Staff** -------softFile3(filename)----------**External links are only visible to Support Staff** -------softFile3(filename)----------**External links are only visible to Support Staff** ------BabeFile2(package)
-------BabeFile2(filename)----------**External links are only visible to Support Staff** -------BabeFile2(filename)----------**External links are only visible to Support Staff** -------BabeFile2(filename)----------**External links are only visible to Support Staff** ------TVShow1(package)
-------TVShow1(filename)----------**External links are only visible to Support Staff** -------TVShow1(filename)----------**External links are only visible to Support Staff** -------TVShow1(filename)----------**External links are only visible to Support Staff**

What i am thinking of is to organize similar type of packages grouped under ONE MAIN SAME ENTITY TYPE.

Now, Grouping the existing similar type of packages(with mirror links) in one Parent Package.

that is existing packages can be grouped "optionally" if wanted into
ONE MAIN PACKAGE, having all similar type of packages from one entity.

it can be done like by

creating option of CREATING MAIN PACKAGE out of existing selected packages.

OR Moving existing selected packages into under a NEW PACKAGE,
by nesting those selected packages into that NEW Package.

like we Move file links from one package to another.
Only this time, we move packages into another package, BUT packages remain NESTED.

it can be new and better structure can be like this as below -

where every packages from similar entity type now can be grouped under that ONE MAIN TYPE OF ENTITY in a drop down tree structure.

rather than packages of different kind scattered here and there up and down


New better Organized Structure can be -

MOVIES1(Top Level package)
------Movie1(package)
-------Movie1(filename)----------**External links are only visible to Support Staff** -------Movie1(filename)----------**External links are only visible to Support Staff** -------Movie1(filename)----------**External links are only visible to Support Staff** ------Movie2(package)
-------Movie2(filename)----------**External links are only visible to Support Staff** -------Movie2(filename)----------**External links are only visible to Support Staff** -------Movie2(filename)----------**External links are only visible to Support Staff**
GAMES(Top Level package)
------Game1(package)
-------Game1(filename)----------**External links are only visible to Support Staff** -------Game1(filename)----------**External links are only visible to Support Staff** -------Game1(filename)----------**External links are only visible to Support Staff** ------Game2(package)
-------Game2(filename)----------**External links are only visible to Support Staff** -------Game2(filename)----------**External links are only visible to Support Staff** -------Game2(filename)----------**External links are only visible to Support Staff** ------Game3(package)
-------Game3(filename)----------**External links are only visible to Support Staff** -------Game3(filename)----------**External links are only visible to Support Staff** -------Game3(filename)----------**External links are only visible to Support Staff**
BABE1(Top Level package)
------BabeFile1(package)
-------BabeFile1(filename)----------**External links are only visible to Support Staff** -------BabeFile1(filename)----------**External links are only visible to Support Staff** -------BabeFile1(filename)----------**External links are only visible to Support Staff** ------BabeFile2(package)
-------BabeFile2(filename)----------**External links are only visible to Support Staff** -------BabeFile2(filename)----------**External links are only visible to Support Staff** -------BabeFile2(filename)----------**External links are only visible to Support Staff**
BABE2(Top Level package)
------BabeFile3(package)
-------BabeFile3(filename)----------**External links are only visible to Support Staff** -------BabeFile3(filename)----------**External links are only visible to Support Staff** -------BabeFile3(filename)----------**External links are only visible to Support Staff**
SOFTWARE1(Top Level package)
------softFile3(package)
-------softFile3(filename)----------**External links are only visible to Support Staff** -------softFile3(filename)----------**External links are only visible to Support Staff** -------softFile3(filename)----------**External links are only visible to Support Staff**
MOVIES 3(Top Level package)
------Movie3(package)
-------Movie3(filename)----------**External links are only visible to Support Staff** -------Movie3(filename)----------**External links are only visible to Support Staff** -------Movie3(filename)----------**External links are only visible to Support Staff** ------Movie4(package)
-------Movie4(filename)----------**External links are only visible to Support Staff** -------Movie4(filename)----------**External links are only visible to Support Staff** -------Movie4(filename)----------**External links are only visible to Support Staff**
TV SHOWS(Top Level package)
------TVShow1(package)
-------TVShow1(filename)----------**External links are only visible to Support Staff** -------TVShow1(filename)----------**External links are only visible to Support Staff** -------TVShow1(filename)----------**External links are only visible to Support Staff** ------Show2(package)
-------Show2(filename)----------**External links are only visible to Support Staff** -------Show2(filename)----------**External links are only visible to Support Staff** -------Show2(filename)----------**External links are only visible to Support Staff**

etc..etc...for which JD is generally used.

it can be highly beneficial from point of view of keeping packages Organized.

Developers please Think and ReConsider , for future JDdownloader 3 May be.
Hope you are getting and understand what i mean.

[Jiaz]

So you wish a way to organize packages?
Maybe instead of another level in tree we can add a group property to packages? so you can easily assign a tag/group to a package and then only filter to view a specific group/tag?

Adding another level in tree is very complex. It's even more complex when the new entity is different than package and its children. That's why it will not happen for current development.

[koningx]

Yes i want to keep packages of similar entity to be organized if they all belong to a ONE
Entity type.

right now what you are trying to say is also a workaround ,

But adding a tag to each and every and every package, each and everytime can be a bit of long work.

right now i do that using comments feature.

But still the Long list are longs list then too, and can't see what all i have to download in
my long list and what is pending and what is priority, while scrolling in those long list of packages.

i was thinking it could have been better if just to select and drag and drop , similar packages into ONE Main tree type of package, giving a short compact overview of our download tasks in and by creating a MAIN package out of selected packages by Nesting them under a tree structure.

which can also finction to collapse n expand those lengthy trees , to make look download list with 10000s links bit nice and cleaner. rather than all jumbled up on first look.

Plus if we add group tag everytime to the package , that may also work , BUT we have to remember the Tag we added. But we can't then collapse and expand those big download lists to see kind of the actual overview of our long scrolling download lists.

rather only filter them , too see parts of them.

it might not be possible with the current version and architecture of Jdownloader, the way it handles links like you say .

BUT may be of anyday anytime , if a new version completely is thought to be made from scratch again , based from existing features of JD2 into JD3.

like JD2 was made after JD1, to be completely new again with UI and all.

OR

if there gets a problem in Naming conflicts in packages .

we can resolve it like-

The Top Level package can be made Optional. allowing functionality of droppng the existing packages into another packages when only wanted/needed, done manually, not by default.


By default, links get added to the linkgrabber the same way as they do now.
and so the filenames and packagenames get generated by default like they do now.

But i mean Later when those packages can be dragged into another package.
or create a package out of those packages. that new package will always
have default name a s"Various Files" like what JD2 usually takes the package name
for links with different filenames. and so same then happens with when there are package with different packagenames.

like with default names-

Various Files(TOP MAIN PACKAGE)[created manually, when need to group some packages]
------Various Files(package with files with different names, like JD2 does so now)
---------file1-----link1
---------file2-----link2
---------file3-----link3
------filename1(another package, with name of the package same as name of the file with mirror links)
-----------filename1----link 1 to it--
-----------filename1----link 2 to it--
-----------filename1----link 3 to it--
------filename2(package)
-----------filename2----link 1 to it--
-----------filename2----link 2 to it--
-----------filename2----link 3 to it--

i can surely understand it can't be done with the current architecture and development.

BUT May be for a Future Re-build of JDownloader IF thought again.

This architecture i think of servers better the purpose of Organising those download lists and packages lists into more organized and systematic and collected manner.

rather than some of different packages of different type of entities scattered here and there.

That' the whole idea and point of it. to have more systematic organization of long list of packages in Jdowloader.

[xcy7e]

Three years later I'm wondering, if the suggested "Group"-Feature has been implemented..?

You developers seem to approach the request by thinking from dev's perspective. You might rather just imagine the requested result, like grouping, which would not be hard to be implemented.. right?

I'm a developer myself and what you tell us about your architecture sounds a bit silly, no offense. I'm very interested to know, if there were - at some point in the past - a major requirement to cut your agility in such a bad way.

As said.. no offense.

[airhorn]

Originally Posted by Jiaz

I'm sorry but this feature is declinded. Absolute no manpower/time to handle this rewrite/change.

Instead an additional level it would make more sense to give labels to downloads which can be used for filtering/view?

This sounds like it would meet my needs.

I sometimes have hundreds or thousands of packages queued for download, the files of each package being written to a different directory. A way to either collapse these lists (all packages from a single host, or even better by save directory) or group them with tags and then restrict the view to certain tags would work.

I've tried adding comments to some packages, but do not see how to restrict the view in either the download list or the linkgrabber list by comment text. I can order by those values, but how do I show only particular values?

[airhorn]

Another mechanism that might work here, and likely doesn't really require changes to the data model, would be to allow the list to be collapsed by 'save to' path.

I've got rules set up so things download to (basically) a path like

e:\jdownload\$host\$poster\$packagegroup\$package

all based of regex field extraction. For instance

e:\jdownload\youtube\MasqueradeJacker\Dark Fantasy GMVs\ (packages)
e:\jdownload\youtube\MasqueradeJacker\Hybrid GMVs\ (packages)
e:\jdownload\youtube\MasqueradeJacker\Light Fantasy\GMVs\ (packages)

Being able to collapse the list by directory could let me, for example:

• roll everything up by host
• roll everything up by host and poster
• roll everything up by host, poster, and package group.

This is probably 'just' an interface change, needing to introduce a new type of grouping to the data model.

[mgpai]

Originally Posted by airhorn

... how to restrict the view in either the download list or the linkgrabber list by comment text. I can order by those values, but how do I show only particular values?

You can use the search filter in the bottom toolbar. Select "comment" and enter your search terms to filter by link comment or do the same with "comment(Package)" to filter by package comment.

[Jiaz]

@airhorn: I'm sorry but that idea requires much more work/changes that it might look like.
Currently there is a highly optimized Data->View Controller/Model that can handle hundrets of thousands of entries. It's internal structure
is Package with Links in it. And everything (View, Actions, Controlling, Selection...) is build upon this Data structure.
Package is the only entity that has/knows a directory. Links are *children* of a Package and multiple Packages are *children* of the Controller/Root.
That complexity increases with each *sub package*

You could also assign that meta information as a comment and then use regex in search field at the bottom to filter/view only those matching on your regex

[airhorn]

Originally Posted by Jiaz

@airhorn: I'm sorry but that idea requires much more work/changes that it might look like.
Currently there is a highly optimized Data->View Controller/Model that can handle hundrets of thousands of entries. It's internal structure
is Package with Links in it. And everything (View, Actions, Controlling, Selection...) is build upon this Data structure.
Package is the only entity that has/knows a directory. Links are *children* of a Package and multiple Packages are *children* of the Controller/Root.
That complexity increases with each *sub package*

You could also assign that meta information as a comment and then use regex in search field at the bottom to filter/view only those matching on your regex

Having no access to the code I can hardly refute a declaration that the idea is hard to implement. I think I might have worded my suggestion poorly.

This is not to dispute your decision, by the way. "I don't want to" is a totally legitimate answer. I think my description might have given the wrong idea so I want to expand a bit in case it causes you to change your mind

I'm suggesting a way of grouping packages, not creating subpackages. Package is exactly where I'd want the key value. That is, grouping the packages within the Controller/Root.

For example, I have queued right now downloads with the following download directories

• jdownload\youtube\BBQpitmasterx\Top 5 Barbecue Recipe Videos 2016\BACON FLAVORED RIBS - Smoked Iberico Belly Ribs
• jdownload\youtube\BBQpitmasterx\Top 5 Barbecue Recipe Videos 2016\HOT & FAST BRISKET - How to smoke a brisket in 6 hours
• jdownload\youtube\BBQpitmasterx\Top 5 Barbecue Recipe Videos 2016\HOW TO MAK EPORCHETTA - Pork Roast Crispy Skin Recipe
• jdownload\youtube\BBQpitmasterx\Top 5 Barbecue Recipe Videos 2016\HOW TO MAKE ROASTED PORK BELLY with CRISPY Skin - Lechon
• jdownload\youtube\BBQpitmasterx\Top 5 Barbecue Recipe Videos 2016\HOW TO ROAST A PIG - Spit roast piglet - Spanferkel recipe
• jdownload\youtube\bgfiles\Being with Babish\Giving $10,000 to My Biggest Fan
• jdownload\youtube\bgfiles\Being with Babish\Giving Back to a Fan in Need
• jdownload\youtube\bgfiles\Being with Babish\Surprised My Brother with a Tesla
• jdownload\youtube\bgfiles\Being with Babish\Surprising a Fan with a Vegas Hotel Suite
• jdownload\youtube\bgfiles\Being with Babish\Surprising Rashid
• jdownload\youtube\bgfiles\Being with Babish\Training like Kratos for 30 Days
• jdownload\youtube\bgfiles\Being with Babish\Whiskey Basic

I'm suggesting this could be used to group the packages (that have the directory information) in a hierarchy something like

• jdownload
  • youtube
    • BBpitmasterx
      • Top 5 Barbecue Recipe Videos 2016
        • BACON FLAVORED RIBS - Smoked Iberico Belly Ribs
        • HOT & FAST BRISKET - How to smoke a brisket in 6 hours
        • HOW TO MAK EPORCHETTA - Pork Roast Crispy Skin Recipe
        • HOW TO MAKE ROASTED PORK BELLY with CRISPY Skin - Lechon
        • HOW TO ROAST A PIG - Spit roast piglet - Spanferkel recipe
    • bgfiles
      • Being with Babish
        • Giving $10,000 to My Biggest Fan
        • Giving Back to a Fan in Need
        • Surprised My Brother with a Tesla
        • Surprising a Fan with a Vegas Hotel Suite
        • Surprising Rashid
        • Training like Kratos for 30 Days
        • Whiskey Basic

The top level 'jdownload' seems unneeded because everything is under the same folder, but I can imagine having rules storing things in different drives or root folders, so I'd leave it.

This would allow collapsing each group of packages at the download root, source, poster, and video list levels. The key (the path) is already present at the Package level where I'd expect it to be needed. No data structure changes required (probably, though I can imagine wanting to cache the parsed path rather than parse again each time).

However! It's not like you're one of my contractors

If you don't want to do it, don't do it.

And I'll check out that search option. I'd never even noticed it way down at the bottom of the screen.