Direct Connect
Jelentkezz be a hozzászóláshoz.
#10122
Részlet a szabályzatból:
Ez kb. 8 honapja mûködik így. Jelenleg határ 1500 user, e felett 10G, alatta 1G. A max userszám 1750, való igaz, ritkán megy 1500 alá, de hajnaltájt nem reménytelen.
Az egyéb hubralépési problémáidnak más oka lehet, de ha nem írod meg hogy milyen hibaüzenettel szakad a kapcsolat akkor nehéz lesz kitalálnunk.
-Minimum megosztás:Dinamikus megosztási limit, 1 G, közel full hubnál 10 G. Az emelt követelmény az újonnan csatlakozó userekre vonatkozik.
Ez kb. 8 honapja mûködik így. Jelenleg határ 1500 user, e felett 10G, alatta 1G. A max userszám 1750, való igaz, ritkán megy 1500 alá, de hajnaltájt nem reménytelen.
Az egyéb hubralépési problémáidnak más oka lehet, de ha nem írod meg hogy milyen hibaüzenettel szakad a kapcsolat akkor nehéz lesz kitalálnunk.
It\'s not hard to meet expenses...they\'re everywhere.
#10121
hello! az normális, h egyik napról a másikra nem tudtam belépni a Flash, a Nasa hubra, és az elite is kidob, mert a nagyobbaknak kell hagyni a helyet? pedig a szabályzatukban nem ez áll!!!! (HUN)LeeFH)
¡Hala Madrid!
#10120
Na. Pár percen belül letölthetõ a BCDC-bõl a 0.306ax, ez már nem gáz, ezt lehet használni, ellentétben a 0.305b-vel..
* javítva a file not available bug alternatíva keresésénél, ha a tömörített átvitel be van kapcsolva
* egyelõre visszaállítva a hagyományos megosztás-ellenõrzés, amíg BC nem jön rá arra, hogy miért lesz kisebb a megosztás.. szóval most már ez is rendben van, nem lesz kisebb :)
egyéb újdonságok, izék a weboldalon, illetve a telepítõben, leírásokat meg ilyeneket majd a jövõ héten frissítek, most egyelõre ez is több volt, mint amit akartam (idõm engedi)
* javítva a file not available bug alternatíva keresésénél, ha a tömörített átvitel be van kapcsolva
* egyelõre visszaállítva a hagyományos megosztás-ellenõrzés, amíg BC nem jön rá arra, hogy miért lesz kisebb a megosztás.. szóval most már ez is rendben van, nem lesz kisebb :)
egyéb újdonságok, izék a weboldalon, illetve a telepítõben, leírásokat meg ilyeneket majd a jövõ héten frissítek, most egyelõre ez is több volt, mint amit akartam (idõm engedi)
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10119
darkd amúgy én még javaslom az e-mail írását is
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10117
Megjelent az ÚJ DCPlusPlus Kliens.
Lehet próbálgatni..
Lehet próbálgatni..
\"Nem a hideg, kevély világnak, Neked szántam regényemet. Bár adhatnék a hû barátnak Ennél méltóbb hûség-jelet.\"
#10112
\"Nem a hideg, kevély világnak, Neked szántam regényemet. Bár adhatnék a hû barátnak Ennél méltóbb hûség-jelet.\"
#10108
Na eltelt egy kis idõ, teszteltem még a 305b verziójú BCDC-t.. a használatát továbbra sem javaslom, a 12 GB megosztásból 2 GB-ot eltávolított, mert úgy gondolta, hogy az duplikáció (tévesen)
Szóval aki nem szeretné, hogy a megosztásának a mérete 20 %-al csökkenjen, inkább maradjon a jól bevált verziónál :D
Szóval aki nem szeretné, hogy a megosztásának a mérete 20 %-al csökkenjen, inkább maradjon a jól bevált verziónál :D
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
![[OP]MaciLaci](https://media.sg.hu/forum/avatars/10410220651043689377.gif)
#10105
Figyelem (az erintettek:D)
A Wishen pentek estetol (januar 9-e) a minimum megosztas 5 G re valtozik!!
Szerintem nem nagy deal:)
Cupp az illetekeseknek,
Maci
A Wishen pentek estetol (januar 9-e) a minimum megosztas 5 G re valtozik!!
Szerintem nem nagy deal:)
Cupp az illetekeseknek,
Maci
Life is wasted on living!
#10104
gyk még mielõtt 30 kérdés lesz..
az alábbi szöveg azt jelenti, hogy a 0.305b, azaz bé verziójú verzióval van a gond.. azaz:
** DC++ bármilyen verzió OKÉS
** BCDC++ 0.305b NEM OKÉS
** BCDC++ 0.305a, ax, ay okés, mivel az a betû nem b betû..
az alábbi szöveg azt jelenti, hogy a 0.305b, azaz bé verziójú verzióval van a gond.. azaz:
** DC++ bármilyen verzió OKÉS
** BCDC++ 0.305b NEM OKÉS
** BCDC++ 0.305a, ax, ay okés, mivel az a betû nem b betû..
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10103
Fontos announcement:
A 0.305b verziójú BCDC++-t ne használjátok, nem véletlen, hogy a magyar weboldalra (http://bcdc.webhop.org) nem tettem ki, ugyanis igen durva hiba van benne, ami miatt a megosztásod mérete csökken, a benne lévõ fájlok nem látszanak, illetve össze is keveredik a könyvtár-struktúrád.
A magyar weboldalon csak ellenõrzött progikat találtok, ami onnan letölthetõ, az okés, illetve ha bug van, arról úgyis kiteszek valami infót...
Köszi
A 0.305b verziójú BCDC++-t ne használjátok, nem véletlen, hogy a magyar weboldalra (http://bcdc.webhop.org) nem tettem ki, ugyanis igen durva hiba van benne, ami miatt a megosztásod mérete csökken, a benne lévõ fájlok nem látszanak, illetve össze is keveredik a könyvtár-struktúrád.
A magyar weboldalon csak ellenõrzött progikat találtok, ami onnan letölthetõ, az okés, illetve ha bug van, arról úgyis kiteszek valami infót...
Köszi
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10102
Na megcsináltam a magyar zdc-hez a következõt:
a tag ezentúl egy M: résszel bõvül, ami a DownloadSlots értékét jelzi ki (maximális letöltési szál).
Itt egy kép róla, hogy mûködik:
http://users.atw.hu/n/o/norti/m_tag.gif
DC++ emuláció esetén megmarad a szabvány tag és description elejére kerül a limit (Lx) és a letöltési szálak (Mx) majd utána verziószám. Desc szerint rendezve a klienseket elég szembetûnõ, ki csal.
BCDC emu esetén a tagba mind2 a végére.
M: a 0 érték esetén, azaz ha nincsenek korlátozva a letöltési szálak, is megjelenik. Ezt majd ha jön az új változat letiltom, hogy mindenképpen legyen korlát.
Ezzel a taggel minden hub meghatározhatja az ndc-re a szabályait (ha akarja).
A témát ezzel átvittem a kliens fórumába, oda írjatok, ha vmi észrevétel, ötlet lenne még ezzel kapcsolatban:
http://forum.supergamez.hu/forum.php3?azonosito=zdcforum
Köszi és sry ha vkit zavartam ezzel itt.
a tag ezentúl egy M: résszel bõvül, ami a DownloadSlots értékét jelzi ki (maximális letöltési szál).
Itt egy kép róla, hogy mûködik:
http://users.atw.hu/n/o/norti/m_tag.gif
DC++ emuláció esetén megmarad a szabvány tag és description elejére kerül a limit (Lx) és a letöltési szálak (Mx) majd utána verziószám. Desc szerint rendezve a klienseket elég szembetûnõ, ki csal.
BCDC emu esetén a tagba mind2 a végére.
M: a 0 érték esetén, azaz ha nincsenek korlátozva a letöltési szálak, is megjelenik. Ezt majd ha jön az új változat letiltom, hogy mindenképpen legyen korlát.
Ezzel a taggel minden hub meghatározhatja az ndc-re a szabályait (ha akarja).
A témát ezzel átvittem a kliens fórumába, oda írjatok, ha vmi észrevétel, ötlet lenne még ezzel kapcsolatban:
http://forum.supergamez.hu/forum.php3?azonosito=zdcforum
Köszi és sry ha vkit zavartam ezzel itt.
#10101
Nem tudom, hogy a Koli HUB operátorai olvassák-e még a fórumot, üzenem nekik, hogy szép húzás megbeszélés helyett kirúgni az embert a HUB-ról! Gratulálok hozzá!
#10100
Changelog:
"* Changed the way rollback works, it is now more tightly integrated with write buffer size. Write buffer
size will now be used as a cutoff, so that the last <writebuffersize> bytes will be removed and then
<rollbacksize> bytes will be compared to see if it's the same file. "
Én nyertem
"* Changed the way rollback works, it is now more tightly integrated with write buffer size. Write buffer
size will now be used as a cutoff, so that the last <writebuffersize> bytes will be removed and then
<rollbacksize> bytes will be compared to see if it's the same file. "
Én nyertem
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10099
"A Write buffer értéke az, amit növelni kell, nem a rollback. A Rollback az az ellenõrizendõ méretet adja meg, de a write buffer lesz az, ami levágásra kerül a fájlból"
Ez így nem igaz...
Rollback: Azon adatmennyiség mértéke amit a kliens a letöltés újrakezdésekor a befejezetlen fájl végébõl ellenõriz. Csak akkor csapja a megadott mennyiséget le ha hibás az utólag vett adat.
Write buffer: Azon adatmennyiség mértéke, amennyinként a kliens a letöltés alatt lévõ fájlt a memóriából kiírja a vinyóra... Ezzel próbálja megelõzni több letöltés esetén a kliens azt, hogy túlontúl fragmentálódjon a lemez.
In english:
Rollback: Size of bytes to rollback when resuming a file to
ensure it contains no errors.If there is an error DC++ deletes <rollback> bytes and checks again.
Write buffer size: Anti-fragmentation feature, DC++ saves every <write buffer size> bytes to keep fragmentation low.
End.
Ez így nem igaz...
Rollback: Azon adatmennyiség mértéke amit a kliens a letöltés újrakezdésekor a befejezetlen fájl végébõl ellenõriz. Csak akkor csapja a megadott mennyiséget le ha hibás az utólag vett adat.
Write buffer: Azon adatmennyiség mértéke, amennyinként a kliens a letöltés alatt lévõ fájlt a memóriából kiírja a vinyóra... Ezzel próbálja megelõzni több letöltés esetén a kliens azt, hogy túlontúl fragmentálódjon a lemez.
In english:
Rollback: Size of bytes to rollback when resuming a file to
ensure it contains no errors.If there is an error DC++ deletes <rollback> bytes and checks again.
Write buffer size: Anti-fragmentation feature, DC++ saves every <write buffer size> bytes to keep fragmentation low.
End.
#10098
#10064: "Más nickkel is próbáltam de nem sikerült azzal sem.Tud valaki segíteni ez ügyben?"
#10095
"Csak" akkor foglal... :) Nekem kb. 1,5 órig csinálta a 26G-s megosztást, mégis járt még mindig a vinyó... Igaz hogy nem hashel újra, viszont, ha naponta frissül a megosztásod, akkor már kb. 10-15 fájlnál (fõleg isoknál) is elszöszmötöl félóráig, ezt pedig kultúráltabban is meg lehetne oldani. RC tényleg e-donkey hash rendszerét használja, viszont szolidabban:
1. 4.5 mb/sel olvassa a fájlokat a háttérben, amit észre sem lehet venni
2. registryt használja a hashek mentésére
(https://sourceforge.net/forum/forum.php?forum_id=332610)
"RevConn use these information to ensure that never hash the same file twice, even if you unshare a folder and share it again. And even more, changing file name or moving file in the same drive will not cause rehashing." << Ez a tapasztalataim szerint bcdcben nem így mûxik.
Az tény hogy RC emu egyelõre használhatatlan, viszont azt figyelembe kell venni, hogy kb. 1 hónapja került bele a kliensbe és így van még idõ fejleszteni rajta.
Jó lesz majd a hash keresés akkor, ha a hubon lévõ kliensek mondjuk 75%a már támogatja. De addig sztem még mindig több találatot eredményez a "sima" alternatíva keresés vagy az egyszerû kézi keresés és filenév/fileméret egyeztetés. RC-ben lehet hash alapján keresni, zdcben azért nem, mivel (egyelõre) ütközik a bcdc és az rc hash módszere benne. Azért az elég érdekes, hogy bcdc emu módban kapsz hash találatokat a bcdc kliensektõl, ahol engedélyezve a hashing...
1. 4.5 mb/sel olvassa a fájlokat a háttérben, amit észre sem lehet venni
2. registryt használja a hashek mentésére
(https://sourceforge.net/forum/forum.php?forum_id=332610)
"RevConn use these information to ensure that never hash the same file twice, even if you unshare a folder and share it again. And even more, changing file name or moving file in the same drive will not cause rehashing." << Ez a tapasztalataim szerint bcdcben nem így mûxik.
Az tény hogy RC emu egyelõre használhatatlan, viszont azt figyelembe kell venni, hogy kb. 1 hónapja került bele a kliensbe és így van még idõ fejleszteni rajta.
Jó lesz majd a hash keresés akkor, ha a hubon lévõ kliensek mondjuk 75%a már támogatja. De addig sztem még mindig több találatot eredményez a "sima" alternatíva keresés vagy az egyszerû kézi keresés és filenév/fileméret egyeztetés. RC-ben lehet hash alapján keresni, zdcben azért nem, mivel (egyelõre) ütközik a bcdc és az rc hash módszere benne. Azért az elég érdekes, hogy bcdc emu módban kapsz hash találatokat a bcdc kliensektõl, ahol engedélyezve a hashing...
Törölt felhasználó
#10094
A #10064 kérdésemre tud valaki válaszolni?Esetleg a Koli OP-jai közül valaki?Köszi.
#10093
A mai szó: "amúgy" :D
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10092
A hashing csak akkor foglal procit és memóriát, amíg legelsõ alkalommal megcsinálja a hasheket.. OK, visszafoghatná a teljesítményzabálást, csak kérdés, hogy jobb-e, ha 20 %-ot eszik a gépbõl mondjuk 3 órán keresztül, vagy inkább befejezi fél óra alatt :D
''Disk usage hasn't really changed. It still reads data to hash as fast as it can // The hash calculation shouldn't be repeated for files it's already hashed, even if you restart the program; it stores them in the file "hashes". ''
Amúgy ezt aláírom, mert nem túl sokat változik a megosztásom, és mióta megvan a hash fájl, azóta a proci használat nem ment pár százalék fölé.
Amúgy a reverseconnect nem tudom, milyen hasheket használ (emule vagy edonkey vagy valami hasonló), de szvsz pl a zdc nem keres hashek alapján (max reverse connect emulációban, ami meg egyéb problémákat okoz.. pl fájl-listáknál stb), mert mindenre "gyanúsan sok" alternatívát ad ki, sokkal többet, mint ahányan a klienst használhatják és még az adott fájl is meg lenne nekik osztva.
Amúgy végre van pozitív eredmény is hash téren, még ugyan messze nincs elterjedve annyira, mint kéne, de ma pl tesztként találtam alternatívát egy elkezdett filmre úgy, hogy a fájnévnek semmi köze nem volt egymáshoz:
>>Screenshot (az oszlopokat megpróbáltam úgy összehúzni, hogy a lényeg látszódjon :) <<
''Disk usage hasn't really changed. It still reads data to hash as fast as it can // The hash calculation shouldn't be repeated for files it's already hashed, even if you restart the program; it stores them in the file "hashes". ''
Amúgy ezt aláírom, mert nem túl sokat változik a megosztásom, és mióta megvan a hash fájl, azóta a proci használat nem ment pár százalék fölé.
Amúgy a reverseconnect nem tudom, milyen hasheket használ (emule vagy edonkey vagy valami hasonló), de szvsz pl a zdc nem keres hashek alapján (max reverse connect emulációban, ami meg egyéb problémákat okoz.. pl fájl-listáknál stb), mert mindenre "gyanúsan sok" alternatívát ad ki, sokkal többet, mint ahányan a klienst használhatják és még az adott fájl is meg lenne nekik osztva.
Amúgy végre van pozitív eredmény is hash téren, még ugyan messze nincs elterjedve annyira, mint kéne, de ma pl tesztként találtam alternatívát egy elkezdett filmre úgy, hogy a fájnévnek semmi köze nem volt egymáshoz:
>>Screenshot (az oszlopokat megpróbáltam úgy összehúzni, hogy a lényeg látszódjon :) <<
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10091
Sztem még azon gondolkozik, miért zabál annyi cpu-t illetve miért darálja a vinyót a hashing és nem azon, hogy a többszálon való letöltés mennyire befolyásolja a dc jövõjét... :) Egyébként a hashing célja tudtommal is az, hogy sikerüljön egy olyan azonosítást és ellenõrzést kidolgozni dc-ben is a fájlokhoz, amivel megvalósítható majd a többszálas letöltés. Viszont Reverseconnect nem vette át a bcdc hashingjét, helyette okosan egy olyan megoldást választott ami már máshol bevált és ami kevésbé terheli a rendszert. Nem vitatom, hogy bcdc-é is elfogadható szinten lesz, csak arra még egy kicsit várni kell...
A másik, visszatérõ téma:
Majd ha Magyarországon is lesz lehetõség szélessávú(!) netre elérhetõ áron és mindehol(!) nem csak a nagyvárosokban, akkor nem lesz szükség többszálas letöltésre. Amíg a dc nem nyilvános és lehet tartani ezt a közel zárt formáját, addig nem alakulhat ki belõle olyan mint pl. a kazaaból. Én épp azon dolgozom, hogy lehessen szabályokat alkotni a letöltési szálakra is, éppúgy mint a feltöltési slotokra.
"Régen" volt már vita, de ez legalább technikai jellegû :DDD
A másik, visszatérõ téma:
Majd ha Magyarországon is lesz lehetõség szélessávú(!) netre elérhetõ áron és mindehol(!) nem csak a nagyvárosokban, akkor nem lesz szükség többszálas letöltésre. Amíg a dc nem nyilvános és lehet tartani ezt a közel zárt formáját, addig nem alakulhat ki belõle olyan mint pl. a kazaaból. Én épp azon dolgozom, hogy lehessen szabályokat alkotni a letöltési szálakra is, éppúgy mint a feltöltési slotokra.
"Régen" volt már vita, de ez legalább technikai jellegû :DDD
#10090
Pedig a DC Socks 5 proxy mögül mûködik, amennyiben van megfelelõ hozzáférésed a proxy-szerverhez.. >Screenshot<
Ha nem socks5 a proxy, akkor reménytelen a dolog szvsz
Ha nem socks5 a proxy, akkor reménytelen a dolog szvsz
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10089
Pedig a hashing lenne az, ami megalapozná a több forrásból való letöltés valódi hátterét. Már cask az a kérdés, hogy BlackClaw vajon miért nem tett több forrásból való letöltést a kliensbe a hashing mellé (valószínûleg jól átgondolta a dolgot, hogy most még miért nincs)...
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10088
Hmm...
Nagyon kéne egy http proxi mögül mûxõ kliens...
Nagyon kéne egy http proxi mögül mûxõ kliens...
Ha nemtetszik az, hogy valamit az X oldalról linkelek, akkor nem kell flémelni, mert nem kötelező rákattintani! :P Link rövidítés: http://fc.lc/ref/PLaci
#10087
Nincs fenn egyébként a bcdc azóta, amióta belerakták hashing-et :P
Hát nem tudom, egyelõre nem nagyon látom értelmét a scripteknek a dc kliensekben. Majd ha talán vki vmi értelmeset ír és használható a dolog, akkor elfogadható lesz :) De hogy egy privire válaszolva away üzi mellé még egy ilyet is kapjak? :DDDD Szörnyûûûû :DDDD Majd vki rájön, hogy lehet több sornyi szöveget (sok kis mókás rajz :) is benyomni, na annak fogok igazán örülni :DDD
Hát nem tudom, egyelõre nem nagyon látom értelmét a scripteknek a dc kliensekben. Majd ha talán vki vmi értelmeset ír és használható a dolog, akkor elfogadható lesz :) De hogy egy privire válaszolva away üzi mellé még egy ilyet is kapjak? :DDDD Szörnyûûûû :DDDD Majd vki rájön, hogy lehet több sornyi szöveget (sok kis mókás rajz :) is benyomni, na annak fogok igazán örülni :DDD
#10086
Közérdekû közl
Aki alternatíva keresésénél kap file not available üzenetet, az kapcsolja ki a tömörített adatátvitelt. Ellenben ha a hibaüzi továbbra is fennáll, akkor mégse vaklárma volt, keressen op-ot és jelentse a dolgot :)
Aki alternatíva keresésénél kap file not available üzenetet, az kapcsolja ki a tömörített adatátvitelt. Ellenben ha a hibaüzi továbbra is fennáll, akkor mégse vaklárma volt, keressen op-ot és jelentse a dolgot :)
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10085
Az új telepítõben átírtam a scriptet, hogy a "slotot"-ra reagáljon, ne a "slot"-ra :) Amúgy szvsz egy jó kis funkció, nemtom, miért idegesít.. :p Érdekes még a view menü Debug messages ablaka is.
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10084
Nekem nem bcdc van :D
Szal törölje az aki ezt használ vagy állítsa be rendesen a scriptet, mert elég idegesítõ, ahogy megkapja az én away üzimet, hogy no slot blabla, visszadobja ezt én meg már ideges vagyok az userre, mit don't ask-ozik nekem :DDDDD
Szal törölje az aki ezt használ vagy állítsa be rendesen a scriptet, mert elég idegesítõ, ahogy megkapja az én away üzimet, hogy no slot blabla, visszadobja ezt én meg már ideges vagyok az userre, mit don't ask-ozik nekem :DDDDD
#10082
Fleet lenne egy kérdésem az új bcdckhez:
mi a fenéért dobja vissza a don't askot nekem priviknél? :DDD
megöl idegileg már :DDDDDDDD
mi a fenéért dobja vissza a don't askot nekem priviknél? :DDD
megöl idegileg már :DDDDDDDD
#10080
nem lehet õket szabályozni.
ne légy mohó és próbálj meg 1xre egy dolgot csinálni, hidd el ugyanúgy jössz ki, mivel a sávszéled csak osztódik.
ne légy mohó és próbálj meg 1xre egy dolgot csinálni, hidd el ugyanúgy jössz ki, mivel a sávszéled csak osztódik.
#10079
jó, ezt a részét vágom, de van egy két olyan HUB , állt külföldi amelyik csak ugy enged be ha csak azon vagyok fent,és ehez kéne, ,és akik rolam töltenek azokat lehet bármilyen modon szabályozni, értem itt ezalatt, hogyha látja hogy 1kval vagy a környékén tud csak ltölteni akkor inkább keressen másik helyet?
#10078
Nagyon sokan viszont azt szeretnék, hogy ha lehet, akkor ne szeresd 2 példányban futtatni.. ha másért nem, mert tiltják a szabályzatok. Azon kívül neked is rossz, ui a dupla letöltés lefogja a netedet
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10076
Ez okés, de Prédikátor szvsz 2, függõlegesen elválasztott ablakra szeretné felbontani a progit. Ehhez viszont csak az elõzõ-méret gomb kell és egy kis kézzel való utánaigazítás (avagy a Window > vertical tile).. opsz most nézem csak, hogy a magyar fordítás pont fordítva van, ki kell javítanom a nyelvi fájlt 
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10075
Ez en DCm tobb peldanyban is tud futni!
#10073
A DC-t csak 1 ablakban lehet futtatni, de a benne lévõ hubokat már úgy rendezed el, ahogy szerenéd. Ehhez minimális szintû windows operációs rendszeri ismeretek szükségesek, illetve az elõzõ- és teljesméret gombok ismerete. Illetve a Window (Ablak) menü tartalmában is nézz körül, ott is találsz 1-2 elrendezést.
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10071
Hi all!
Hogy lehet megcsinálni azt hogy egyszerre 2 ablakban is futtatni tudjam a DC-t ugy mintpl a Totalcommander-nél
Hogy lehet megcsinálni azt hogy egyszerre 2 ablakban is futtatni tudjam a DC-t ugy mintpl a Totalcommander-nél
#10070
Csodás valóban, de ha a kurzorral beálltam abba a mezõbe és bármit írtam bele, uhnandled expection-nal kilépett.. akkor is, ha csak hagytam egy kicsit ott villogni a kurzort 
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10068
* Added possibility to write any arbitrary text as connection type in the settings dialog. The default values are still there (Cable, DSL, etc)
csodás ez az új odc, csak ezzel elég sok hub nem fogja beengedni az usert, ha használja... (még ha az új taget engedélyezik is)
viszont van benne egy olyan bug, ami zdc/ndc-ben is, hogy privik fülénél legtöbbször a context menü alulra nyílik ki. de azt írják ezt késõbb (?) javítják.
csodás ez az új odc, csak ezzel elég sok hub nem fogja beengedni az usert, ha használja... (még ha az új taget engedélyezik is)
viszont van benne egy olyan bug, ami zdc/ndc-ben is, hogy privik fülénél legtöbbször a context menü alulra nyílik ki. de azt írják ezt késõbb (?) javítják.
#10067
Ez hasonló a limitáláshoz, viszont akkor a LAN-osok pl. max esetben 30*1,5 szálon tölthetnének, ami szintén eszi a többiek elõl a slotot...
Viszont zzz beültetett vmit a fejembe, amit ha meg tudok csinálni, akkor minden hub saját szabályt alkothat a letöltési slotokra is és így nem lesz vita, hogy miért 7 vagy egyéb a korlát. Ezzel együtt viszont le kell mondani a szabvány dc++ tagról, mert ott is szerepelnie kell a letöltési slotoknak... Desc-be meg nem akarom már zsúfolni, mivel már dc+ emunál ott a limit és a verziószám illetve, hogy opos-e...
Viszont zzz beültetett vmit a fejembe, amit ha meg tudok csinálni, akkor minden hub saját szabályt alkothat a letöltési slotokra is és így nem lesz vita, hogy miért 7 vagy egyéb a korlát. Ezzel együtt viszont le kell mondani a szabvány dc++ tagról, mert ott is szerepelnie kell a letöltési slotoknak... Desc-be meg nem akarom már zsúfolni, mivel már dc+ emunál ott a limit és a verziószám illetve, hogy opos-e...
Törölt felhasználó
#10064
Szeretném megtudni miért vagyok bannolva a Koliról?
Ezt írja ki:This Hub is running version 0.9.6 alpha of VerliHub (RunTime:0days 21h 43min).
<Hub-Security> Bad nickname: already used
Más nickkel is próbáltam de nem sikerült azzal sem.Tud valaki segíteni ez ügyben?
Ezt írja ki:This Hub is running version 0.9.6 alpha of VerliHub (RunTime:0days 21h 43min).
<Hub-Security> Bad nickname: already used
Más nickkel is próbáltam de nem sikerült azzal sem.Tud valaki segíteni ez ügyben?
#10058
rollback 4096 write buffer 64 vagy 128
It\'s not hard to meet expenses...they\'re everywhere.
#10056
A Write buffer értéke az, amit növelni kell, nem a rollback. A Rollback az az ellenõrizendõ méretet adja meg, de a write buffer lesz az, ami levágásra kerül a fájlból
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10055
<++ V:0.25,M:P,H:0/0/3,S:8> --- ez egy 5.212es oDC tagje, az <o5.212> csak a descriptionbe kerül bele, nem a tag része
<oDC V:5.3,M:A,H:0/0/5,S:6> --- ez pedig az oDC 5.3 tagje, láthatóan nagyban különbözik az elõdétõl, itt már a descbe nem kerül bele külön a <o5.3>
<oDC V:5.3,M:A,H:0/0/5,S:6> --- ez pedig az oDC 5.3 tagje, láthatóan nagyban különbözik az elõdétõl, itt már a descbe nem kerül bele külön a <o5.3>
Az alkohol öl, butit és gyomorba döntöm.
#10047
Acer azért, mert az 5.3-as odc nem csinál dc++-os taget, hanem oDC-t ír a ++-ok helyébe.. gondolom, majd a botokon variálnak egy kört, hogy be tudjon menni az új odc is (ha valóban ez a gond, amit most kitaláltam a levegõbõl :) )
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10044
Szia,
téged is arra szeretnélek kérni, hogy egy kicsit pontosítsd a hibajelenséget.. a hublista nem jön be? vagy ha hubra fel szeretnél lépni? (ill melyiknél fordult elõ pl.)
téged is arra szeretnélek kérni, hogy egy kicsit pontosítsd a hibajelenséget.. a hublista nem jön be? vagy ha hubra fel szeretnél lépni? (ill melyiknél fordult elõ pl.)
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10041
< magyar >
http://dcinfo.sytes.net/hungaryhublist.config (aktív)
http://guinevere.no-ip.org/hungaryhublist.config
http://b-team.tx.hu/hungaryhublist.config
http://divxvid.uw.hu/HungaryPublikusHublist.config
http://free.x3.hu/bflash/HungaryHubList.config
http://vnet.hu/csonti1/hublist.config
http://hwb.dyn.hu/PublicHubList.config
http://dcinfo.sytes.net/hungaryhublist.config (aktív)
http://guinevere.no-ip.org/hungaryhublist.config
http://b-team.tx.hu/hungaryhublist.config
http://divxvid.uw.hu/HungaryPublikusHublist.config
http://free.x3.hu/bflash/HungaryHubList.config
http://vnet.hu/csonti1/hublist.config
http://hwb.dyn.hu/PublicHubList.config
\"Nem a hideg, kevély világnak, Neked szántam regényemet. Bár adhatnék a hû barátnak Ennél méltóbb hûség-jelet.\"
#10035
Szia,
Ez a hiba nem a hublista miatt van, csak a DC nem szereti a gépedet :D vagy oxigén ...
Próbáld meg letölteni az újabb (vagy ha a legújabb van, akkor az eggyel régebbi) verziót, hátha abban nem csinálja...
Ez a hiba nem a hublista miatt van, csak a DC nem szereti a gépedet :D vagy oxigén ...
Próbáld meg letölteni az újabb (vagy ha a legújabb van, akkor az eggyel régebbi) verziót, hátha abban nem csinálja...
Magyar BCDC++ honlap: http://bcdc.dccafe.org Magyar LUA fórum: http://ro.4242.hu/cgi-bin/yabb2/YaBB.pl
#10031
Lenne egy buta 5letem a többszálas problémára. Mi lenne ha a maximális letöltési szálak száma az upload slotokkal megegyezõ lenne mindig? Esetleg valamilyen szorzóval lenne maximalizálva (pl. upload slot x 1.5 esetleg 2). Az elsõ változattal el lehetne érni, hogy mindig legyen szabad slot, és senki se tudja "leharácsolni" a hubokat.