Version 0.6.7

Version 0.6.6 didn't exactly work either. Removing explicit ordering changed it to expected alphabetical ordering instead of any ordering.

Version 0.6.6

Version 0.6.5 didnt actually work as intended :)

Version 0.6.5

For large files (>35GB) the par2 process failed due to the fact too many parts had to be created.

The par2 process now keeps on trying larger part sizes to allevaiate this problem. (up till 10x a single message size)

The upper limit is now therefore around a 350GB file.

Version 0.6.4

Cleaned up the core nntpPoster.exe a bit. This is a direct method to access the usenet uploader without all the surrounding logic of watch folders, verification etc.

To call this just run:

nntpPoster.exe <path to file or folder>

This tool uses the same settings.config file with some reservations:

It is highly recommended to enable nzb file output. Since without this, you might never find your uploads again on usenet.

Since no watch folders are being used the watch folder settings with the short name of Default will be used. If this are not present the first available watch folder settings will be used.

The following settings are ignored and can be left blank/default:

ObfuscatedNotificationUrl
SearchUrl
IndexerRenameMapSource
IndexerRenameMapTarget
BackupFolder
MkvPropEditLocation
FFmpegLocation
RemoveAfterVerify
FilesystemCheckIntervalMillis
FilesystemCheckTesholdMinutes
AutoposterIntervalMillis
NotifierIntervalMinutes
VerifierIntervalMinutes
VerifySimilarityPercentageTreshold
RepostAfterMinutes
MaxRetryCount
DatabaseFile

Version 0.6.3

Fixed rar compression parameters so folders with folders in them work correctly.

Version 0.6.2

Added extra logging code in external process calls to exactly see what is being called.

Version 0.6.1

The posting retry loop covers more logic, this should hopefully prevent a hang on connection issues with the usenet server.

Added extra logic in the search method to replace certain characters when searching on the indexer. This is required when the indexer does its own modifications to post names.

For this new config settings have been added underneath the <SearchUrl> tag:

<!-- The indexer rename maps defines rules how the indexer itself renames uploaded items. Use this if verification fails because of too much difference between what was uploaded and what was found.-->
<!-- This map works as follows. Each character in Source is replaced by the corresponding character in target. If the character in target is identical it is removed entirely -->
<IndexerRenameMapSource>_@</IndexerRenameMapSource>
<IndexerRenameMapTarget> @</IndexerRenameMapTarget>

added a bugfix where an indexer double escapes ampersands on returning search values.

Version 0.6.0

This version adds the ability to apply passwords to the uploaded archive.

This can either be a fixed password or a randomly generated password (A GUID)

This is configured on a per watchfolder basis by adding the following new tags (or modifying them in the sample config)

<WatchFolderSettings>
    [..]
    <!-- Wether to apply a random password to the uploaded archive -->
    <ApplyRandomPassword>true</ApplyRandomPassword>
    <!-- Apply this fixed rar password to the uploaded archive
         If ApplyRandomPassword is set to true this takes precedence and this setting is ignored. -->
    <RarPassword>Test wachtwoord</RarPassword>
</WatchFolderSettings>

Take care that if you use the random password setting you would best also enable an nzb output folder. Otherwise the only way to know what password was applied to an archive is to look into the SQLite database.

Version 0.5.0

A new function was added to have files/folders moved to an uploadfailed folder when they fail to upload for 3 times (this is a parameter, so more or less retries can be specified)

When updating it is best to add the following two XML nodes to your existing config:

<!-- The maximum number of attempts a file will be reposted if it has an error. After this it goes to the postFailed folder -->
<MaxRepostCount>3</MaxRepostCount>
<!-- The folder to put failed uploads in -->
<PostFailedFolder>uploadfailed</PostFailedFolder>

If these are not present the default values of 3 retries will be used and the failed uploads will be placed in the uploadfailed subfolder relative to the application executable.

Additionally some small changes have been made to the logging so there is a bit more info present when doing file moves, or when an upload completes.

Version 0.4.2

Small bugfixes:

The api responses are checked for the text "<error code=" instead of just "error" this prevents fauly matches on files that actually contain the word error

The current working directory is once more set to the application folder on service startup.

The service shuts down after a clean stop command (pause) this is not exactly according to windows spec. But atm the easiest way to implement a clean shutdown while finishing the current upload.

edit: prior to 2015-10-9 22:09 the attached release zip file was not the correct build