Torrent server

[errikos]

It must be something regarding the fact that Ethernet shares the same bus with the USB ports, or something... I 'm really not sure... The weird thing it that it happens also when downloading torrents to the sd card...

[guisacouto]

It is related to the usb bus. basically the bus is probably getting drained and it somehow provokes the kernel panic.

this happens with the sd card too but my guess is with higher download speeds, that in the end will also drain the bus, because in this case it is only used by the Ethernet or wifi (so you should probably need the double of the speed to cause this).

A possible workaround would be to have some load balancer in the driver to limit the usage per 'client'/device. if the bus limit is x and there is only one device, that device would be able to use x; as soon as a second one is connected, x should be divided by 2 and so on. this would avoid competition for using the bus..it would definitely be slower and not optimized but should work.. the problem? i have 0 experience writing drivers LOL

[purg]

from my first post I moved the swap to an external drive, tested by downloading the rpi torrents also a 700mb xvid leaving them to down/up at max speed (3Mb dsl isnt that good).

this is far fro ma fixed as the box crashed over night but today transmission still running after 6hours of download ans sharing, so a move in the right direction with a 256Mb swap on external hdd. I sure hope this is fixed by someone as the RPI was ment to replace an old 4x smaller NAS (transmission worked on).

[guisacouto]

With a 3Mb connection it should be fine I guess.. I've tried limiting my download speed at 900KB/s but it still crashes.

Limiting at 500 or less might be a temporary solution, but since I have a 50Mb connection (I can download at ~6MB/S), don't know if it is worth leaving the pi doing torrent work, because in my desktop I can download 12x faster.

I don't see much info about this issue around github, or the forums, except from people complaining about the kernel panic. I hope there are some experience users trying to solve this so the pi can get to it's limits:)

[mrlinux2u]

Hi,

Has transmission running for the last week or so without any issues and I'm sharing files via samba running off the 19/04/2012 debian distro.

However, until I replaced the kernel with the one from http://www.raspberrypi.org/phpBB3/viewt ... 2&start=25 I had major issues (USB lockups etc). With this kernel everythings been rock solid streaming videos to openELEC and vlc.

hope this helps.

cheers

mrlinux2u

[guisacouto]

My kernel is updated so it should work.. or does this kernel has something that the ones in the repois and github don't have?

[mrlinux2u]

@guisacouto

Don't know what the kernel has different (IPV6 I think), but it's around 100k small than the updated kernel I was using.

Another thing with it, I don't need a swap file (never ran out of memory running torrents,ssh,samba).

Hope that helps a little.

cheers

[guisacouto]

I don't think that kernel is any different from an updated one from the raspberrypi@github. Anyway, I tried to use it, but my wifi doesn't work with it, so it doesn't fit my needs.

best regards!

[fernan13malaga]

I had the same kernel panic.
Now, i'm running the new Weezy minimal (http://www.raspberrypi.org/phpBB3/viewt ... =50&t=7400)

Now, still working from 24 hours with heavy load (usb+lan) and no issues. Working with samba and transmission daemon.
All my downloads are downloading into the external hdd. No X needed for me.

Hope this help, sorry for my bad english.

[jerhat]

As suggested by fernan13malaga I tried the Raspbian from here: http://www.linuxsystems.it/2012/06/rasp ... mal-image/ still the same issue. The workaround for the kernel bug the author (darkbasic) is talking about is actually "only" the vm.min_free_kbytes parameter from sysctl.conf which we know does not solve the problem.

Also tried to use a kernel I built from a git pull yesterday, no luck.

For the reference, this bug is also discussed on github here (I think): https://github.com/raspberrypi/firmware/issues/9

Finding a patch for this is way beyond my capabilities but I would be glad if I can help in whatever way...

[guisacouto]

@jerhat

Tks for your feedback, you save me some time in testing those options.

I've been googling for weeks to try find a solution, and nothing seems to help... really frustrating.
Unfortunately I don't see much activity in trying to solve this issue, that in my opinion I consider very urgent, since the rest is working pretty well for the stage of the project.. I've tested 1080p and it works great, the sound works too, and so on.

I hope someone finds a way to work this out:)

[gr3ener]

I joined specifically to post in this thread, as it's unfortunate none of you know of a couple gems that will greatly enhance your use of rtorrent (which btw is an amazing program)

