RT* = RTorrent + RTWI aztán RT73

 ( hajbazer | 2009. január 5., hétfő - 23:22 )

Egyre több probléma kísért mostanában csak azért, hogy még véletlenül se érezhessem úgy, hogy ura vagyok a helyzetnek. Valaki nagyon nem akarja, hogy magabiztos informatikus legyek. Régebben úgy volt, hogy akármennyire is hülye problémával kerültem szembe - amikkel mások sohasem, hiszen csak engem szivat az élet - mindig megtudtam valahogy oldani, a "kötelező szarakodási időt" természetesen le kellett húznom, hogy minél jobban életemtől megkeseredett legyek. Mára ez már a multé. Idegeskedhetek napokig, csak arra jövök rá a végére, hogy minden hiába. Néhány megtörtént eset...

RTorrent + RTWI

Nemrég csináltam rTorrent + RTWI (RTorrent Web Interface) kombót. rTorrent a letöltéshez, RTWI a webes eléréshez és irányításhoz. Az rTorrent BitGate-es torrentektől kifekszik, méghozzá segfaulttal, ami a legeslegszörnyűbb látvány, amit egy alacsonyszintű programozáshoz nem értő és forráskódot nem átlátó rendszergazda-növendék megpillanthat. A konzolra kihány nekem egy stacktrace-t, amiből annyit tudok megállapítani, hogy az xmlrpc-c (az RTWI-vel való összekapcsoláshoz szükséges library) okozott végzetes hibát. Mit tesz ilyenkor a magamfajta ember - újratelepíti az xmlrpc-c-t, azaz újraforgatja a legfrissebb verzióra. Természetesen nem változik semmi, ugyanúgy elszáll és ugyanoda mutat a stacktrace. Mit tesz a magamfajta? Újratelepíti az rTorrent-et is, ebből is a legfrissebbet forgatja. Ekkor már tesztfázisig el sem juthat a dolog, hiszen az RTWI-nek túl új az rTorrent és mindenféle figyelmeztetéseket ír + nem hajlandó berakni a torrenteket letöltésre hozzáadáskor, hiába van bepipálva az erről szóló jelölőnégyzet. Ilyenkor szoktam összeomlani idegileg és feltenni a költői kérdést: Miért kell minden újat elrontani?
Miért nem tudják az rTorrent és az XMLRPC-C fejlesztői úgy megcsinálni a programjaikat, hogy azt egy régebbi kód is tudja gond nélkül használni. A legviccesebb az volt, hogy még vissza is jött egy régi hiba, ahogy a legújabb XMLRPC-C headerfájljaival forgattam az rTorrentet: 2GB-nál nagyobb fájloknál átfordult a signed int és mínuszban jelenítette meg a letöltött/feltöltött fájl méretét (persze még véletlenül sem az eredeti mérete volt, hanem zagyvaság). Máig nem találtam megoldást.

Stacktrace

Caught Segmentation fault, dumping stack:
0 rtorrent [0x43b050]
1 rtorrent [0x43f3e2]
2 /lib/libc.so.6 [0x7f27852ce100]
3 /usr/local/lib/libxmlrpc.so.3(xmlrpc_abort_if_array_bad+0x5b) [0x7f27863d12fb]
4 /usr/local/lib/libxmlrpc.so.3(xmlrpc_destroyArrayContents+0x33) [0x7f27863d1353]

RaLink Access Point mód szopás

