Verification checklist

[Oleekae]

Firstly, thank you very much for reversing the option to add more than one server for uploading. I find the design to be polished and informative. I have done a few checks on v0.0.29-rc7 of those threads that I opened at the time. Everything tested has been positive, everything worked. Great work.

Resolved (confirmed / addressed):

✔Add favicon to Postie Web UI (browser tab icon)

✔Container healthcheck fails: wget not found (container runs but stays unhealthy)
Status: Resolved — the Docker healthcheck now uses curl (/live) and the container reports healthy.

✔rc7 fully compatible with previous configs
Status: Resolved — existing config loads correctly on rc7 in my DSM deployment (no setup wizard / config accepted).
Note: rc7 specifically added support for multiple upload providers with different backbones, which was the breaking change in rc6.

✔Postie version in Docker
Status: Resolved — running the latest Docker image successfully (version can be identified via image tag/digest + container is healthy).

✔Option to keep .par2 files (don’t delete after NZB creation)
Status: Resolved / closed upstream — tracked as issue #53 and marked Closed (milestone v0.0.29-rc4).

✔Add option to disable servers
Status: Resolved / fixed upstream — feature request #49 is Closed with label fixed (milestone v0.0.29-rc2).

Still pending test:

❔Creation of a single .nzb per folder
Status: Not tested yet (pending verification).

Once again, great work. Congratulations on developing a tool as effective as Postie for everyone.

[javi11]

Thanks for the checks please let me know if the folder nzb creation works

[Oleekae]

My working environment is always based on Docker on NAS.

The NZB folder creation process isn't working properly; let me explain:

Works if: For files stored in a single directory without subdirectories; it works, generating a single functional .nzb file

Not working >> When processing a directory containing X files and subfolders (2 in the test case), once processing is complete, it has generated two NZB files for the two subfolders, but the NZB file for the main folder is missing, even though the application shows it as having been created successfully. In fact, it is never there, either because it has been overwritten by one of the .nzb files from the subdirectories or because an error has occurred. This always happens with subdirectories to be processed within the main directory. For example, Dir: Sun.Moments (01.rar...78.rar) "Proof" dir and "Sample" dir always end up creating two .nzb files from the subdirectories, never from the root directory. I should also add that the time taken to complete the entire process is very long compared to nyuu. It is not effective if we want to use it in a production environment.

I'm adding a comment regarding the testing of this v0.0.29-rc7

Testing with:

• 22 directories with a total size of 1.38 TB (1,523,942,900,065 bytes), including the .par2 files created previously. Postie therefore had Par2 disabled.

It took more than two days to process just 4 of the 22 directories; in the end, I stopped the whole process and deleted everything. What did I notice? After a few hours, Postie would invariably crash the three servers I had set up. As I had to stop them because they would shut down – presumably due to the sheer overload caused by so many verification, re-verification and deferral parameters – I’d happily disable those settings if I could. In my case, I reckon all this ‘extra arsenal’ of parameters is causing my servers to crash. To fix this, I always had to stop the Docker service and restart it; then they’d automatically become functional again for a few hours before crashing once more. This didn’t happen with v0.0.29-rc5, or if it did, it was very sporadic. With this version, in my case, it’s systematic.

Well, in my case, I’ll go back to v0.0.29-rc5, which is the only one of these recent versions I can consider reasonably functional in a working environment with certain requirements.

Finally, on one occasion, the following Postie runtime error also appeared. You can see it in the screenshot.

[Oleekae]

I’ve installed the latest version, v0.0.29 (4f19c18). I’m afraid I haven’t been able to test it much because, just like the previous version, v0.0.29-rc7, as soon as I started processing a single 27GB folder, all three servers crashed within five minutes. It’s probably down to all those parameters you’ve added – I personally can’t see any benefit in them, as I already knew full well that it was propagating across all the backbones simply by having the standard recheck policy for article verification. Ever since this whole set of checks, re-checks, post-checks, etc. was added, the servers have been crashing constantly, and the only way to fix it is by manually shutting down and restarting the server. Even manually checking the server doesn’t resolve the error.

Take a look at the screenshot so there’s no confusion about what I’m talking about. The screenshot shows the new block that’s constantly disrupting the normal flow of the servers; these are the settings I’ve configured. Personally, I’d be happy if this could be disabled. And if it just disappeared, that would be even better.

