'/' is a special character in SABNZBDPLUS

[zerocarbthirty]

Hi,

I noticed an issue where nzbs sent to sabnzbdplus from SC++ were resulting in weird results so I posted an issue over on the sabnzbdplus GitHub. sabnzbd/sabnzbd#955

The result is that if you give sabnzbdplus an NZB file where the filename or title have a '/' sab will treat it as if it is protected with a password and everything after the '/' will be used as the password. This is a really unfortunate feature of SNP since most multipart binary sets use something like "[001/142]" in the title to denote how many parts of a message there is but they insist that this is an issue with how you are sending the NZB to them.

Please let me know if there is anyway for this to be resolved.

thanks.

[ppslim]

Whilst this is a common format for the originating sources as they appear in Usenet, the individual component files generally do not and quite possibly there is strong argument should not, appear this way in the index services that sabconnectplusplus is intended to provide helper functions on.

For example, sabnzbd would not normally be used to add part 001, 002, 003,... 141, 142 of 142 individually. Instead, the component parts are gathered into a collective nzb file and used to seed applications such as sabnzbd to download collectively and reconstruct into the original output (would could be one or more files, but collectively, they form the originally intended download).

You would not refer to this reconstructed format as part "all of 142".

So yes, I would agree with your original statement that that the '/' is a pretty common character. As per the sabnzbd logic, it is intended to be there for the purpose of automatic rar decryption.

However, here in lies the problem your are describing.

In indexers correctly make use of the '/' character, auto-decryption takes place. If sabconnectplusplus removes the '/' character intended to delimit the password, auto-decryption now fails.

As such, the extension should retain the '/' to allow support for its intended purpose, removing it limits this function.

This generally means, the indexer you are using should use the '/' character in the proper way. Without knowing which and supported by the details above, it's already quite clear it is not using it properly (as it's stating all 142 parts are in the 001 part filename, which simply isn't true).

I do however agree, that something may be possible here, as it's entirely possible that the extraction in the extension does have the correct name available to it, but is pulling the wrong data from within the indexer. A new match routine or correcting it may help.

To look into that, do you have a copy of the original page this appears on in which the link is being extracted?

The extension provide different matching implementations for different sites. Knowing which one is used and having the content to manually apply the match will be critical.

[zerocarbthirty]

It was just browsing a binary NG on nzbi.

…

On Jun 27, 2017 1:31 PM, "Phil R" ***@***.***> wrote: Whilst this is a common format for the originating sources as they appear in Usenet, the individual component files generally do not and quite possibly there is strong argument should not, appear this way in the index services that sabconnectplusplus is intended to provide helper functions on. For example, sabnzbd would not normally be used to add part 001, 002, 003,... 141, 142 of 142 individually. Instead, the component parts are gathered into a collective nzb file and used to seed applications such as sabnzbd to download collectively and reconstruct into the original output (would could be one or more files, but collectively, they form the originally intended download). You would not refer to this reconstructed format as part "all of 142". So yes, I would agree with your original statement that that the '/' is a pretty common character. As per the sabnzbd logic, it is intended to be there for the purpose of automatic rar decryption. However, here in lies the problem your are describing. In indexers correctly make use of the '/' character, auto-decryption takes place. If sabconnectplusplus removes the '/' character intended to delimit the password, auto-decryption now fails. As such, the extension should retain the '/' to allow support for its intended purpose, removing it limits this function. This generally means, the indexer you are using should use the '/' character in the proper way. Without knowing which and supported by the details above, it's already quite clear it is not using it properly (as it's stating all 142 parts are in the 001 part filename, which simply isn't true). I do however agree, that something may be possible here, as it's entirely possible that the extraction in the extension does have the correct name available to it, but is pulling the wrong data from within the indexer. A new match routine or correcting it may help. To look into that, do you have a copy of the original page this appears on in which the link is being extracted? The extension provide different matching implementations for different sites. Knowing which one is used and having the content to manually apply the match will be critical. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#160 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AP5Wwp_2WJOverbtSJVAJfXvxmjzhu8aks5sITxkgaJpZM4OF-UV> .