First, is ruTorrent (https://code.google.com/p/rutorrent/). It's a web interface for rTorrent and does absolutely everything you could ever want. It will require you to have Apache.

Now in response to RSS downloaders, the majority of trackers (torrent sites) I am a member of all announce the new release on an IRC channel. There's a plugin for rTorrent called autodl-irssi (http://code.google.com/p/rutorrent/wiki ... utodlirssi). What it does is monitor the tracker's announce IRC channel, and when a user uploads a torrent, before it hits RSS it is announce in IRC. autodl-irssi will match the release to your filters and snatch it up. Many minutes before your RSS feed catches it.

[fernan13malaga]

As suggested by fernan13malaga I tried the Raspbian from here: http://www.linuxsystems.it/2012/06/rasp ... mal-image/ still the same issue. The workaround for the kernel bug the author (darkbasic) is talking about is actually "only" the vm.min_free_kbytes parameter from sysctl.conf which we know does not solve the problem.

Also tried to use a kernel I built from a git pull yesterday, no luck.

For the reference, this bug is also discussed on github here (I think): https://github.com/raspberrypi/firmware/issues/9

Finding a patch for this is way beyond my capabilities but I would be glad if I can help in whatever way...

I don't know exactly what's the problem but, my rpi continue working since the reinstall this image without any kernel panic. I was copying around 400GB of data to an external hdd, attached to the rpi via lan cable, downloading with transmission and access to the files via samba to view some movies. No problem or lag found. I am very happy about this, because this is everything that i need with my rpi.

My configuration is this:

- 1A power supply.
- 500Gb hdd (3,5') attached to the usb.
- Network via LAN cable.
- Wireless USB keyboard + mouse.
- 2GB microSD with adapter
- Debian image: http://files2.linuxsystems.it/raspbian_ ... 608.img.7z

[jerhat]

I tried another sd card... same issue.
I cannot believe we are only 1 or 2 people facing this...

For me, reproducing the issue is as easy as:
- write a brand new image to the sd
- apt-get install transmission-daemon transmission-remote-cli
- start downloading a torrent
- wait for 2 to 5mn

All the PSUs, USB cables, SD cards, OS images, configurations I could possibly think of have been tried without success... Wait!, I didn't try to change the ethernet cable, will try tonite and let you know. I doubt it but I'm so hopeless now that everything is worth a try...

[jerhat]

Same freeze with a black box 3m ethernet cable, must be something else...

[Kilamite]

I'm also having the same problem.

Using only a 16GB SD card and ethernet. Transmission will work fine for 5-10 minutes, then the daemon will stop. Restarting the daemon, it'll work fine again then stop.

I've managed to download a 1.5GB torrent through about 4 daemon stop/starts. I SFTP'd to the Pi and was able to copy the file from Pi without hiccups.

Also, copying a 1.5GB to the Pi using SFTP works fine.

Might try rtorrent and see how that gets on.

[declutter]

I've also found that running transmission-daemon with multiple torrents being downloaded onto an external usb hard drive causes the raspberry pi to crash. If it's useful:

- limiting the download speed to ~500k still causes transmission-daemon to crash after a few minutes, but the raspberry pi keeps going
- limiting the downloading to one torrent at a time, with unlimited download speed, seems to be working OK so far.

[Kilamite]

limiting the downloading to one torrent at a time, with unlimited download speed, seems to be working OK so far.

Mine will crash even with one download going after 5-15 minutes (not sure why timeframe varies).

[Caótico Fanegas]

I've tried limiting the number of connections to a ridiculously low amount for a torrent client, just 50. It kept working for a fairly long time, about 45 minutes, and then panicked.

I'm using:

• Headless Raspberry Model B.

• sshd for remote access.

• Debian wheezy with patched kernel (supposedly to fix this issue): http://www.linuxsystems.it/2012/06/debi ... mal-image/

• External powered USB disk for downloading and downloaded torrents

• Transmission-daemon client through web interface

• samba for LAN file sharing

Let's see if we can find a way to fix this. I'm trying to compile as many fully working torrent box specifications as possible, so I can fin'd out what's the key on all this. If you managed to make your box work, please post a brief specification of your system, as well as the changes you had to make it work on this thread: http://www.raspberrypi.org/phpBB3/viewt ... =26&t=8497

[fernan13malaga]

I don't understand...

Mine, contunues working without any problem, without any download limit and with an attached usb hdd.

How can I help you, i've only installed samba an transmission-daemon (with dependecies), edit with nano both config files and... ¡ !

Try tochange de owner/group of your external hdd folder to debian-transmission.

I think this is not the problem because that fail gives you an "acces denied" writing the folder, but...

How can i clone my sd for share with you??

----------------------------
EDIT
----------------------------

HDD formatted as EXT4 and mounted at startup via rc.local

[guisacouto]

@fernan13malaga

If you don't mind, please leave your /etc/sysctl.conf, /boot/cmdline.txt, and settings.json from transmission content here to see what differs from ours.

I'm also using an external hd with ext4.

Best regards

[Caótico Fanegas]

No luck with Raspbian either. I've loaded 5 torrents/magnets and it went down just as with debian with tweaked kernel.

The only difference i've found with your method, is that I mounted my external HD through fstab instead of rc.local. May it make any difference?

[root_me]

Has any one tried bonding the usb and ethernet? I did read the reason why the network adapter is only 10/100 is because its shared with the usb. This could cause an issue because of the upstream and if the kernal has to monitor usb mounts. What does dmesg say when you get this problem with the torrent download?

[fernan13malaga]

@fernan13malaga

If you don't mind, please leave your /etc/sysctl.conf, /boot/cmdline.txt, and settings.json from transmission content here to see what differs from ours.

I'm also using an external hd with ext4.

Best regards

sysctl.conf:
Everything with # and below...

Code: Select all

vm.min_free_kbytes = 8192

cmdline.txt:

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

Settings.json:

Code: Select all

{
    "alt-speed-down": 50, 
    "alt-speed-enabled": false, 
    "alt-speed-time-begin": 540, 
    "alt-speed-time-day": 127, 
    "alt-speed-time-enabled": false, 
    "alt-speed-time-end": 1020, 
    "alt-speed-up": 50, 
    "bind-address-ipv4": "0.0.0.0", 
    "bind-address-ipv6": "::", 
    "blocklist-enabled": false, 
    "blocklist-url": "http://www.example.com/blocklist", 
    "cache-size-mb": 4, 
    "dht-enabled": true, 
    "download-dir": "/media/Compartido/Intercambio", 
    "download-limit": 100, 
    "download-limit-enabled": 0, 
    "download-queue-enabled": true, 
    "download-queue-size": 5, 
    "encryption": 1, 
    "idle-seeding-limit": 30, 
    "idle-seeding-limit-enabled": false, 
    "incomplete-dir": "/media/Compartido/Intercambio/Incomplete", 
    "incomplete-dir-enabled": true, 
    "lpd-enabled": false, 
    "max-peers-global": 200, 
    "message-level": 2, 
    "peer-congestion-algorithm": "", 
    "peer-limit-global": 240, 
    "peer-limit-per-torrent": 60, 
    "peer-port": 51413, 
    "peer-port-random-high": 65535, 
    "peer-port-random-low": 49152, 
    "peer-port-random-on-start": false, 
    "peer-socket-tos": "default", 
    "pex-enabled": true, 
    "port-forwarding-enabled": false, 
    "preallocation": 1, 
    "prefetch-enabled": 1, 
    "queue-stalled-enabled": true, 
    "queue-stalled-minutes": 30, 
    "ratio-limit": 2, 
    "ratio-limit-enabled": false, 
    "rename-partial-files": true, 
    "rpc-authentication-required": true, 
    "rpc-bind-address": "0.0.0.0", 
    "rpc-enabled": true, 
    "rpc-password": "{90ebae168d4a9ae27577d9fef2fbcf0eab098d3735f2GuYj", 
    "rpc-port": 9091, 
    "rpc-url": "/transmission/", 
    "rpc-username": "fernando", 
    "rpc-whitelist": "127.0.0.1", 
    "rpc-whitelist-enabled": false, 
    "scrape-paused-torrents-enabled": true, 
    "script-torrent-done-enabled": false, 
    "script-torrent-done-filename": "", 
    "seed-queue-enabled": false, 
    "seed-queue-size": 10, 
    "speed-limit-down": 100, 
    "speed-limit-down-enabled": false, 
    "speed-limit-up": 100, 
    "speed-limit-up-enabled": false, 
    "start-added-torrents": true, 
    "trash-original-torrent-files": false, 
    "umask": 2, 
    "upload-limit": 100, 
    "upload-limit-enabled": 0, 
    "upload-slots-per-torrent": 14, 
    "utp-enabled": true
}

[guisacouto]

@fernan13malaga

Tks for your reply. You do have speed limit in your files, and that's probably why it keeps working.

transmission-daemon/settings.json

Code: Select all

...
"speed-limit-down": 100,
"speed-limit-down-enabled": false,
...

With only 100kb/s it should work ok.. Try setting that to 300 and that will be enough to get a kernel panic.

best regards