A következő a WiFi problémája. A RaLink chipsetes, 3000 Ft-ért vett USB-s WiFi adapterem gyártójának a Windows-os driver-ébe még futotta implementálni az access point módot, de az alternatívak közösségének, esetlegesen akik Linuxot vagy valamilyen UNIX-ot használnak, és nem Windows-ból szeretnének hozzáférési pontot csinálni, na azoknak már nem jutott ki a jóból. Emellett még a nagy OpenSource zsenik, akik külön projekt keretében fejlesztik a legacy RT73-at, illetve az RT2X00-t (az rt2x00.serialmonkey.com közössége által fejlesztett RaLink chipset driverek kódnevei) sem tudtak megoldást találni arra, hogy az USB-s chipek (természetesen csak ezek, mert ez van nekem és csak nekem nem sikerülhet, a nem USB-sek működnek). Összeszámolva négy-öt nap folyamatos szopás áll mögöttem (persze nem egyszerre, mert azt már nem éltem volna túl - belefulladtam volna a keserűségbe) ezzel kapcsolatban. Kezdődött azzal, hogy leírták a fórumba: az RT73 legacy driverek nem támogatják (és nem is fogják támogatni) az AP módot, helyette tegyük fel a RT2X00-t, amihez persze a legújabb, legszuperebb legfrissebb kernel kell, mert csak abban van git, amit ők is használnak a fejlesztésre. Érdekes, eddig jó volt a 2.4.36-os kernel, most meg rögtön 2.6.28-rc5-re (ez volt a git-ben) frissítsek, egyetlenegy driver miatt. Sebaj, gondoltam kipróbálom a 2.6-os kernelt. Először még csak a sima kernel.org-os változatot raktam fel, reménykedve abban, hogy már belefoglalták az RT2X00-t. Fél napig tartott, melyből két és fél óra volt lefordítani, ami legalább háromszor annyi idő, mint a 2.4-es. Pedig eltöltöttem fél órát a konfigolásával, hogy tényleg csak az kerüljön bele (még modulként is), amire feltétlenül szükség van. Természetesen alapdolog volt, hogy bejött néhány dolog, ami istenadta figyelmetlenségemből adódóan arra kényszerített, hogy a kernelt újrafordítsam (ezért lett fél nap). Az is alapdolog volt teljesen természetesen, hogy néhány régi dolog nem működött megfelelően:

  • Az fbset nevű program, amivel a Linux Framebuffer-rel támogatott konzolját lehet állítgatni (felbontás, színmélység, stb.), már csak aktív ablakban volt hajlandó állítani a dolgokat. Ha elindítottam egy programot a tty2-n és én a tty1-en voltam, akkor az aktív terminálon, a tty1-en váltotta át a felbontást, szóval a szkriptjeimbe, amik kényelmi szolgáltatásokat indítottak bizonyos tty-ken, bele kellett még írni: chvt ..., de még azt is, hogy váltsa vissza arra, ahol volt.
  • A bootolás csigalassú volt ahhoz képest, ami volt és amikor a megfelelő betűtípusokat beállította, szinte majdnem egy másodperc telt el az egyes virtuális terminálok között, ahogy végigment rajtuk, holott a 2.4 egyszerűen ledarálta.
  • További fél óráig tartott rájönnöm, miért nem működnek rendesen az új kernellel a konzolos, magyarékezetes betűk, mire egy fórumon benyögték, hogy a 2.6-os kernel alapból UTF8 karakterszetten kezeli a konzolokat és indítóparaméternek kell megadni, hogy ne így legyen.

Az első két probléma láttán ismét feltettem a kérdést: Miért kell minden újat elrontani?
Pozitívumára legyen ennek a kernelnek, hogy X alatt az mplayer TV lejátszása folyamatosabb képet ad, mint 2.4-ből (bár többet is eszik a CPU-ból 3-4%-kal).

Így lett hát git-es kernelem. Ebben már benne volt, amit kerestem, de AP módot nem tudott és mikor sikerült beconfigolnom a hostapd-t, akkor derült ki, hogy semmi értelme nem volt az egésznek, mivel még ők sem tudják hogyan lehetne az USB-s chipekből AP-t csinálni Linuxon.

Ez a legfelháborítóbb! Nem, nem számít, hogy tudja a hardver. A sok kis Linuxos, aki nagyobb méretekben szeretne AP-t csinálni (nem kicsiben, mint a Windows-os), majd szépen megveszi pluszpénzért (a semmiért, a lófaszért, a fogyasztói rothadvány társadalomnak nevezett birkacsorda fenntartásáért) azt, ami szintén tudja és már driver is van rá, holott az előző termék is tudja, csak arra már nem fejlesztenek és nem is segítenek másoknak a fejlesztésben, nehogy véletlenül ne vegyék meg azt, amire valójában nem is lenne szükségük, csakhogy tömögethessék a zsebüket. Újat nem tudnak kitalálni, ezért inkább elbaszajtják a régit, aztán a nem elbaszottat adják el újként. Hogy én mennyire gyűlölöm ezt a világot, uramisten.

Összesítve tehát meg kell ismételnem, hogy négy-öt napig tartott mindez. Semmi értelme nem volt az ég világon, mert ahogy elnézem ebből már nem is lesz USB-s WiFi access point.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hibákat jelezted a fejlesztőknek, vagy csak magadban sápítozol?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Az rTorrent hibát teljesen feleslegesnek tartom jelezni, ugyanis a legújabb verzióban (0.8.4) a hiba már nem jelentkezik. Ezt azonban a fent írt okokból (RTWI nem szereti) sajnos nem fogom felrakni, kénytelen vagyok 0.8.3-at használni. Erre "sápítoztam", hogy miért kell minden újat elrontani, illetve még véletlenül sem kompatíbilis semmi visszafelé.

