Posting OTR to the binary groups is largely "poster's rules" (ie, the
poster makes the rules and the rest of us practice being grateful :-).
Still, you may want to consider some of the following info I've picked
up over the past few years. These are not formal rules but ideas and
suggestions. Corrections and additions are welcome.
understand that your uploading will likely go slower than your downloads This is because broadband connections usually have wicked download
speeds, and upload speeds that are a fraction of that speed. Sometimes
1/10th the speed of the download. So allot a chunk of time to the
uploads. Using yEnc can alleviate this somewhat.
understand that your uploading may affect the speed of
your other network traffic Your browsing or other activities may be impeded. I queue my uploads
on a timer (with PowerPost) so they go out at night when I'm not trying
to use my feed.
understand that you may spend more time servicing repost requests than uploading
Timely requests are fairly simple to handle; you've probably still got
the CD mounted in your PC. Some people will ask for reposts too early
(within a couple of hours) before the segments have had time to propagate.
Some will wait for two weeks, so you've already put that CD back in
the cabinet. Some people will say "I was on vacation; can you post all
50 CDs again for me?" Uh, no. Some people will give less-than-useful
information like "can you repost one segment of that file from last
week?" when you've posted 100 files since then.
You may want to come up with a policy on this stuff ahead of time
(see the section on 0-files) just to manage expectations and keep you
from wanting to strangle some poor soul out there on the net.
understand that you can't make everyone happy.
No good deed goes unpunished: there is no upload so well-intentioned and
well-executed that somebody, somewhere can't find something to complain
about.
Posting can
be a thankless pain (or you may be surrounded by happy fans). Set a
comfortable pace so you don't get burned out or attract the ire of your
ISP/news provider.
pick the right group for your posts
alt.binaries.test is for testing. This is where you test your setup before posting to the OTR newsgroups
alt.binaries.sounds.radio.oldtime is a main posting group.
alt.binaries.sound.radio.oldtime was something of an accident (typo) is also used for posting. Sometimes it is used for floods (large posts that would "flood"/overrun the usual group).
alt.binaries.sounds.radio.bbc is where you find BBC stuff. Lots of high quality drama; check it out!
alt.binaries.sounds.radio.misc is for radio shows that don't fit elsewhere
alt.binaries.sounds.mp3.spoken-word is for audiobooks, etc.
alt.binaries.sounds.radio.highspeed is for massive floods, typically entire CDs worth. It is for those that have broadband connections.
alt.radio.oldtime is used for discussion. It is not used for posting binaries.
limit your daily volume to a sane amount.
The figure ~70MB/day is most often cited for
non-highspeed groups. This limit does two things: it
keeps us from providing more stuff than can be downloaded (especially
for dialups) and keeps us from pushing other shows off the server (news
servers have per-group limits based on size or number of articles).
If you push too hard/fast you'll spend the next two weeks handling repost
requests (see below).
use posting software that allows for segment reposts segment reposts are vastly superior to whole file reposts because you are reposting only those portions which did not propagate for the user. This is one of the major ways you can help conserve the Usenet resource. It's not limitless...
The most common tool for posting is PowerPost. See notes about yEnc below, however. The original tool for doing segment-based stuff was Peck's Power Post. Uuencode only, and an little clunky but sometimes better for some stuff.
Here's an introduction to posting with PowerPost
My zero-files state segment reposts only; if users ask for a file repost I reply "Which segments?" Either they specify the segments or they don't answer. It's a "win" either way.
Note that this is not some eternal truth: once in a blue moon a
file really will explode and you'll hear from 10 people all saying it
didn't work. That's a good case for file reposting.
Some users will want you to repost entire files or entire floods; I urge you to resist.
Users ask for file reposts because:
the user doesn't know it's possible to repost just the segment they need
the user doesn't realize it's incredibly wasteful to repost all 50 segments when they just need the one...
the user doesn't realize that all newsservers have size, date, or article number limits for each newsgroup and that each repost effectively reduces the newsgroup's capacity to carry new material..
the user didn't read your "segment reposts only" caveat, if any.
If I get a user who needs an entire file reposted, I usually put it up on a website for them. No sense taking up group resources for one person.
Here's how to repost a segment with PowerPost:
select History (Scroll with floppy disc Icon)
select the file[s] and press Queue Selected Files
close the History window
right-click on each file now in the queue
select Task Properties
select Uncheck All and manually reselect the segment[s] you need to post. Close this dialog box.
post away!
I usually leave all the info just as it was so the segment transparently completes the binary. If you change the Subject: line, etc, the users may have to manually pick out the segment for decoding.
use sane segment sizes For normal posting, segment sizes are expressed in lines (3000, 5000, 10000). The larger segment sizes are somewhat more efficient, but risk being rejected by news servers for being oversized. 5000 lines seems to me a nice compromise.
When using yEnc a line limit of 3000 or so is usual because the lines are longer and you can run into oversize issues again.
Note that some clients and protocols express their segment sizes in KB rather than lines.
UUencode or yEnc UUencode has been the traditional way to encode files for transport. UUencode generally inflates the file by about 30% for safe transport; (8bit ascii to 7bit).
In the last year or so yEnc has becoming a controversial but increasingly popular encoding scheme. It is loved because it does not incur the 30% inflation; it is hated because it is new and because it was something of a hack.
If you are going to use PowerPost to post yEnc, please use YENC POWER POST 2000 V3 which handles yEnc correctly. Other versions apparently had problems.
Although posting yEnc *can* be faster, it is mainly used for the benefits to the newsgroup itself and to the downloader. If it happens to be faster for the poster, then that is an added bonus.
use descriptive Subject: lines so we don't have to d/l your file to see what it is.
don't .zip/.rar/.par the files. .mp3 files are already compressed, and won't get much smaller. They may actually be larger after the archive overhead is added. The main advantage to .rar/.par processes come into play for very large files like .mpg/.avi files which run to hundreds of MB. Files of our size don't benefit from the .rar/.par overhead and add needless complexity for the user.
use safe Subject: lines
It seems that some versions of (Free?) Agent are fragile where Subject: lines are concerned. See this page on the subject.
warn about re-encoded files Posting upsampled/reencoded files, or mp3 files made from .ra sources can get the locals perturbed in a hurry. If you must do it, at least say so in the Subject: line or 0-file.
include a 0-file that discusses your repost policy
A zero-file is so-called because it precedes your files (1 of 10, 2
of 10) and is usually named by the software as "0 of 10". This textfile
is where info about your post should go; anything too long to go in the
Subject: line. Your repost guidelines, scope of your posting, credits,
requests for fills, pointers to your online trading lists, etc, can go
in here.
You may want to use the 0-file to remind your users to be
specific when requesting segments; otherwise you may get
"hey, can you repost segment 10 of that file you posted last week?"
even though you posted 75 files in that timeframe.
I save my 0-file text in a textfile and paste it into the posting
software.
repost segments with their original subject lines This will allow for seamless reconstruction for the users. This is bulletproof in PowerPost; pull up the file from the History list, requeue it. Rightclick on the file and choose: Task Properties. Select only the segments you want to repost. The Subject: will be the same as the first time it went out.
post using meaningful subject lines At the least include the filename and filesize. That way people can
see if they already have that file before downloading.
Get out there and start posting! :-) Watch for requests, post new/better encodes, and contribute fills when possible. It's really not that much work if you stay organized. Thanks for posting!