A Few V6 Questions

[V_M_F]

I just upgraded from Version 6, and I have a few outstanding issues that were not covered in the FAQ or a Google search:

1) How do you change the order in the Groups section? This is by far my biggest peeve, as it used to be drag-n-drop in any previous version I used, but now they seem totally locked. I use lots of OOP film groups and it's very difficult to visually parse a.b.vintage.film.xxx, a.b.vintage.film.yyy, a.b.vintage.film.zzz, a.b.vintage.film.aaa, etc. with no method to sort them manually. If you can answer/solve just one problem, this is it, as I'm about ready to revert to V5.

2) How to get the standard "Last Updated" field in the Groups section to display as Days (like it used to) without changing the Posting Format (which works best as a Date, again, as it always used to). They seem be tied together for some strange reason, when in V3/V4/V5 it was the properly formatted way. Is there a "switch" for the Last Updated field?

3) Is it possible to Hide/Delete/Get Rid Of the Search tab? Not a big deal, but I remember being able to before and since I've never ever used it, the extraneous tab just adds to the overall clutter.

4) How can you change the post display to list the individual (RAR, R001, R002) files, without the "+" - I know how to expand/ungroup them, but it is extremely time-consuming to manually do that over and over for hundreds and hundreds of new posts - plus, when you load a "+" set to download without first expanding it, you cannot "remove from download list" individual files - delete one and it removes them ALL and then deletes all previously downloaded files (BAM!). I found that out the hard way LOL. This group/ungroup posts option used to be in the Display box, but it seems to be gone now.

Also, if some/none of these are solvable, can you safely downgrade to V5 without losing settings or posts?

[Quade]

It's pretty much "can't" across the board. The groups order thing is on my todo list.

Is there any particular reason you want to micromanage the download and not just let Newsbin handle the RAR and PAR processing? You can add the whole set, and "sample" when a couple rars downloads. It's in the right click menu.

[V_M_F]

I only download indic=vidual posts now, as there doesn't seem to be any way to delete individual files once you auto-load them as a group. I tried yesterday and it deleted all undownloaded posts, and then permanently deleted the 6GB of downloaded files as well.

Is there a way around this? In my experience, load as a group and Newsbin treats them all as a group when deleting from the download list.

[V_M_F]

Also, were any of these issues changed in any V5 revision? I think I was using 5.54 or 5.55 and everything worked perfectly, so would I be safe with 5.59?

[Quade]

I only download indic=vidual posts now, as there doesn't seem to be any way to delete individual files once you auto-load them as a group.

You're saying you never download enough RAR files to unrar the entire set?

5.59 will work for you. As for the deleting thing, as I said in the other post about this, it did warn you before deleting the files.

[V_M_F]

Downgraded to 5.59 and it's working perfectly. Settings, posts, everything.

And here's my deal on V6 downloading - I disable auto-Par because I want full control over when and how I expand it (I have multiple PCs on the network as well as 3 media players, so I may DL for weeks, then pick and choose destinations) so when I load a "group post" I get 100% of the PAR files, which I do not need and then have to go in to delete them. I either do that for every single post I download, or I manually expand each and every post - both are very time consuming compared to just having them auto-expanded as a default and then shift-click to DL.

I like some of the V6 features and the GUI, but I still feel that V6 has gone down the "hardcore user" path a bit too much, and I prefer the flexibility of V5 myself. I can configure it to my individual tastes, while V6 forced me down a very specific path with no ability to change the defaults. Even something simple, like having Days for Last Updated and Date for individual posts, which has been the default since I started NB with V3.

No biggie and I appreciate you still offering V5 as a download. The downgrade was a breeze and I'm a happy camper again.

[driverdude]

I too turn off par and unrar and use my own post processing to do that and only desire the newsreader to handle Yenc possible retries among fill servers and the like. I have several good reasons and past examples with other products where I will only trust my own par2 and unrar automated tools. The very first time i tested this product using a specially known par2 fixable bad file fetch, I think I had auto par2 on and because yenc passed perhaps, i THINK (not sure) it saved bad files without warning, but the files were corrupt on uploaders side and the included par2 files saved to drive detected and fixed in post processing on my side. perhaps the type of corruption was near the tail end of the file, and only front md5 was used, perhaps Yenc was trusted too much, perhaps par2 codebase was different in some key way, or some other thing. More likely it was user error, but I can easily retry the example test another day, for I know the files. Incidentally, though probably not relevant it was a fileset fullfilled usingtwo servers at the time. All I meant to say is that in one test out of one , or 100% of my tests, using cherry picked file set, I got this program (and OTHERS), to silently save corrupt (according to par2) files to disk. I meant to retry the tests and do it properly at a later time before bringing it up, and its not even an issue to me, because I do my own par2 , sfv, and unrar anyway, always. I prefer the par2s to not change position in the file download list, I just want to select a pile of usenet messages and get them to download and dump to files in one huge directory, no other features. Traditional special case selection-search is done nowadays by nzb tools on another machine.

VERY VERY VERY happy with the many things this amazing product does do though. NTFS ADS file tagging with usenet uploader and subject being a prime one.

In summary.. The auto grouping is not that annoying to me, but it would be nice to have a toggle switch, especially because autogrouping ignores some files that I use tools to regroup back in using logic, such as nzb files uploaded with the group. or external files outside the par2 itself yet associated with the upload.