A RaLink access point dolgokat pedig megírtam nagyon szépen részletesen a fórumjukra (stringZ), kattintgass a linkekre, amiket kiemeltem a postban.

Nekem megy minden xmlrpc ami jo volt a 0.8.3 verzioval a 0.8.4 rtorrentel is. Milyen hivasokon hasal el az rtwi?

---
Apple iMac 20"
áéíóöőúüű

Így hasal el:

Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: Input is not proper UTF-8, indicate encoding ! Bytes: 0XE9 0X72 0X64 0X65 in Entity, line: 1 in /var/www/rtwi/classes/xmlrpc_handler.inc.php on line 137

a hiba meg a 0.8.4-es verzioban is el, csak szerencsere a bitgate-nel kivettek az ekezetet a tracker uzenetbol (az egyikbol, azota mar csinaltak masik ekezetes uzenetet is...)
a gondot az okozza, hogy nem utf-8 kodolassal kuldik a tracker uzenetet, s mikor ezt megprobalja valami xmlrpc-n keresztul lekerni az rTorrent-tol, az belehal
itt talalhato egy patch hozza (a nem utf karaktereket lecsereli ?-re, ha jol ertem), nalam mukodni latszik minden egyeb okozott gond nelkul

a masik, hogy az emlitett hibat, amin a 0.8.4-es rTorrent-nel elhasal az rTWi, azt meg tudnad mondani picit pontosabban, hogy milyen korulmenyek kozt fordul elo?
mert joideje 0.8.4-es rTorrent-et hasznalok 0.3.2-es rTWi-vel, s meg hasonloval nem sikerult talalkoznom

Nekem nem fekszik ki a BitGate torrentektol... Verzio: rTorrent 0.8.4/0.12.4. mikori a libcurlod? ha az ocska akkor elszallhat. A 2 giganal nagyobb filemeret nekem sosem ment xmlrpc feluletrol... igy kezdetek ota azt hasznalom hogy chunkok darabszama * chunkok meretevel. Nekem bevallt. UIbol meg joforman 1ik sem jott le, igy a nekem kello minimal funkciokra irtam egy sajatot.

---
Apple iMac 20"
áéíóöőúüű

az 4Gnagyobb kijelzes csak az ujabb xmlrpcben megy.

nekem amugy ilyen van (es nincs elhasalas):

ii  libtorrent11                                   0.12.2-0ubuntu1.1                   a C++ BitTorrent library
ii  libxmlrpc-c3                                   1.15.6-1                            A lightweight RPC library based on XML and H
ii  rtorrent                                       0.8.2-0ubuntu1.1                    ncurses BitTorrent client based on LibTorren

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A 2.4-2.6 atallas nagyon nagy odafigyelest kivan, es regebbi gepeknel nem is feltetlen ajanlott. Attol fugg, mi a gep, hardverek, ilyesmi. Az fbset fura, nekem vegigdaralja az ilyesmi beallitasokat meg regi gepen is. Az UTF8 nem veletlen lett default, az opensource vilag mindenutt elment arrafele, hogy ez legyen a default, es ez nem olyan rossz dolog. Persze, at kell allni mindenutt utf-re, de ez van.
A Ralink sosem a kernel tamogatasarol volt hires, sajnalatos modon van sok ilyen paraszt gyarto, nincs mit tenni, le kell nyelni a bekat. Probalj meg valami intel chipes akarmicsodat beszerezni, az biztos jol le van kezelve. Kerdes, h az intel gyart-e nem-alaplapi wireless stuffokat is.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Egy emberke összehozott egy ilyet rtorrenthez C++ es Qt 4.4.3 segitségével (win ala, de mivel platformfuggetlen erdemesnek talaltam megemliteni. Qt 4.3.3-al is lefordult Fedora 9-en.):

forrás fileok
windows csomagok

vagy repobol: svn checkout http://rwin.googlecode.com/svn/trunk/ rwin-read-only

Forditása alabbiak kozremukodesevvel tortenik:

Qt + mingw(gcc):
qmake
make

Remelem tetszik.

Valami jó GUI-t tudtok az RTorrenthez? Az alap RTorrent sem rossz, de pl. nem lehet keresni a torrentek között, szétválogatni tracker-enként, stb. A többi kliens pedig eléggé viszi az erőforrást, talán a Deluge olyan még, hogy a GUI-nak nem kell futnia mindig, hanem egy daemon intézi a letöltéseket, ami nem rossz, csak még így is kell memória szépen.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."