rtorrent freezed and werkt niet samen met rutorrent.

[Kain_niaK]

Ik ben sinds een maand nu met Linux gestart, en het gaat moeizaam.
Programma's installeren met scripts die ik op internet vind is allemaal geen probleem.
Maar zodra er iets gebeurd wat niet helemaal de bedoeling is zit ik vast.

Ik gebruik Ubuntu server 10.4 64bit.
Ik heb webmin geïnstalleerd en dat draait goed.
ftp server werkt.
Ik gebruik een light http server, doet het ook goed.
rtorrent heeft 3 weken gedraaid en rutorrent met de webgui deed het ook prima.
En toen moest ik wat torrents verwijderen en toen zei rutorrent dat rtorrent niet meer reageerde.
Ik heb uiteindelijk van mijn sessie map maar een backup gemaakt.
En toen met het script rtorrent en rutorrent opnieuw geïnstalleerd en geprobeerd om de torrents weer toe te voegen. Na het plaatsen van alle torrents terug in de map vanwaar uit rtorrent automatisch torrents start, zei de webgui weer dat er geen verbinding meer was.
Dus ik heb rtorrent opnieuw opgestart en geprobeerd op torrent per torrent terug te starten.
Als ik in het screen van rtorrent kijk dan staat er bij één torrent van 250 GB dat hij aan het hashen is.
Maar het scherm reageert niet en de webgui van rutorrent zegt opnieuw dat rtorrent niet reageerd.
Maar rtorrent gebruikt wel 70% van de cpu (dual core)
Dus ik heb via webmin rtorrent maar weer gekilled.
Hoe krijg ik dit weer in orde?
Ik heb lopen kloten in de config.php file van rutorrent en ook in de .rtorrent.rc file van rtorrent.
Ik krijg het gewoon niet meer werkende. Wie kan mij helpen?

[matthijsln]

rtorrent is single-threaded, wat betekent dat tijdens hashen e.d. het niet snel reageert op commando's (zie deze link). Ik had daar ook last van, alhoewel als je wat langer wacht je wel weer respons krijgt. Weet je dus zeker dat rtorrent wel vastgelopen is?

Ik vond dit trouwens zo irritant dat ik ipv rtorrent nu deluged gebruik. Met de gui van Deluge kan je een daemon remote besturen. Web interface zit er ook bij.

[Kain_niaK]

Ja, misschien is het dat.
Ik heb nu 250 torrent files lokaal staan.
En ik ben via FTP die één voor één in de watch map van rtorrent aan het zetten.
De kleinste bestanden eerst.
Tot nu toe opent hij ze vrij goed en binnen de minuut zijn ze weer aan het seeden.
Nu heb ik er in één keer 10 gelijk gekopieerd en nu hangt alles weer.
Ik zal het gewoon wat tijd moeten geven.

edit: En nu gaan de kleine files wel vlot. Ik heb er nu al 30 van onder de 1 GB terug aan de praat.
Ik kom er trouwens net achter dat ik vanuit de webgui rechstreeks bestanden kan openen die klaar zijn.

Is het trouwens mogelijk om van een ubuntu server videofiles te streamen naar alle mogelijke locaties?
Dan kan ik mijn eigen muziek en fimlpjes voortaan naar thuis streamen.
Ik ga eens kijken of ik daar de nodig info over vind.
In ieder geval lijkt alles terug te werken en zal ik voor het bestand van 250 GB gewoon veel geduld moeten hebben.

Ik heb wel check_hash terug op yes gezet.
Misschien was het dan rtorrent de hash niet controleerde en dan vast liep op een bestandfout of zo.

[ Voor 48% gewijzigd door Kain_niaK op 03-12-2011 14:09 ]

[matthijsln]

Wat ook in die link staat is dat je kan letten op wat 'top' weergeeft als cpu-percentage "wa" (io wait). Als dit erg hoog is betekent het dat de cpu uit zijn neus staat te vreten omdat het wacht totdat de schijft een lees- of schrijfactie heeft uitgevoerd. Een programma als rtorrent kan in die tijd niks doen om een gui of webinterface te updaten.

Ik vind het ontwerp van rtorrent hierom erg slecht. Niet alleen omdat het single- threaded is, want dat zou nog kunnen werken met async io. Maar het opent bestanden met mmap(), waardoor dat dus niet mogelijk is. Ik zou dus gewoon een betere client gebruiken zoals deluge

[Kain_niaK]

Ik heb deluge geprobeerd maar rtorrent is veel beter bij grote hoeveelheden torrent files.
Mijn CPU is maar een atom dus dat is niet zo heel erg veel soeps.
rtorrent mag misschien single threaded zijn op zich is dat niet erg zo blijft de server tenminste altijd nog responsive in het geval dat rtorrent 100% CPU tijd probeert te gebruiken.

[Jaap-Jan]

Als alternatief zou je ook nog transmission (transmission-daemon onder Ubuntu) kunnen proberen.

Daar is ook een gui voor Windows omheen gebouwd die wat lijkt op uTorrent (transmission-remote-gui).

[ Voor 35% gewijzigd door Jaap-Jan op 03-12-2011 14:24 ]

[CAPSLOCK2000]

Om op een Atom zoveel torrents te draaien lijkt rtorrent mij de beste keuze. Hashen kan inderdaad irritant lang duren, zeker op een langzamere CPU. Je zou eens kunnen proberen om rtorrent vanaf de console te draaien, dan kun je zien wat er gebeurt.

[Kain_niaK]

Ja, dat doe ik dus.
Zodra hij gaat hashen reageert rtorrent op niks anders meer, ook de console hangt vast terwijl hij wel gewoon aan het hashen is.
Bij die 250 GB grote torrent duurde dat blijkbaar een vol uur.
Maar alles is nu in orde.

[ Voor 5% gewijzigd door Kain_niaK op 05-12-2011 00:49 ]

[CAPSLOCK2000]

Eerlijk gezegd ben ik nog best onder de indruk. Zowel van de torrent (250G? en ik dacht dat ik veel downloade...) als van hoe snel het ding verwerkt is. Het ding heeft een uur lang (250G/3600s) = 70 MB/s staan hashen, niet verkeerd voor een Atom.