9 minutes ago, binhex said:

so with that in mind im going to try including a arch linux build of unrar and symlink it in and see if that fixes it, are you up for testing this, as i currently do not have a usenet subscription so kinda need some help to find out if this resolves it.

It will take me a few days, maybe a week of running with a test version, as the issue is hard to replicate. Do you want to use a special tag so it's not the :latest? Maybe use :test again?

1 minute ago, jonathanm said:

It will take me a few days, maybe a week of running with a test version, as the issue is hard to replicate. Do you want to use a special tag so it's not the :latest? Maybe use :test again?

sure i will go with a test tag, thanks for testing jonathanm, i thought it was more frequent than that, i guess thats a good thing for you, not so good for me to try and fix it 🙂

1 minute ago, binhex said:

i thought it was more frequent than that

That's what is so maddening. It can work PERFECTLY for days, then sometimes it will hang several times in one day. Change some setting, think you fixed it, bang, it hangs. Change another setting, works great for a while, then it doesn't. Restarting the docker every hour ensures everything works smoothly, and I've never seen a restart munge a download, so it's a great solution if the real issue doesn't get handled. I've had mine on autorestart for several months now, time flies, it may be as much as a year.

ok one question for you @jonathanm to confirm the issue is unrar, not par right?, as in the unpacking of the completed rar files yeah?.

1 minute ago, binhex said:

ok one question for you @jonathanm to confirm the issue is unrar, not par right?, as in the unpacking of the completed rar files yeah?.

Honestly, I quit digging when I found out restarting solved my issue and didn't damage anything. I THINK it's the unpacking, but I can't be 100%. I suppose it could be the handoff between verifying / rebuilding par and unpacking.

11 minutes ago, jonathanm said:

Honestly, I quit digging when I found out restarting solved my issue and didn't damage anything. I THINK it's the unpacking, but I can't be 100%. I suppose it could be the handoff between verifying / rebuilding par and unpacking.

fair enough, for now lets start with unrar and see how we go, image built with tag 'test' please pull down and let me know how you get on, this includes stable unrar 5.60, im forcing nzbget to use this instead of the included statically built version by using option flag, and for sanity i have deleted the static version to prevent it being sneaky and trying to use that instead.

 

Edited May 31, 20197 yr by binhex

16 minutes ago, binhex said:

please pull down and let me know how you get on,

Pulled and running, restart script disabled, I'll let you know. As I said, it's hard to force the issue, so we'll see.

59 minutes ago, jonathanm said:

Pulled and running, restart script disabled, I'll let you know. As I said, it's hard to force the issue, so we'll see.

I've been on the previous version since the major unpack issue nobbled the latest, and it happens once in a blue moon at the unpack phase.  Hasn't happened in a while for me though, and restarting always fixes it.  Hadn't thought of scheduling a restart.

22 minutes ago, Cessquill said:

I've been on the previous version since the major unpack issue nobbled the latest, and it happens once in a blue moon at the unpack phase.  Hasn't happened in a while for me though, and restarting always fixes it.  Hadn't thought of scheduling a restart.

fancy trying the newly tagged 'test' image i have just produced?

23 minutes ago, Cessquill said:

Hadn't thought of scheduling a restart.

Dirt simple, hourly cron with docker restart binhex-nzbget

 

Hopefully it won't be necessary any more though.

While I've got everyone's attention, how do you find the nzbget version in the GUI? Settings about nzbget is useless for that purpose, system has an update button, but doesn't show the current version.

 

I'm lazy and don't feel like googling, anybody know off the top of their head? Or do I have to read the log file to get the version?

17 minutes ago, jonathanm said:

While I've got everyone's attention, how do you find the nzbget version in the GUI? Settings about nzbget is useless for that purpose, system has an update button, but doesn't show the current version.

 

I'm lazy and don't feel like googling, anybody know off the top of their head? Or do I have to read the log file to get the version?

Click on the NZB logo in the top left, I *think*

 

And yes, I've got a mover script running on CRON to stop my cache drive filling and taking out my dockers.  I can either combine the restart with that, or run a second one.

 

@binhex - no problems, yes.  Gives me something to do this weekend.

On 5/31/2019 at 8:28 AM, binhex said:

please pull down and let me know how you get on, this includes stable unrar 5.60,

Well, I pulled :test yesterday after you said it was built, but it's still using 5.7. Did I pull too early?

Well, I pulled :test yesterday after you said it was built, but it's still using 5.7. Did I pull too early?

I'm assuming you mean 5.7 unrar right? How are you identifying the version? exec?

Sent from my EML-L29 using Tapatalk

1 hour ago, binhex said:

I'm assuming you mean 5.7 unrar right? How are you identifying the version? exec?

Yep, docker exec

sh-5.0# unrar
UNRAR 5.70 freeware      Copyright (c) 1993-2019 Alexander Roshal
sh-5.0# which unrar
/usr/sbin/unrar

 