https://imgbox.com/GyDmEfK8

In my current setup, I had three active servers for uploads and one server dedicated solely to checks. As you can see in the screenshot, all three went down after about five minutes.

https://imgbox.com/lTcp3TSN

As the servers keep crashing, I haven’t been able to carry out any further testing to check that all the changes and additions you’ve made are working properly – I’m sorry about that. Once the server issues are sorted out, I’ll be happy to test everything that’s still pending.

[javi11]

You can disable all of that by disable the article check, but can you share the log to see what is crashing

[Oleekae]

However, checking articles is absolutely essential to ensure they are uploaded correctly; what is, in my humble opinion, entirely unnecessary is the section you’ve added regarding the check. It is almost certainly the cause of the servers constantly crashing, as this problem has only occurred since this whole set of options was added.

Here’s the log; it’s basically the same throughout. I’ve edited some sensitive information, but the key details are all there.

https://pastebin.com/N28DscSA

[Oleekae]

I’ll add some more details. In the previous test, the ‘Single NZB Per Folder’ feature was always enabled. Systematically, after about five minutes, the processing of the articles stops and the servers go into idle mode.

OK, I’ve recreated the same task with the ‘Single NZB Per Folder’ option disabled, and now at least it’s processing the folder. At times during this process, all three configured servers go into idle mode, but they come back online on their own after a short while. It hasn’t finished processing the folder yet, but it looks – and I say ‘looks’ – as though the servers won’t crash.

Edited: the entire 27 GB directory has been processed without any errors occurring on the servers. Given that errors occur during processing when the ‘One NZB per folder’ option is enabled, it is possible that this is related to that setting.

I’ll leave it running for hours with this option disabled, processing multiple folders, and I’ll be able to get to the bottom of this issue. I’ll let you know the results. What’s clear is that with that option enabled, the processing of articles stops after just a few minutes.

[Oleekae]

OK, test complete: both options – ‘Single NZB Per Folder’ and ‘Create Par2’ – are disabled

Processing of 14 directories totalling 865 GB (929,002,756,233 bytes); all processed successfully, no server crashes.

This finding directly links the issue of server crashes to the enabled option of Single NZB Per Folder.

I will soon be testing the option to generate Par2 files alongside the 'Skip PAR2 Generation if Files Already Exist' setting on a set of mixed directories containing some previously created .par2 files and others where no such files exist. I’ll let you know the results.

[Oleekae]

Confirmed the 'Skip PAR2 Generation if Files Already Exist' function does not work; it recreates .par2 files even in folders that already contained them.

[Oleekae]

More testing and final checks on how the .par2 generation works.

• 26 directories with a total size of 1.55 TB (1,708,594,114,572 bytes) were processed with the .par2 generation feature disabled. Everything went perfectly.

• On the current Postie version, PAR2 generation fails when using the default/automatic mode (leaving ParPar Binary Path empty).

In that mode, .par2 creation fails consistently for very small files, and the upload cannot be processed correctly.

However, when I manually set ParPar Binary Path to an external ParPar binary, PAR2 generation works correctly and the folder is processed successfully.

So, in my case:

• Automatic/default PAR2 mode: fails
• Manual external parpar path: works correctly

The likely cause seems to be in the built-in/native PAR2 generation path used when ParPar Binary Path is empty. It appears to have trouble with very small files, while the external ParPar binary handles them correctly.

It may be worth reviewing the automatic/native PAR2 generation path, especially how it handles very small input files and slice/block size calculation.

And once again, I’ve confirmed that there’s a bug in the ‘Skip PAR2 Generation if Files Already Exist’ function. I’ve tested it again with the path to the parpar file set manually and does not work; it recreates .par2 files even in folders that already contained them.

As for the option to generate a single .nzb file per folder, I need to do a lot more testing, but it seems this feature still needs a lot of fine-tuning. I have now placed two directories, each containing some subdirectories, in the watch folder, and once the process for both directories has finished... I see a single .nzb file generated, which is surely the merge of the two directories, and the name generated is that of the watch folder, not that of the directory where the .nzb file is generated.

From all this, I conclude that the features causing Postie to crash are essentially the creation of .Par2 files using the new ‘automatic’ system. There is also a very noticeable bug in the ‘Skip PAR2 Generation if Files’ setting.

Keep up your top work!