Queue coruption

[wpmccormick]

I just got through a somewhat difficult to track down issue. The major symptom was that I was getting client browser "nzbget communication errors"; at first, it seemed like the comm errors were infrequent, in that I was able to see the queue. Then the errors became more frequent, though I could still see the queue. Then the client browser interface could connect, but there was no queue displayed; no top title/menu, but there was something on the footer (sorry I can't recall exactly), and the comm error message.

... skipping ahead to the "ah-ha" moment, I replaced the queue dir in the conf file with "newqueue", cause i suspected a queue issue, and the communication errors ceased and the interface then came up.

There's over 2100 queue files in my queue dir, and if it's of any use I zipped em up and attached them with a png extension.

[clinton-hall]

and you believe this is caused by nzbToMedia? or do you want to post this over at NZBGet forums?

[wpmccormick]

duh!

[clinton-hall]

So do you need anything over this side?

[wpmccormick]

Sure. I'm running nzbget+cp+sickrage+headphones on raspbian. Storage is on a WD Cloud raid 1. I started with running nzbget on the NAS device, but was unhappy how WD set things up. Now this issue is post-processing speed - e.g. moving from complete to movies; it's would be much faster if the PI could hand the the post-processing off to the NAS device. Do have any ideas? Recommendations?

Thanks,

Bill

[clinton-hall]

What was wrong with the way this is set up on WD NAS?

You could have NZBGet on the Pi and then SickBeard and CP on the NAS. In nzbToMedia you would set the remote folder options to have this process correctly on the NAS.

Otherwise mount the NAS volume in your Pi and do the downloading and postprocessing on the same drive.

[wpmccormick]

I started out running it on the WD NAS, as it is one of the apps that their system framework has included for install. But then I became disenchanted with how customized WD made their OS. For example, it wasn't obvious how to get nzbget to update, or install whatever else I might want. I think I was also concerned that it was having some impact on performance, but then found out that WD has some automatic process that like to scan the drive for new media files and build meta-data; that was the likely culprit. When I build my own NAS I'll run everything from that.

I'm already mounting the NAS shares on the PI. Post processing is just so much more efficient when run locally from the NAS. If the PI does it, it's actually flooding the network with transactions, even though the files aren't being physically moved from the drive.

I don't really care to mess with the WD setup beyond the framework they offer; afraid to mess up my only NAS.

Cheers.

[clinton-hall]

The reason I asked is that I maintain the NZBGet app for WD.

However, I only provide bug fixes and update for each stable release oh NZBGet. It then goes through WD testing so I don't know how long it is until update.