Right now, if I right click on an incomplete collection and choose "Download & Save Attachments (auto)", I would expect the program to automatically watch the collection to ascertain when all of the parts were finally available and to complete the download and joining of the PAR2 or RAR files without further intervention. (I have the program configured so that it automatically gets headers once per hour.) In other words, I would expect the user to be able to mark the collection once from the context menu and expect the program do whatever is necessary to retrieve the desired file represented by the collection.
Instead, the program only retrieves the files that are currently in the partial collection. Even if the rest of the files necessary to complete the decode appear later, the program does not recognize that these should be downloaded to complete the download. Instead, the user has to mark these manually for download.
Moreover, once the file was successfully decoded, I would expect the program to remove the collection from the window even if more par2 files stragged in later. In other words, the program should be clever enough to realize that once the file had been successfully downloaded and decoded, the collection is no longer of interest, so it should not rise from the dead and clutter up the window.
To summarize, I would like the be able to right-click on a collection, whether partial or complete, walk away from the computer, and have the program do what was necessary to put the decoded file on my hard drive.
Can I set options in the program to implement this desired functionality?
Auto watch/download/decode of incomplete collections
-
Robert2413
- Posts: 35
- Joined: Mon Jun 13, 2005 11:02 pm
auto collections are more organizing group headers in a compact way. i didn't go as far as to add an option to automatically mark for download newly incoming files into collections which have other files downloaded or being downloaded, the collection feature was rather perceived as view mode with the ability to invoke different operations on collection files as a whole as they are at the moment. just in usenet there is no strict definition of well-defined collection friendly subject, collections are just a heuristic algorithm of my own design.
with partial messages if a part has arrived while a partial is being downloaded those parts are marked for download as well, in principle the same could be added for collections (only as an option which is disabled by default), i'm not sure though it would be practical, for some collections it could lead to downloading of a lot of unwanted files.
collections are not connected to unpack directly, they only reflect what is in the view, only if the post subject is well-formed the data files listed in the par2 files and the collection files will be the same.
with partial messages if a part has arrived while a partial is being downloaded those parts are marked for download as well, in principle the same could be added for collections (only as an option which is disabled by default), i'm not sure though it would be practical, for some collections it could lead to downloading of a lot of unwanted files.
collections are not connected to unpack directly, they only reflect what is in the view, only if the post subject is well-formed the data files listed in the par2 files and the collection files will be the same.
-
Robert2413
- Posts: 35
- Joined: Mon Jun 13, 2005 11:02 pm
I think that the feature that I suggested would be good to add.
I think that, by definition, the goal of anyone who buys a binary news reader is to download and decode binary files in the most transparent and convenient way possible. Take Bit Torrent for example. Typically, one clicks on a link on a web page to download the torrent. One or two more clicks get the Bit Torrent client going. From there on in, everything is automatic; the combination of the client and tracker aggregate all of the data and deliver the desired file to the user's hard drive. The user can walk away and do something else. The initial few mouse clicks is all that is necessary to satisfy the user's requirement.
There is no reason why a USENET reader cannot be equally as easy to use once it is set up. Usenet Explorer came a long way toward this goal with the 2.0 release. But from a marketing perspective, I think that it is always wise to consider the user's goal and to offer a solution that satisfies that goal better than one's competition. For binary news readers, the user's goal is almost always to acquire a binary file effortlessly. Except in pathological cases, the underlying mechanism that retrieves and decodes the file should be completely transparent to the user. In the case of Usenet Explorer, a collection should represent a binary file object to the user. The user should be able to see a collection, whether complete or incomplete, and tell the program to "please acquire the binary file that this collection represents and tell me when you have done this successfully." After a successful download and decode, the program should do the necessary clean-up, including removing the binary file object (the collection) from the user's view.
In most cases, incomplete collections are incomplete because the sender has not finished uploading all of the parts or because the parts have not yet propagated through the network. In this case, an ideal program should have no problem watching for missing parts and acquiring them in a way that delivers the completed file to the user with minimum delay.
The pathological case, of course, is when an incomplete collection is incomplete because the sender failed to upload all of the parts or because there was a problem in the network that prevented the parts from being delivered to the user's provider. I think that a user-specified global timeout parameter could be added to the program so that after the timeout the program would abandon trying to fetch the desired media file if the combination of main parts and PAR2 files in the collection was insufficient to reconstruct the file. After the timeout, the program would mark the collection as abandoned and would automatically delete any related data that it had successfully downloaded.
I think that, by definition, the goal of anyone who buys a binary news reader is to download and decode binary files in the most transparent and convenient way possible. Take Bit Torrent for example. Typically, one clicks on a link on a web page to download the torrent. One or two more clicks get the Bit Torrent client going. From there on in, everything is automatic; the combination of the client and tracker aggregate all of the data and deliver the desired file to the user's hard drive. The user can walk away and do something else. The initial few mouse clicks is all that is necessary to satisfy the user's requirement.
There is no reason why a USENET reader cannot be equally as easy to use once it is set up. Usenet Explorer came a long way toward this goal with the 2.0 release. But from a marketing perspective, I think that it is always wise to consider the user's goal and to offer a solution that satisfies that goal better than one's competition. For binary news readers, the user's goal is almost always to acquire a binary file effortlessly. Except in pathological cases, the underlying mechanism that retrieves and decodes the file should be completely transparent to the user. In the case of Usenet Explorer, a collection should represent a binary file object to the user. The user should be able to see a collection, whether complete or incomplete, and tell the program to "please acquire the binary file that this collection represents and tell me when you have done this successfully." After a successful download and decode, the program should do the necessary clean-up, including removing the binary file object (the collection) from the user's view.
In most cases, incomplete collections are incomplete because the sender has not finished uploading all of the parts or because the parts have not yet propagated through the network. In this case, an ideal program should have no problem watching for missing parts and acquiring them in a way that delivers the completed file to the user with minimum delay.
The pathological case, of course, is when an incomplete collection is incomplete because the sender failed to upload all of the parts or because there was a problem in the network that prevented the parts from being delivered to the user's provider. I think that a user-specified global timeout parameter could be added to the program so that after the timeout the program would abandon trying to fetch the desired media file if the combination of main parts and PAR2 files in the collection was insufficient to reconstruct the file. After the timeout, the program would mark the collection as abandoned and would automatically delete any related data that it had successfully downloaded.
This has been suggested by myself and one or two others already. From Alex's perspective, he tends to focus on making UE bullet proof. Just to round out the concept of automation in UE, an automatic search for missing files would be just about perfect. Having said that, Repair/Unpack is already such a big feature there needs to be time to evaluate it for anything undesired that crops up.
Over the years there have been quite a few things on my wishlist that still haven't made it into UE. A lot of it counts on how many people want it to happen, so here's my vote (again) for, hmm..., Auto Binaries Completion (ABC).
Over the years there have been quite a few things on my wishlist that still haven't made it into UE. A lot of it counts on how many people want it to happen, so here's my vote (again) for, hmm..., Auto Binaries Completion (ABC).