1 hour ago, jonathanm said:

Yep, docker exec

sh-5.0# unrar
UNRAR 5.70 freeware      Copyright (c) 1993-2019 Alexander Roshal
sh-5.0# which unrar
/usr/sbin/unrar

 

actually thats fine, 5.60 was the version i saw from the previous build when i was testing, so it will now be 5.70, im confident that is the arch linux packaged version and not the statically built binary included with nzbget, so i think we are good. have you seen nzbget unpack since you switched to the test tagged image?, i just want to know nzbget can find the unrar binary on the path (or vai the option i specified) and unpack ok.

1 hour ago, binhex said:

actually thats fine, 5.60 was the version i saw from the previous build when i was testing, so it will now be 5.70, im confident that is the arch linux packaged version and not the statically built binary included with nzbget, so i think we are good. have you seen nzbget unpack since you switched to the test tagged image?, i just want to know nzbget can find the unrar binary on the path (or vai the option i specified) and unpack ok.

Well, in that case it's not the unrar doing it, I got the same exact hang with the new container, which is why I started investigating. You said you included stable 5.6 in the test build, and when I saw 5.7 I assumed something didn't go right with the build.

Well, in that case it's not the unrar doing it, I got the same exact hang with the new container, which is why I started investigating. You said you included stable 5.6 in the test build, and when I saw 5.7 I assumed something didn't go right with the build.

Uggh ok that's not good news, thanks anyway, looks like it's back to the drawing board.

Sent from my EML-L29 using Tapatalk

Hello Gents,

 

Same issue here. Would be happy to help test any potential solutions. Restarting the container always seems to fix it. 

 

Thanks,

Hello quick question how do I deal with the Movie/Tvshow files sonarr does not pick up cus there named adsiuotfgiueaSGUFbwa is there a way to make it notice them

8 hours ago, MarkPla7z said:

Hello quick question how do I deal with the Movie/Tvshow files sonarr does not pick up cus there named adsiuotfgiueaSGUFbwa is there a way to make it notice them

Is this happening on all, or just a few? They should recognise that they're obfuscated and pick them up.  Sometimes they don't though (e.g., if they're nested within folders).  If the main file is within something like...

 

Title/folder1/folder2/media.mkv

 

...then move it into Title/media.mkv - after a while it should be picked up.  I've sometimes tried renaming it to be Title/Title.mkv.  Sometimes I give up and process it manually - it's only renaming, copying over and triggering a library rescan.

 

This is assuming that the file is OK.  Just a few thoughts, but if it's always happening, something else is wrong.

On 7/5/2019 at 9:07 AM, Cessquill said:

Is this happening on all, or just a few? They should recognise that they're obfuscated and pick them up.  Sometimes they don't though (e.g., if they're nested within folders).  If the main file is within something like...

 

Title/folder1/folder2/media.mkv

 

...then move it into Title/media.mkv - after a while it should be picked up.  I've sometimes tried renaming it to be Title/Title.mkv.  Sometimes I give up and process it manually - it's only renaming, copying over and triggering a library rescan.

 

This is assuming that the file is OK.  Just a few thoughts, but if it's always happening, something else is wrong.

yes it is exactlu the problem its always in a sub folder with jumbled letters and an MKV file it doesnt happen with anything else

Same issue with the unpacking problem here. I will pull all log files I can when it happens again to see if we can investigate further and more than happy to be a tester for any 'test' images. Really annoying problem more to the fact that it hangs the 1 core I have pinned to 100% usage. Keeps my CPU toasty for a long time until I notice the noise coming from my server. As everyone else restarting NZBget fixes the issue but so does cancelling Post Processing of the stuck download and simply telling NZBget to Post Process the same files again. 

 

Either option seems to temporarily fix the issue until after a while it comes back again. 

Edited July 8, 20196 yr by witalit

16 minutes ago, witalit said:

Really annoying problem

yeah tell me about it!, wish i could get to the bottom of it, i might be able to give it a bit more time end of this week and just try some rather extreme options and see what happens.

On 2/25/2019 at 10:21 PM, jonathanm said:

Since you are using deluge-vpn, there is no need for a second privoxy on your system. Just point all your http proxy settings through the existing deluge-vpn privoxy. If you are talking about sending the actual download traffic through the VPN, that's a different thing altogether.

 

If you are using SSL connections to your usenet servers, there is really no need for a VPN for usenet.

I would also like to use nzbget via VPN if that is somehow possible, meaning to do downloads trough vpn?

I found on internet that nzbget does not support proxy configuration, so perhaps it is possible to add it via docker itself, like some parameter or something?

I understand that it is not needed since ssl is used, but somehow I would feel much better, not even sure why...

Please enjoy a beer @binhex as a than you for another excellent container!