On Tue, 12 Jul 2011 21:28:13 +0200, Heinrich Mueller wrote: > 500 is obvious. The server doesn't support the command. If so, > the program barfs atm. As I said, experimental ;) > I think I'll put it into another branch.
Please do. That way we can test different builds as our personal time allows, then switch back to a more-proven functioning version for regular use. > On 07/12/11 08:58, SciFi wrote: >> (b) With my world-wide Usenet subscriptions at Giganews (primary) and >> Astraweb (fallback) both, no red-flag warnings were seen, but we >> also saw *no* updates in the newsgroup-subscription panel at all >> -- none were bold-faced, none had '(numbers)' after them, etc. >> This also was the result at Gmane, together with the already- >> mentioned red-flag warnings in its log. > I tested it with astranews and it worked, so I can't guess what's wrong. As for Giganews, the only public article I could find is here: <http://www.giganews.com/accelerator.html> They do mention Newsbin there. I wonder if I should open a support request to see if they are doing this compression in the XZVER/XZHDR methods as Astraweb has documented? > Thank you for your feedback, much appreciated. > I can't recreate your yenc-error, sorry. I up'd the bytes-per-file spinner way-way-way up there, to ensure the files would be posted as one single slice each (I knew they were very small files). >> Also, my text introduction was repeated for each file in separate >> postings, with no Reference line(s) joining the messages themselves >> (while the proper Reference was included to follow your original >> posting only). > Well, how many references would you like? GNKSA says the limit is > something around > 936 chars, so this would be impossible for large upload queues. Or am I > understanding > you wrong?? Please disregard what the GNKSA says about Reference lines. I believe there is no _effective_ limits in the NNTP protocol for these, since each header-line is "continued" to the next line by adding spaces/tabs to the first part of those line(s). But *EACH* Message/Reference ID *STRING* might have a server limit. However, don't confuse these two aspects, please. ;) > I _could_ do as you suggested as an option, to let the user choose the > repetition of the > initial message in the posts or just the first, or let the message be > seperate from the > binaries. I don't know what's better, yet. For the "all-in-one-post" version of "multi-file" postings, I kinda view this as what a PowerPoint™ presentation might look like: ---MIME-separator--- content text/plain initial message text etc. ---MIME-separator--- content octet-stream (or PNG-img or whatever) encoded data for the first file ---MIME-separator--- content octet-stream (or whatever) encoded data for the 2nd file ---MIME-separator--- etc etc etc … just as MIME is used in e-mail to provide all the parts of the whole message, esp'ly in HTML e-mail (gfx/pictures/etc), see. This was what I was hoping for the two files I tried to post. yeah I know this type of post can get awfully complex, that's why there are specialized apps for this kind of stuff ;) As for the other kind of "multi-file" postings, think of it as the usual big massive binary postings, perhaps a RAR-split collection of files comprising a 700MB AVI for example. (yencee allows an initial text-mode post ahead of the binary posts, separated and not even Reference'd, as a "subject.nfo" file type thing. I'll try to binsearch for such a post I did with yencee, I'll send another message with the nzb for it.) I haven't studied to find out whether all of the subsequent article-sized slices need the entire wad of Reference lines to keep everything together. I kinda think it only needs to reference the immediately-preceding ('just posted') Message-ID, and not _all_ of the preceding ones that form 'this' file (RAR-part). Much simpler in this case, of course. Visually: file.part01.rar (01/10) (first article-sized slice) file.part01.rar (02/10) (2nd slice, needs to Reference the ID for 01/10) file.part01.rar (03/10) (3rd slice, needs to Reference the ID for 02/10 *and* 01/10??? i think it only needs to reference 02/10 only) …etc… >> These files should have been small enough such that they won't need the >> "part" designation, based on the Preference setting (byte-count per file). >> -OR- >> There is no proper yEnc "ending part" to say there is no more. > > UUEncodePartial appends a part counter for every upload, but I _could_ > change that. As I eluded, pre-determine the small file is a single-part piece entirely, not needing any "slices" at all, (comparing to the bytes-per-file setting), or be sure the single piece is completely self-contained including any "ending" gizmos to tell the downloading app there is nothing more needed. I think this latter mode is what got my posts into trouble, yydecode was quite emphatic about the missing "ending" gizmos ISTM. Again, look at yencee-at-Sourceforge, it seems to be doing the first mode properly i.e. it does not create "yEnc part=#" slices if it is the only piece. It is imperative we get any/all encoding methods working as expected and as compared with the tried-&-true apps already out there being used esp'ly by the wynderz™ people. > I'll try and fix those bugs. (And read your mails thoroughly this time ;) ) Upload test messages, download 'em as original text mode, use different tools (try using yydecode and yencee etc.), use other newsreaders to ensure they like your test-posts (other volunteers can do this), tweak things as you go along, and study-study-study. ;) > See you. Hollar if needed. Thanks much for taking time for all this. :) _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