[Quade]

Autopar groups anything that's mentioned in the PAR file these days. During the unrar process it also moves any other files that happen to be named in the PAR.

Code: Select all

 perhaps Yenc was trusted too much,

Because of bugs in common posters, you can't trust the yEnc CRC at all. At best it can be used for reporting. You can't really use it for disallowing a particular block because of CRC. Most of the time if the CRC is bad on one server, it's bad on every server. Even a bad block is better than no block for par processing. A single bad post can potentially take out 2 or more par blocks. Better to save it and hope the par processing can salvage blocks out of the bad post. PAR blocks aren't always lined up so, it's one block per post. At least there's no requirement that that be true.


My answer to much of this is "it's usenet". It's best effort across the board. Nothing is ever perfect.

[driverdude]

OH NO

If you save files with bad Yenc CRC, which some other usenet readers do not save by the way, even if you do it to possibly aid PAR/PAR2, is there at least a way you could add details to the file to warn the user that the file may be bad, especially if there are no PAR2 to begin with. Otherwise we are saving bad files.

For example in addition to the NTFS ADS usenet subject added to every file and the uploader, could you add fields at the end similar to the "descript.ion" file such as usenet upload date, and now a new request such as [[FILE FAILED YENC]], or [[PARTIAL FILE]], or [[DAMAGED FILE]] or something.

Otherwise i fear I have now possibly collected thousands of files that were damaged in transit either to a server or from a server, that are not detectable due to no sfv or par2 or par and no way to set program to stop doing that.

Perhaps store them in a different subdirectory as an option, if no par2 in upload or is autopar disabled, move them later after assembly.

I understand that you say YEnc used to not be trusted for bad crc, but I would hope that would not be the case in the last couple years.

I and most people using files containing no inherent crc typically (audio files) would prefer to not have any damaged files in collections at all. And if Yenc is all we have left to aid us, then at least tag the damaged files, or separate them or create a log technology to aid us in destroying them.

I have no idea how shoddy Yenc is or is not in 2012, but I do think I would like to know if a file is damaged, or seems damaged, and decide if i want to keep them or not.

Now I understand how I can download 50,000 test files with this product and see no REPORTED damaged files not covered by par2.

Please consider at least affixing damage status data to the NTFS ADS comment

[Quade]

I understand that you say YEnc used to not be trusted for bad crc, but I would hope that would not be the case in the last couple years.

1 - Even if everything today is posted perfectly, there's still 1400 days worth of old files that weren't.

2 - Often times there's nothing wrong with the post that has a bad yEnc CRC. The posting software either filled in the wrong CRC or set the CRC to zero. You simply can't tell anything from the yEnc CRC.

3 - Old posting software is still being used today.


If you enable debug level logging in the options, you should see Newsbin log error messages about the yEnc state to "Logfile.txt" in the data folder and to the logging pane.

"YEnc Reported and Actual Size don't match: Filename"
"Bad YEnc CRC: Filename this is a posting program problem"
"Bad YEnc CRC: Filename;"

I'll repeat though, getting one of these errors doesn't mean the file is bad. You just can't tell. Unless there's a Par file or SFV, downloading from usenet is best effort. Expecting it to work better than that is unrealistic.

[driverdude]

I bet a lot of people would rather not save files that lack par2 or sfv with Yenc reported corruption. Especially audio files. Its one of the main joys of Yenc, to know that files are are intact. If reported spuriously bad I would at least want to know about them, tag the files, move the files, or anything other than silent contaminated storage. I would suspect that files in the last 1400 days uploaded with Yenc are legit, but you are correct that some people somewhere might use very old uploaders with perhaps illegal Yenc, but Id still prefer not to have such files then to ignore Yenc from everyone else. You ignore LENGTH of file AND ignore YENC CRC too? Those are files I really would not want around without being able to at least know about them.
Your log seems to not roll over into a prior log, but to delete entirely. Consider saving the prior log, or even better appending to a rollover log with a fixed size. Some people want no forensic backup residue but those people are odd and should be moving entire newsbin data folder to a encrypted partition mount if that paranoid. If I see no Yenc messages of the type you are stating on 2008 files, then I should be relieved I suspect, but it also means that this issue of people using bad clients in 2012 is probably not common in recent years and trusting Yenc for files lacking par2 and sfv should be considered. I will check it out. At least give people a choice to fail such corrupted files, or mark them, or move them or name them or something.
Anyway thanks for responding, and thanks for the product.

[Quade]

. I would suspect that files in the last 1400 days uploaded with Yenc are legit,

You would be wrong. I was looking at an issue for some files posted 30 days ago. Old posting software, bad subject format.

Your log seems to not roll over into a prior log, but to delete entirely. Consider saving the prior log,

I added an option just for you:

[LOGGING]
Append=?

0/1 = 1 means append. Default it to no append.

It'll be in the next beta. It'll let you tell Newsbin to simply append to the logfile file. Letting the file just grow for normal users is a bad idea.

If I see no Yenc messages of the type you are stating on 2008 files, then I should be relieved

yEnc CRC errors are rare period. You seem to want to toss out perfectly fine files. I'm not keen on the idea. I have no problem with giving you the tools to do it though, like the logging file.