Newsbin 6.91 B4 Beta - build 5595

[Quade]

Fixes a nasty bug in B3 where split apart files covered by a PAR could be removed from the download list.

https://s3.us-east-1.amazonaws.com/downloads.newsbin.com/downloads/beta/nb691B4-5651.exe

Changes:

- Autopar and download: Enabling delete by parid causes files from a loose set to be removed from the download list after the par downloaded.
Continue to use “delete by parid” but singletons can only trigger it when the repair engine returns “everything completed”.
- AutoPAR: Report that obscured rename doesn’t always work. The issue was naked MKV files not inside RARS. Without PARS was working but naked files with PARs follow a different path.
Confirmed “nodecode sets” were disabling obscured rename.
- Download: On restart and detecting existing downloads, the files aren’t listed as completed in the download list. So sonarr progress doesn’t go up correctly.
- NZBAutoload: When no paths are set in autoload, it’s not pulling the default unrar path.
No repro current beta
- Display: NZB files feed direct to download don’t show files sizes till they resolve.
- Display: Hitting enter in security options tab blanks the window.
- Search: Report that “mark old” in search tab doesn’t stick.
Works now.
- Base: Latest version of Sqlite and SSL library
- Base: Added the logging folder to the automatic purge routine.
Will purge files based on normal purge interval
Updated unit tests for testing this.
- Base: Report that autoshutdown couldn't be aborted.
No repro
- Base: Reports that adding txt posts doesn't create posts with TXT extension on disk
No Repro.
Did notice that incomplete files don't leave TXT files.

[Stan]

Fixes a nasty bug in B3 where split apart files covered by a PAR could be removed from the download list.


- Search: Report that “mark old” in search tab doesn’t stick.
Works now.

It might work there not sure but for some reason in doing watch lists searching from Internet the mark old is not working again. There was a beta that did and I hope to try the older ones like b2 or b3 to see.
I had issues before and always had to go back to 6.80 for it to work. I looked again, and it doesn't even update the database file, last update on the file was 2/2.
I re-downloaded b3 not sure, I can find the other betas will keep looking and if I find which one worked I will update.

NOPE tried b2,b3 and b4 I could have sworn it was working in one of the new betas maybe b1 which can't be downloaded. It doesn't save my sorting preference either and in the later b3 and b4 if you sort by status that don't seem to work like 6.80 or b2 either.
I added that to this because I get many incompletes while searching in watch lists from Internet, so I sort by status and either mark old or delete the incomplete.
There has been a setting show incompletes I tried turning on and off, but does not seem to help with that. It won't stay checked if turned on although then for sure it would show incompletes, but thinking maybe because it's shows as not checked it really is not reading the setting.

I know with the fact that once back to 6.80 the hide old works that it's not a permission issue on the files or antivirus etc ...

[Quade]

It fixes is for search but not for the watch lists. That's still on my todo list.

I'm probably going to put out a B5 to fix a rare crash then I'll look harder at the watch lists.

[Quade]

I was just testing this and found a surprising number of incompletes too. I'll see what I can figure out.

[Stan]

Thanks for looking into the issues.

I maybe don't understand what the checkbox show incompletes does, if unchecking it doesn't hide them. Or I guess maybe it doesn't work for watch lists.
And like I said, if you check it, it does not stay checked. I don't see the option in 6.82.
I forgot to ask once I used 6.9 and 6.91 what the option should do.
In the end it did not matter, when using 6.82 I just mark the incomplete old, and then it would hide them.

I know there are priorities on certain issues like if it is crashing etc ...
In the past it seemed, at times, it did it to me if I changed or edited the newsservers which gladly now I don't need to do much.

I like that we can have 2 versions, I have 6.82, and then I have the 69 which I update to the betas now.
I don't have the time I used to have to try different things with the program to see what issues may show up other than I do the watch lists and searches, although I do a few groups that don't have a large amount of headers and are not obfuscated.

[stavros]

Hi,
Just got a strange result trying to d/l a .7z file:

