[bugbear]

Idézet: Hippo - Dátum: 2007. febr. 7., szerda - 16:34

Másik kliensel próbáltad már?

Még nem de jó ötlet !

[Orgi]

Egy másik dolog (lehet ez feature mondjuk ), amit már korábbi verzióban is megfigyeltem: vannak emberek, akiktõl még fájllistát se tudok tölteni, azt mondja a bcdc, hogy a másik kliens nem támogatja teljes körûen a tth-t - letöltés nem lehetséges. A másik kliens vmi dcgui volt azt hiszem, ez gondolom vmi linuxos verzió.
Így viszont egyrészt nem tudok letölteni 2 giga ape zenét, ami egy embernek van meg összesen, másrészt meg még a letöltési listámból se tudom törölni, mert csontrafagy a bcdc
Mivel én nem kényszeríthetek mást, hogy milyen klienst használ (ráadásul a legnagyobb magyar audiophile hub egyik operátora), nem lehetne, hogy tth nélkül is lehessen letölteni (bár gondolom ez direkt lett kiszedve annó a sima dcbõl is).

[Hippo]

Idézet: bugbear - Dátum: 2007. febr. 7., szerda - 18:24

Még nem de jó ötlet !

Én egy jóideje ApexDC-t használok, ha gondolod próbáld ki. Nekem bevált.

[FleetCommand]

Idézet: Orgi - Dátum: 2007. febr. 7., szerda - 19:10

Egy másik dolog (lehet ez feature mondjuk ), amit már korábbi verzióban is megfigyeltem: vannak emberek, akiktõl még fájllistát se tudok tölteni, azt mondja a bcdc, hogy a másik kliens nem támogatja teljes körûen a tth-t - letöltés nem lehetséges. A másik kliens vmi dcgui volt azt hiszem, ez gondolom vmi linuxos verzió.
Így viszont egyrészt nem tudok letölteni 2 giga ape zenét, ami egy embernek van meg összesen, másrészt meg még a letöltési listámból se tudom törölni, mert csontrafagy a bcdc
Mivel én nem kényszeríthetek mást, hogy milyen klienst használ (ráadásul a legnagyobb magyar audiophile hub egyik operátora), nem lehetne, hogy tth nélkül is lehessen letölteni (bár gondolom ez direkt lett kiszedve annó a sima dcbõl is).

Igen, direkt lett kiszedve, így nem lehet TTH nélkül tölteni, és ez nem fog megváltozni Ennek az az egyszerû oka, hogy a letöltések biztonságát szeretnék garantálni, így csak teljeskorõ TTH-támogatással felszerelt kliensek tudnak egymástól tölteni a jövõben.

Ma már minden platformra elérhetõ olyan kliens, ami mûködik teljeskörúen, így Linuxra is (wxDCGUI névre hallgat a Valknut új változata, amit elsõsorban abból az apropóból kezdtek el újra fejleszteni, hogy az új DC++/stb is tudjon tõlük tölteni).

Ez konkrétan annyit jelent, hogy DC++ 0.403-nál régebbi klienstõl tölteni nem tudsz új DC-vel. Az a verzió már 2,5 éve jelent meg, szerintem belátható, hogy nem az új klienseknek kell a régi, elmaradottakat támogatni, hanem a régi, elmaradott felhasználóknak kellene valami modernebb cuccot beszerezni.

