Dit is ons idee hoe het met yEnc-uploads in grote lijnen in elkaar steekt. ========================================================================== ## LEES ONDERAAN VOOR EEN STRUCTURELE OPLOSSING BIJ DOWNLOAD-PROBLEMEN! ## Sinds vele jaren gebruiken we de yEnc-methode om binaries (digitale data bestanden) op usenet te zetten. Usenet is namelijk een tekst-medium. De bestanden moeten zo efficient mogelijk gecodeerd worden, vandaar yEnc. Aan de download-kant wordt dat dan weer netjes gedecodeerd. Zie http://www.yenc.org/whatis.htm voor meer (engelstalige) info. Daarnaast verdwijnt er wel eens een stukje (een article, zeg maar een klein stukje van een bestand). Daar worden dan PAR2-bestanden voor gebruikt om een en ander te kunnen repareren (meestal door de newsreader die ook de download op zich heeft genomen). Zie http://www.quickpar.org.uk/ voor info over de moeder van PAR2. Helaas helpt dit niet tegen 'Takedowns' (N&T) door bv. BREIN en de DMCA. De essentie is dat alles goed op elkaar afgestemd is. Dat maakt de kans op een succesvolle download het grootst. Gelukkig werkt het meestal ook wanneer het NIET goed ingesteld is, met merkbaar meer gezeur op Spotnet. Maar in moeilijke situaties kan het een verschil zijn tussen een download 'lukt net wel' of 'lukt net niet'. -------------------------------------------------------------------------- Het idee is eigelijk heel simpel: 1) yEnc werkt met 'regels' van 128 bytes. Om praktische redenen werken we met een veelvoud van 1000 regels, ofwel veelvoud van 128000 bytes. In dit verband zijn 3000 regels (384000 bytes), 5000 regels (voor 640000 bytes) en 6000 regels (768000 bytes) populair voor DSL-internet. Leuk in de vorige eeuw, maar nu een beetje achterhaald. Anno 2021 is 'minder dan 8000 regels' eigenlijk respectloos (lees: er zijn onnodig veel articles nodig om iets te posten). Gezien er dan meer gerepa- reerd moet worden bij problemen. Helaas gebruiken alle yEnc-tools de 3000 regels (omdat het dan 'altijd' wel wel zal werken). Voor highspeed internet is 'groter is beter' van toepassing. Zo zijn dan 15000 regels (1920000 bytes) of 24000 regels (3072000 bytes) dus (veel) beter. De praktische limiet ligt bij 30000 regels (3840000 bytes), maar niet elke newsserver kan daarmee overweg. Ga voor 15000/1920000! We gaan even uit van die 15000 regels (1920000 bytes), want dat is prima in te stellen in bijvoorbeeld "Camel Powerpost". Dit zelfde aantal regels MOET dan ook ingesteld worden in QuickPAR (of in bijvoorbeeld MultiPAR). 2) Wanneer die 15000 regels in QuickPAR is ingesteld, dan geeft dat reparatie 'blocks' van 1920000 bytes. Nu is er al jaren gedoe over 'hoe groot is nu een MB'. Wat een bron van misverstanden geeft. Daarom schrijven we de boel in Bytes (met grote B), dan is er geen enkele discussie of misverstand mogelijk. 3) De RAR-bestanden moeten een geheel veelvoud zijn van die bovenstaande 'blocks'. Zoals RARs van 57600000, 115200000 of 192000000 bytes. Dat is dus GEEN 57 MB, 115 resp. 192 MB! Pas in WinRAR de grootte dus aan naar Bytes (beter, stel die of 115200000 bytes als standaard in). -------------------------------------------------------------------------- Laten we eens een volledige DVD5 onderhanden nemen (die is 4700000000 bytes groot). Daar laten we WinRAR op los, om bestanden te maken van 57600000 bytes. Dat geeft 4700000000/57600000 = 82 bestanden, waarvan de laatste iets kleiner is dan de rest. In QuickPAR of MultiPAR openen we die 82 bestanden, overtuigen ons ervan dat deze het geheel ziet als rond de 2400 'blocks' van 1920000 bytes en maken dan bijvoorbeeld 240 reparatie 'blocks' (10%), beperkt tot het grootste bestand (zodat de PAR2-bestanden handzaam blijven). En dan openen we dat geheel in 'Camel PowerPost' om te posten. Laat PowerPost NIET zelf de PAR2-bestanden maken, gezien jij de baas bent. Ofwel, goed rekenen (goede voorbereiding) is het halve werk :) Dit is HEEL BELANGRIJK bij grote uploads. Dit zal een HELEBOEL TIJD schelen bij het aanmaken van de PAR2-bestanden (efficiente blocks, met een groot aantal blocks, toch sneller klaar). Articlesize = Blocksize Blocksize = M x 128000 bytes (waarbij M een geheel getal is). RARsize = N x Blocksize (waarbij N een geheel getal is). In bovenstaand verhaal gebruikten we M=15 en N=30. Want 15x128000=1920000 en 30x1920000=57600000. Gelukkig werkt yEnc ook wanneer de instellingen NIET optimaal zijn. Met een grote(re) kans kans dat een download niet lukt. -------------------------------------------------------------------------- We zijn niet op de exacte details ingegaan van bv. WinRAR, QuickPAR of Powerpost. Het gaat ons om de essentie. Uploaders (posters) weten al hoe hun programmaas werken (nemen we maar aan). Het is simpelweg een kwestie van de getalletjes goed zetten! En DAAR gaat het bij vrijwel IEDEREEN niet goed, ook niet bij de 'grote jongens'! Want die gebruiken de 'standaard' instellingen of 'doen maar wat', want 'het werkt toch wel'. -------------------------------------------------------------------------- Zie ook http://www.pfcorner.nl/Spotnet/ hoe je een mislukte download toch (toch) compleet kunt krijgen (en nog gratis ook). Je kunt ons bijvoorbeeld vragen (per email) voor extra PAR2-blocks. Beter is natuurlijk om je huidige usenet-aanbieder in de wilgen te hangen, om over te stappen naar PFCorner. Want voor vrijwel iedereen kunnen we iets voordeligers leveren op een (veel) hoge(re) snelheid. Zie daarvoor http:/www.pfcorner.nl/ -> Prijzen (zoals "BULK"). Wat ook kan is om NAAST je huidige aanbieder een accountje van ons in je newsreader (bv. SABnzbd) te zetten als backup. Dan ben je met onze services (vrijwel) zeker dat alles te bekomen is van Usenet. --------------------------------------------------------------------------