[02/16 21:45:35] DEBUG AutoPAR: Add File No PARID: <filename stuff here.7z>
[02/16 21:45:36] HIGH HFC: Obscured Rename Disabled - too many files <filename stuff here.7z> yEnc
[02/16 21:45:36] HIGH HFC: All decoded files have been rejected: Filename Filter

The file size is about 166 MB, I have autopar enabled, but did not get any failure message in Failed Files or Files List tabs and only the above messages in the Debug Log.

I disabled the autopar option and retried the d/l and NB allowed it.

On inspection, the file had a top level directory that was not encrypted, but contained 17 encrypted files. I do not know the password.

I'm sure that, in the past, I've seen entries appearing in the Failed List saying 'encrypted / no password'. Is this something new/different?

I can send an nzb of the post if helpful.

regards
Stavros

[Quade]

[02/16 21:45:35] DEBUG AutoPAR: Add File No PARID: <filename stuff here.7z>
[02/16 21:45:36] HIGH HFC: Obscured Rename Disabled - too many files <filename stuff here.7z> yEnc

Means is that if there are more than I think 4 files in the 7z set, Newsbin won't attempt to rename obscured files. The issue is some downloads like game ISO's contain files that look like they're obscured but it's the correct filename.

It doesn't prevent download or decoding.

[02/16 21:45:36] HIGH HFC: All decoded files have been rejected: Filename Filter

This is the real issue. You have a filter set that's filtering out all the filenames from the decoded 7z

Because of how 7z works, I can't do a partial decode of the 7z files which means I can't look inside the 7z at the encrypted RARs to detect they're encrypted.

[stavros]

Hi Quade,
thanks for the reply.

I had a look at the GoG and there were no filters set, but I found a header filter on one of the included groups in the GoG, so I cleared it.

I restarted NB and re-tried the d/l - same thing, so I disabled "delete Rars and Pars on successful UnRar" and tried again, same thing:

[02/17 20:27:58] DEBUG CNNTPDownloadDBEx:ReadFile: 1 Files Read for: <file name stuff.7z> yEnc
[02/17 20:28:02] DEBUG CheckFilename: Using Path:F:\DL\<file name stuff.7z>
[02/17 20:28:03] DEBUG RepairThread: New Filename to Process: <file name stuff.7z>
[02/17 20:28:03] DEBUG AutoPAR: Add File No PARID: <file name stuff.7z>
[02/17 20:28:03] HIGH HFC: Obscured Rename Disabled - too many files <file name stuff.7z> yEnc
[02/17 20:28:03] HIGH HFC: All decoded files have been rejected: Filename Filter

Only this time, the file was downloaded and left in the target download folder - the other times it had been deleted (not sure which side of the fence this scenario falls for definition of "successful UnRar").

I disabled the filters in use in the GoG subject header bar (green button - all filter fields greyed out) and tried again - same thing:

[02/17 20:43:18] DEBUG AutoPAR: Add File No PARID: <file name stuff.7z>
[02/17 20:43:18] HIGH HFC: Obscured Rename Disabled - too many files <file name stuff.7z> yEnc
[02/17 20:43:18] HIGH HFC: All decoded files have been rejected: Filename Filter

I can't see any other filter being used in the Group or GoG properties. Is there a default filter that might apply somewhere?

I very rarely muck about with filters so maybe something got set/amended a long time ago? Anywhere else I should look?

Is this a strange corner case - where the .7z has a top level directory that is NOT encrypted, but every file within that directoery IS encrypted and no password is available?
It is almost as if NB starts the decode because it can, then fails to decrypt any files and treats/reports that as a filename filter failure?

I looked inside the .7z, none of the directory & file names appeared 'obscured', they all had human meaningful names
(unless you mean that the file names were encrypted - 7zip showed a '-' in the encrypted column of the top level directory and a '+' for each file within the TLD).

regards
Stavros

[Quade]

I expect this is the "Post UnRAR" filter set in the AutoPAR options.

[stavros]

Hi Quade,

I checked the "Post UnRAR" filter, it is unset and I have never used it.

I checked the contents of the Global filter as well - it is empty too.

I sent an nzb of the problem.7z in case that is a help.

regards
Stavros