Az, hogy ez pont egy operátorral fordul elõ, az pedig kimondottan szomorú. Próbáld meg megkérni, hogy nézze meg a wxDCGUI-t ( http://sourceforge.n...ojects/wxdcgui/ ), hátha hallgat a józan szóra.

[bugbear]

Felraktam a DCPlusPlus-0.698-at de semmi változás.

[bugbear]

Megoldva !!!!!!!!!!!! Felraktam egy filemonitort és a dc könyvárban találtam egy pár file-t amit felülirogat a dc menet közben és erre a könyvtárra adtam irásjogot a felhasználónak. Azért mindenkinek köszönöm !!!

Szerkesztette: bugbear 2007. 02. 07. 22:18 -kor

[Orgi]

Köszi Fleetcommand, megpróbálom jelezni neki legalább a dolgot, hátha meghatja, ha már operátor
Nem lesz mostanában 699az verzió, letöltési listám fele olyan könyvtár, amit már kiszedett a tulaj a megosztásából vagy nem lehet vhogy manuálisan törölgetni az xml-bõl? Belenézés után nem túl bonyolult a felépítése...

[FleetCommand]

Idézet: Orgi - Dátum: 2007. febr. 8., csütörtök - 0:14

Köszi Fleetcommand, megpróbálom jelezni neki legalább a dolgot, hátha meghatja, ha már operátor
Nem lesz mostanában 699az verzió, letöltési listám fele olyan könyvtár, amit már kiszedett a tulaj a megosztásából vagy nem lehet vhogy manuálisan törölgetni az xml-bõl? Belenézés után nem túl bonyolult a felépítése...

Folyamatosan figyelem a DC++ svn-jét, de sajnos már hetek óta semmi aktivitás nincsen. Pedig engem is irritál ez a bug, fõleg annak a fényében, hogy nagyon jól tudom, hogy ez az egyetlen hiba a programban, ami idegesítõ, és szeretném mielõbb kijavítva látni. Egyelõre csak azt tudom javasolni, hogy várj még egy kicsit.

Egyéb: Az xml fájl valóban nem túl bonyolult, elvileg könnyen törölhetõek belõle a letöltések kézzel is. Csak, ha ilyennek látsz neki, célszerû lenne olyan szerkesztõvel nekilátni, ami jelzi rögtön az xml-ben a hibákat, így nem érhet az a meglepetés, hogy beleszerkesztesz, elfelejtesz lezárni egy taget és elszáll az egész letöltési sorod... (pl XML Notepad 2007, stb)

[mushmushi]

Sziasztok!
Némileg hasonló problémám lenne a bcdc++ új verziójának összeomlásával kapcsolatban, mint orginak. Íme a hibaüzenetem:

Code: c0000005
Version: 0.699
Major: 5
Minor: 1
Build: 2600
SP: 2
Type: 1
Time: 2007-02-10 17:07:01
TTH: NB2QZKQJ5UFHHJLBEGKKABNZUATCH6QXKUPTCLA

0x0012F627: ?
c:\bcdcsrc\windows\queueframe.cpp(980): QueueFrame::removeDir
c:\bcdcsrc\windows\queueframe.cpp(641): QueueFrame::removeSelectedDir
c:\program files\microsoft visual studio 8\vc\atlmfc\include\atlwin.h(3078): ATL::CWindowImplBaseT<WTL::CMDIWindow=0x01CB8650,ATL::CWinTraits<1456406528=0x00000000,64> >::WindowProc
USER32!0x77D38734: GetDC
USER32!0x77D38816: GetDC
USER32!0x77D389CD: GetWindowLongW
USER32!0x77D38A10: DispatchMessageW
c:\documents and settings\szabolcs\my documents\dcplusplus source\wtl80_6137\include\atlapp.h(584): WTL::CMessageLoop::Run

Jó lenne tudom, h van -e összefüggés a két crash között, illetve, ha van, kijavítható lesz -é? Sajnos már olyanokat is olvastam, h az új amd processzor okozza ezt a memória zárolást, melyet a bcdc aktivál. Na ezt most jól megaszondtam, nem igazán értek hozzá ilyen mélységekben. Üdv mindenkinek. Várom választokat.
Mushi

[mushmushi]

Sziasztok!

Ismét mushi vagyok, s mivel a minap elég zavarosan vázoltam fel azt a bizonyos processzor folyamatot, most mellékelem az irományt, melyben a hiba vonatkozásában a processzorra hivatkoznak, amit elvileg a bcdc készítõinek már rég orvosolniuk kellett volna, ugyanis az iromány 2005bõl származik, a hwsw-rõl, vagyis innen.

Íme: Kitk@t az athlon64 processzor behozott egyújdonságot, amit úgy hívnak hogy Nx (no execute) bit. Ez arra való, hogy kártékony programok amik csellel adatként lopóznak be a memóriába majd az alkalmas támadó rész aktivizálódása után mûködésbe lépnek, mégse tudjanak mûködni, kárt okozni. amikor egy elinduló program az operációs rendszertõl memóriát kér, az operációs rendszer megjejlöli, hogy a kért memória milyen szándékkal lett kérve (kód vagy adatok). Az athlon 64 processzor ezt szigorúan ellenõrzi, ha az sp2 frissítés telepítésre került.

Namost ne ijedj meg, nagy valószínûséggel nincs vírusod. valszeg az van, hogy a kérdéses directconnect mitoomén micsoda program, slendriánul van megírva, pl matat a processzor vermén, így a processzor úgy kátja, hogy rosszhiszemû kód férkõzött a renszerbe és a probléma helyén fellelhetõ alkalmazás futását letiltja és a kérdéses memóriahelyet zárolja.


mielõtt nagyon nekiesnél a directconnect akármi írójának elmondom, hogy a microsoft office termékcsalád is belefut ebbe a gondba mint disznó a késbe, így az office-okra sp2-es rendszerben athlon64/opteron processzor esetén a megfelelõ update-tel el kell látni.


Lehet, hogy ezzel nem segítek, de eléggé hasznos lenne orvosolni a problémát, hiszen van egy olyan érzésem, hogy nem csak én és orgi vagyunk az egyedüliek, akik ezzel a hátrányos helyzettel küzdünk. Amúgy nekem már spontán is kifagy a bcdc, nem csak akkor, amikor valamit megpróbálok törölni a download queue-bõl...

Üdvözlet és legjobbakat:

Mushmushi

[FleetCommand]

Idézet: mushmushi - Dátum: 2007. febr. 10., szombat - 17:41

... Sajnos már olyanokat is olvastam, h az új amd processzor okozza ezt a memória zárolást, melyet a bcdc aktivál. Na ezt most jól megaszondtam, nem igazán értek hozzá ilyen mélységekben. Üdv mindenkinek. Várom választokat.
Mushi

Ez így, ebben a formában nem igaz. A fenti crashnek egy-két hibás sor az oka, nem a processzor. Már fentebb linkeltem a Bugzillát: http://dcpp.net/bugz...bug.cgi?id=1141 .. Itt jelentettem a hibát, ami - mint említettem - a DC++ svn-ben van. Az esetleges változásokat (kijavítás, stb) valószínû elõször itt fogják bejelenteni.

A másik problémádra reflektálva: Nekem soha nem fagyott le sem a 0.698-as, sem a 0.699-es verzió "csak úgy".

[mushmushi]

Köszönöm a felvilit Fleet!

Örülök neki, hogy van akinél nem jelentkeznek az ezen fajta crashek, de nálam mégis megmutatkozik a bcdc sötét oldala...bár lehet, hogy a hiba az én készülékemben van, addig is bemásolom a spontán "fatal bug" crash exceptioninfóját:

Code: c0000005
Version: 0.699
Major: 5
Minor: 1
Build: 2600
SP: 2
Type: 1
Time: 2007-02-12 00:38:04
TTH: NB2QZKQJ5UFHHJLBEGKKABNZUATCH6QXKUPTCLA

0x0012F627: ?
c:\bcdcsrc\windows\queueframe.cpp(980): QueueFrame::removeDir
c:\bcdcsrc\windows\queueframe.cpp(641): QueueFrame::removeSelectedDir
c:\program files\microsoft visual studio 8\vc\atlmfc\include\atlwin.h(3078): ATL::CWindowImplBaseT<WTL::CMDIWindow=0x01CE4E60,ATL::CWinTraits<1456406528=0x00000000,64> >::WindowProc
USER32!0x77D38734: GetDC
USER32!0x77D38816: GetDC
USER32!0x77D389CD: GetWindowLongW
USER32!0x77D38A10: DispatchMessageW
c:\documents and settings\szabolcs\my documents\dcplusplus source\wtl80_6137\include\atlapp.h(584): WTL::CMessageLoop::Run

Hátha ez segít fényt deríteni a jelenségre, mert mindíg is bcdc-t használtam, s örülnék, ha ezen túl is ez maradna a letöltõprogramomnak. Még egyszer köszi szépen a bugzillás cuccost, hasznos lesz, amennyiben minden így marad.

Peace: Mushi

[Warton]

A BCDC-nek nincs is világos oldala, legalábbis én még nem tapasztaltam.

[Wyco]

Most en állok elo a szokásos problémával.
Nem tudok csatlakozni hubokra, ill ha mégis, ledobnak, 0 byte/sec upload-om van állandóan, keresés nem megy, stb.
Adatok: Chello, router (amivel korábban ment). Probáltam portforwardot, passzivot, egyik se segít. Upnp nincs, ki van kapcsolva, le van torolve. Szolgáltatásként se fut. Windows tuzfal van csak, de akkor se megy ha bekapcsolom, meg akkor se ha kikapcsolom. Kvázi egyáltalán nem megy.
Kb az osszes klienst végignyaltam, még a settingsfilet is töröltem (meg gyakorlatilag minden mást is, de nem segített.)
Ötletek?
A bind address 0.0.0.0 de ha bealitom a belso ip-met rá (192.168.2.40 akkor se megy). A masik erdekesség hogy a progi mindig áltállítja a kulso ipmet a fent emlitett 192-es cimre, pedig hát nem az. (és ha visszaallitom se tortenik semmi, kov. indulaskor visszaáll. de mint mondtam passziv modban se megy.)

Szerkesztette: Wyco 2007. 03. 03. 21:27 -kor

[nyunyu]

Alap DC legfrissebb:

akarmi.dyndns.org helyere elmeletileg a kulso IP-det kene irni, de lusta vagyok minden nap kezzel atirni, egyszerubb ha a router altal frissitett DDNS aliast hasznalom.

Csatolt fájl:

•  dc.GIF (0byte)
  Letöltések:: 0

[nyunyu]

Ugyanez StrongDC-nel:

UPNP egyaltalan nem mukodik a StrongDC-ben, ugyhogy muszaj manualt hasznalni.
(Bezzeg hugom messengere siman nyitott maganak portot, szoval nem a routerrel van a baj...)

Csatolt fájl:

•  sdc.GIF (0byte)
  Letöltések:: 0

Szerkesztette: nyunyu 2007. 03. 04. 01:26 -kor

[Wyco]

Mleyik tobbszalu kliens tud upnp-t?
Megprobálom átirni, de pl passzivban miert nem mukodik vajon?
kiprobltam az upnp-t bcdc -vel is de mindig arra sir hogy unalbe to create port mappings
maskor meg arra sir hogy unalbe to open tcp port, pedig engedelyezve van mindenhol

Szerkesztette: Wyco 2007. 03. 04. 11:01 -kor

[nyunyu]

Ha az IP-hez nem irod be a kulso IP-det/DDNS aliasodat, akkor egyaltalan nem megy a kereses.

[Wyco]

ezen már átestem. probáltam a dyndns-sel is.
mondom, az a gond hogy 0byte felmenõm van és ezért rovidtávon ledob a rendszer mindenhonnan.
probáltam más géprol is itthon (eredeti win-beallitasokka) ami ezen a routeren van, sõt probáltam már a router gyári visszaállításával is...semmi

[Wyco]

visszatérve a 0 byte-os dologra, ezek az aktualis beallitasok, de ha beirom az ip cimet vagy átmegyek passzivba akkor sincs semmi jo...


[ Kattints ide a teljes méretû képhez ]