Support Forum

shypike's latest commit (a6a68b9b672c4d2abcb4ae0d4bffad4e74184e9f) reversing an older commit fixed this for me - thanks!

yes, it seems to be the very same problem. I too don't do cross file-system renames as you can see, and for me too, it only appeared a couple of commits ago.

I guess you can close this and track it in the other thread (perhaps give it a more sensible subject, though)

Hi all, since my latest git pull, I get after every download finishes the following error: Error renaming "/mnt/md3/Downloads/complete/_UNPACK_foldername" to "/mnt/md3/Downloads/complete/foldername" The debug log shows the following: 2014-02-28 09:32:01,442::ERROR::[postproc:403]...

Okay, results are in. Downloads finished around 4am, so SAB is idling since a couple of ours. According to top, it uses 40% of 2GB, so roughly 800MB of RAM. To make the story short, the heap dumps won't be of much help. This is what the dump looked like while downloading. I've picked one of the high...

absolutely It's purely cosmetic

I've added the guppy code (was a bit of a pain as there was no guppy-package for python2.7 in debian?! Had to compile it myself). Anyway, memory profiling is running and SAB should be busy for the night. I'll post the logs/findings in the morning

Would it help if I did those code modifications on my system and trigger this memory situation again or are you guys good? (could do it tomorrow-ish)

Debian wheezy amd64
Python 2.7.2-9 (debian wheezy package)
Sab 0.6.10

Yup, you're right. It was the oom-killer. The fact stands that SAB rather gets killed than giving up some of its allocated memory.

Okay, so I've thrown in a bunch of large downloads yesterday night and went to bed. This morning, things looked like this: http://final.skilled.ch/sab/sab_before_test.png It's currently roughly 9am, so SAB hasn't been doing anything for six hours. Console shows the following: http://final.skilled.ch...

I've sent the NZB that caused this issue

I don't have an issue with SAB using 1GB of memory while actually doing stuff, but "stockpiling" that memory seems like a bad approach, especially since there can be absolutely nothing meaningful in there once the queue is paused/empty and all yencs are decoded - or am I wrong? I will chec...

yes, works fine otherwise. I use Debian wheezy non-free unrar: Package: unrar New: yes State: installed Automatically installed: no Version: 1:4.0.3-1 Priority: optional Section: non-free/utils Maintainer: Martin Meredith <mez@debian.org> Uncompressed Size: 254 k Depends: libc6 (>= 2.2.5), libgcc1 (...

I only have 200MB Swap because my OS is on a 2GB USB Stick the OS is debian. Are you sure this couldn't be handled via code?

Seems that if a job contains more than 200 rar files, SAB displays the unpacking procedure wrongly.