search

linuxserver / docker-nzbget

GNU General Public License v3.0
144 stars 84 forks source link

ls70 -> ls71. server crashes upon receiving certain nzb from sonarr/radarr #131

Closed SeeThruHead closed 3 years ago

SeeThruHead commented 3 years ago

linuxserver.io

Expected Behavior

NZBGet should not crash when receiving nzb from sonarr/radarr

Current Behavior

crashes on certain nzb where it didnt crash before (ls70)

Steps to Reproduce

file.name try sending this NZB from sonarr to nzbget post ls70

Environment

OS: CPU architecture: x86_64/arm32/arm64 How docker service was installed: unraid 6.9.2 docker installed via docker add container

I added a ticket over on NZBget github https://github.com/nzbget/nzbget/issues/744

But it looks like ls70 -> ls71 was actually a change in alpine on this side? that seems a likely culprit

in ls70 i get back a proper error via the nzbget server: name cannot begin with the '6' character, hexadecimal value 0x36. Line 8, position 68

and the server does not crash

is any container post ls70, the nzbget server crashes and will no longer accept requests from sonarr/radarr for nzb

there is a bit more detail over in that ticket. but seems to me as tho an error that was previously caught is no longer caught.

thank you for your time and help

looks as tho this is still happening on ls70

ErrorWarningSystemArrayLogin

Removed due to file names.
github-actions[bot] commented 3 years ago

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

j0nnymoe commented 3 years ago

We are unable to replicate this issue, and will not attempt to, as this requires us to download copyrighted material. Original post edited.

nemchik commented 3 years ago

Ref: https://github.com/nzbget/nzbget/issues/744#issuecomment-819500008

throwaway481 commented 3 years ago

@j0nnymoe this is probably caused by https://github.com/nzbget/nzbget/pull/745 . There is also a legal and corrupt example nzb there to reproduce.

nemchik commented 3 years ago

@j0nnymoe this is probably caused by nzbget/nzbget#745 . There is also a legal and corrupt example nzb there to reproduce.

Thanks for looking into that. It seems like this would be best handled by nzbget applying your fix (or some alternative to handle it accordingly). Since this doesn't seem to be an issue with the container itself (it seems to be an issue with malformed nzbs, and nzbget not handling them well) I don't think there is a need for us to adjust the container.