JBinup Problems

I know this program is still 'beta', and I've done various tests on small to very large postings, but...

It appears to have major problems in 'validating' some parts here and there. At first, I was able to simply 'set status to... upload successful' in order to get the program to generate the nzb, simply because no matter how many times it 'attempted' to re-upload a particular part, it would simply fail again.

Now I've run into an upload failure that won't 'cure' by setting the thing to 'upload successful' as that option is 'greyed out'. Once again, no matter how many times I try to get it to re-upload, it fails once again.

Anybody know the 'trick' to get it to first, generate the nzb without all the parts perfectly 'aligned' (in usenet, there is NO SUCH THING as 'perfect'!), or another trick to get the program to somehow accept a failed upload and generate the nzb.

Really at a loss here.

Try the english language support forum at: http://forum.jbinup.com/

No such help there.

I've come to the conclusion that whoever is running this program has 'farmed out' the programming duties, as I'm getting several icons that nobody there seems to recognize. 'Left hand not knowing what the right hand is doing' syndrome.

I'll continue beating on it, but it's pretty close to getting shelved and PowerPost getting taken off the shelf and pressed back into duty.

This site s/w is double posting; hopefully, this will not double-post as well

Lol...

Some preliminary deeper testing of JBinup has shown that the problem is really deep in the logic of the program; doing some basic testing where the posts have a particular data stream in them (easily done by generating files with specific stream sequences) posting failure(s) can be induced.

Taking the same stream and posting it with that old standby, PowerPost, does not yield the same errors (random skipping of particular parts of a multi-part message).

Of course, when JBinup does it, it won't 'qualify' the posting, no matter how many times one re-posts it, and of course, without doing so, one can't get the program to generate the nzb. At a minimum, what they need to do is allow users to generate a 'pre-posting' nzb in addition to the 'post-post' 'qualified' one. But hey, that's just a suggestion.

Some testing will continue, but I've pretty much confirmed the error(s), and where they're coming from.

Since I keep several block accounts open, I've noticed that a LOT of bugs happen only with a particular combination of software and provider. Swapping out one or the other often solves the problem.

It might seem a bit odd with such an ancient protocol as Usenet, which we'd expect to be a universal standard by now, but it seems that every provider tweaks their servers a little differently, leaving newsreader developers scratching their heads, and putting the onus on them for having to adapt to the whims of various server admins. So I never assume that the fault lies completely at my end.

Of course there are other factors that can cause bug-outs like article size, or the subject title's length or use of non-recognized characters.

One particular problem, that does cover quite a few threads on their message board, is getting 'confirmation' when the posting server is changing or modifying the message-ID,

It's been just about forever since I actually last ran a usenet server (circa 1996), but lots of operators even back then (way before digital video started swamping things), that the ID message string was too small. Now were well beyond that point, where some operators have long ago modified their programs (the usenet operating rules having been changed) to handle many more (10^whatever) ID's.

Some didn't move fast enough, and are still trying to 'catch up'. Astraweb is probably the most major of those, and JBinUp ran right into problems with them.

But you're right, 'one would think' as old (and a bit creaky) as all this is.... but one does have to remember that it wasn't designed to do binary transfers in the first place; judicious use of pars and posting folks 'watching' their uploads (from downstream of where they're posting at) in simply good practice.

I suggest YencBin Poster it has been working flawlessly, for me anyway :D

camelsystem powerpost is the most updated version of powerpost as far as i know and works great http://powerpost.camelsystem.nl/e-index.shtml

Quote:

---

YencBin Poster

---

Easy Usenet Uploader created by the same author is better and less buggy than yencbin poster

PS

Funny thing.. ive just tested easy usenet uploader(EUU) vs camelsystem powerpost(CP). 20(and 12) connections in EUU vs 12 connections in CP

EUU didnt manage to get upload rate higher than 3.0-3.2MB , CPP on the other hand did a great jog of achieving 4.8-4.9MB

What got me going on this JBinup was the built-in SSL; I have s slew of PowerPost variants, but hadn't heard about this Camelsystems one.

I've had the stunnel on a machine for quite a while, but it's my most pathetic machine (horsepower wise, a Duron just about 0Mhz!), that was simply crawling along, but I'm working toward swapping things around a bit the next couple of weeks, and will be putting an Athlon64 (2.8Ghz) machine into that spot.

So maybe stunnel will work better when I get through getting a new machine built (to take the Athlon's 'spot') and pull the current 'posting' machine out to my junk machine pile.

Good idea. Funny how some people use their old ready-for-recycling computer for uploading files :P

Not wanting to kill another hard drive, I used to use an old PC I got out of a garbage heap for seeding on eDonkey. Of course Java applications never seem to work well on old PCs; it couldn't use Limewire.

One reason I have not posted binaries in awhile is because this PC has a strange (hardware-based) crashing problem and I don't want to crap up usenet with incomplete/corrupt articles whenever it crashes.

Well, usenet posting is a pretty low-intensity task (or should be!), that old machine only has 200G of hd space, 512M of ram, running w2k (although as does the machine that will replace it, solid as a rock), but another bottleneck is that it's only 100Mb/s Ethernet port, when virtually my entire network is gigabit (only a couple of boxes, non-pc's, are not).

We shall see, after I get through 'invigorating the economy' and have this new machine built (6core FX Phenom), still wrangling with the basic hard drives to go with it (right now, twin WD 1TB 'black' SATA3-6gb/s).

I wonder if Windows 2000 might be the problem. Most applications are not tested on old operating systems by the developers, and often times, not enough people use them to report problems. Even old versions of XP sometimes don't work well with recent versions of certain apps, as I've painfully discovered. Also consider that Powerpost was around during the Win2000 era while Jbinup was more recent.

I'm the author of yEncBin Poster and Easy Usenet Uploader and I can confirm that a program can work perfectly with one newsserver and has a lot of problems with an other newsserver.

Also, upload tools are not updated as often as download tools (newsreaders). One of the reason is there's less interest in upload tools. If you go to the JBinUp or CamelSystem PowerPost forum, the first thing you'll notice is that these forums are almost dead with about 1 new thread/reply (or even less) a week. The forums for newsreaders like Newsleecher, Alt Binz, SABnzbd+ and NewsBin Pro are a lot more active. Nobody really tries to help to improve the upload tools, so programmers eventually start to lose their interest in the project and do less work/updates. This is also the reason why I quit developing yEncBin Poster and Easy Usenet Uploader.

To answer Hypatia reply about Easy Usenet Uploader being slower than PowerPost.... PowerPost is written in C++ and is multithreaded. While uploading one part to the newsserver a new part is read and yEnc encoded in a separate thread. In other words, the program can keep uploading without interruptions.

Easy Usenet Uploader is written in the old/ancient VB6 that does not support mulithreading. This means that a part is read and yEnc encoded and then uploaded... a new part is read and yEnc encoded and then uploaded... etc, all in one thread. While reading/encoding a part the upload is halted for a fraction of a second, because it can only do one thing at a time and this causes the overall upload speed to be slower when uploading with a very fast internet connection.

It's s pretty bad situation. I came back to this thread after quite a while, simply because of all the (censored) crap going on right now just because Giganews decided to go off the tracks, and too many providers out there are too tightly wound up with them.

There MIGHT be more 'traffic' on the JBinUp and Camelsystems forum, IF they would actually spend the minimal amount of time/effort to translate their log-in process to English. Unfortunately, the Dutch is just too far off from it's roots in German to be possibly figured out, even with my current pathetic (it's been 25+ years) German ability.

The Camelsystem Powerpost looks to work fine in non-SSL, but the SSL is not working, and the 'documentation' is nill. The JBinUp simply has too many errors going on to use in any consistent way. So, it's kinda back to ground zero.

I think that overall, it's simply cases of programmers (professional or not) simply thinking that their code is without error, or why would they not write any clear documentation?

Add: BUT, if I had not spent time and effort trying to get stunnel originally working with PowerPost, I wouldn't have been able to figure out what was going on. BUT, it's still pretty easy to 'confuse' Camelsystem Powerpost , I'll wait and see it it will recover decently from continually trying to post duplicate message ID"s... that plus eating up CPU cycles like mad I'll have to do yet more extended-term testing to see if the machine will hold up to such 'abuse'..

Hey Beck, before you give up, you might want to know that Usenet Explorer (usenetexplorer.com) offers a free text/binary poster. I'd be very surprised if it doesn't work perfectly for you when posting binaries using SSL and multiple connections. Did I mention that Usenet Explorer is a highly advanced, extremely configurable, feature-packed, well-coded (low resource load & bug-free) software application?

Depending on your level of "geekiness" - you will either love Usenet Explorer or hate it. :)

From the website:

Quote:

---

Free poster

The program contains free text/binary poster, also related functionality like newsgroup list related is free. The reason for including it as a free tool is existing widely used poster 'powerpost' is terrible by introducing options that may puzzle text newsreaders by forming invalid subjects and arbitrary placing references which isn't used by binary downloaders anyway and has backlog of all kinds of problems.

The poster can post par2 sets, nzb and sfv files, for posting par2 it seamlessly uses par2 command line client. Other features are reposting segments/attachments, retrying posts reposting only failed segments, post task persistency between sessions, simultaneously posting several posts each to its own server (but still not suitable for sending spam), remembering prior posts etc. See the post menu and edit menu->properties->posts for related settings.

---

If you download the 2-week "trial" version, it eventually turns into nagware whenever you start it, but just hit the "post" icon on the toolbar at the top and the nag screen immediately disappears, and it allows you to post indefinitely.

I've taken a look at just about everything, I'll try that after I get through my latest 'push'...!

Right now, I have two machines in the 'service bay', one that got hammered by an anti-malware program (Malwarebytes) that I couldn't quite figure out how to recover (so, invigorate the economy and give the local pc shop a few bucks), plus my new 6core machine with Win7 I toyed with for a couple weeks before coming to the conclusion that once again, I need to wait until M$ gets it's act together and releases at least one service pack on... (having it rolled back to, yes, Vista, which I have working excellently at this point on another machine, again, after the two service packs).

But as I 'skipped' getting into Vista in the 'early' days, I got a good shot at what folks must have been going through, and IMHO Win7 is 'not ready for prime time', at least for the simply applications I need it to run.

@Beck38, which applications don't you have running on Win7 that seem to run fine on Vista. In no way can I offer help, I'm just curious. I advocate Win7 over Vista to anyone that asks, I'm the tech go to guy for everyone I know, but I wouldn't mind being enlightened in the opposite direction. I have all 3 systems at my house running Win7 64 bit, I was honestly convinced since RC phase to switch away from XP. But you'd figure with a Win7 64 bit system, I'd come across the most difficulties with the plethora of stuff I have running at any given point. You don't think that for your AVERAGE user, Win7 is prime time (considering average user doesn't run a lot of complicated software)?

Back on topic, I've been using Camelsystem Powerpost and haven't had any issues thus far. It works well enough that I haven't even considered finding a different posting prog. Does any other program out there offer advantages over CP that anyone has experienced?

The biggest thing is that JBinup has SSL 'built in', and I found long time ago (and again with Camel/Powerpost) is that stunnel grabs a whole lot of CPU cycles (although both it and the CPP are 'light' in the ram dept.). Of course, the machine I use to post on is a absolutely pitiful 1.3Ghz Sempron, that I wanted to send to the old heap and replace with a 2.8Ghz Athlon64 (but it's the one that got nailed by Malwarebytes!).

Now, back when I had a fairly low-speed DSL line (768Kb/s upstream), it wasn't a problem. But it was Verizon, and they quit my area a couple months back, the 'replacement', Frontier, has 5GB caps on it's DSL services (and no real commercial service). So, the only way to go was with Comcast and a good VPN service on a commercial circuit. It actually came at about the right time, as the HD stuff was really coming together, and I needed LOTS more bandwidth.

The new 3.2Ghz PhenomX6 is to go into MeGUI HD/x264 production. The big problem with Win7 is that they 'thought' (M$) that making the HD codecs a part of the OS would make things 'easier' for newbies, but makes it deadly for anyone who knows what they're doing and needs/wants to run something other than M$ 'certified' codecs. Which is what one needs to do with MeGUI.

That, plus they again 'thought' that doing the same with networking was the 'way to go' as well. I have a very diverse network, including quite a few machines running W2K, the operating system of choice for over 65% of the world's PC's. Win7 won't play well with it at all. Okay with Vista, and I'll presume XP (but have never had that in my network), as well as major problems working with my PCH (popcorn hour) boxes.

So, with those two marks against it, for my network, it was a real bust, and as it was built especially for the first (MeGUI), it's a killer.

My other 'big' machine is a PhenomX4 Vista (3.2Ghz as well), runs MeGUI just fine, but has other 'duties' to perform as well, so that's why the 'new' X6 machine, with the newest MB/chipsets, twin SATA3 drives, tons of superfast ram and such. Now if I can get the Vista and get MeGUI loaded up and 'into production', I'll be a 'happy camper'!

-Actually I remember I never got SSL setup for CP, so I ignored it after that.

-Hmm, I've got MeGui running quite nicely with Win7 64, similar to one of your machines with the AMD Phenom II 955 BE powering it. As far as the codec issue goes, having control over directshow filters is key, and I haven't run into any issues using Shark007 to manage that (did it to make sure everything runs in MC7, but I would say it's accessible to novice users).

-I will agree with you on the networking and Popcorn Hour issues. Some people have gotten their PCHs to work out alright with Win7 systems on the network, but for my setup, there doesn't seem to be anything I can do to have it browse SMB. However, as long as I remember either the local IP or client name, I can find the PCH on the network, and I use share links on the PCH to see things the other way around. With so many workarounds, it isn't good for the novice user. Isn't Vista networking pretty much the same though?

Microsoft networking has been in the same schema ever since Win95, same through NT, W2K, XP, and Vista. Then in Win7 they decide to go 'off the tracks' and again, try to make it 'easier'. Heck, it was easy in the first place! I'm sure that come around the time of the first major 'tweak' with service pack 1 (supposedly next spring?) that it will be fixed. Bottom line, I spent 2 weeks trying to make it work, my shop spent another 2 weeks trying to make it work...

And Nada. Now, I'll admit my skills aren't anywhere near 100% (I've been retired for 8+ years now), that's why I had the shop take a wack at it. Same with MeGUI. Yep, lots of folks our there running just peachy with Win7 (and I got it working right away on my 'older' Vista machine) but neither I or my shop (3 to 4 top line certified techs) could make it work. I talked to a 2nd shop, some 30 miles from me (that figured out some real toughies for me in the past, considered the best shop in the 11th largest city in the U.S.), and they won't touch Win7 for any of their corporate customers. Vista Only.

And this is in Microsofts back yard! It comes back to that old adage, wait until at least one service pack on any Microsoft OS's. There have been a fair amount of folks that have reported (witn MeGUI), that they had to reload the OS several times on a machine to get it to work, and maybe I got caught up in that inconsistency, but if so, I'd be wondering what the heck is lingering in that box ready to bite my rear! So way fool around with it any more? Four weeks already down the drain, Get Vista and be done with it. The machine I have with it, and service packs 1 & 2 plus all the .net framework stuff, runs beautifully. I wonder if Vista had been this stable and nice upon original release..... naw!

Oh well, it'll all get sorted out at some point. Maybe. What a Mess.

Quote:

---

Originally Posted by Beck38

...
I have a very diverse network, including quite a few machines running W2K, the operating system of choice for over 65% of the world's PC's.
...

---

Source please? According to w3schools, the market share of Windows 2000 is 0.4% worldwide :P. http://www.w3schools.com/browsers/browsers_os.asp

I have been using YENC with SSL forever....

Nice little guide i wrote, and is a pretty simple setup....

I agree on the market share of Windows 2000, no way that many people use it, if anything it's still XP, and I"m sure 7 is making it's way to the top, can't see anyone using Vista still...except my dad :P

- Beck,did you update your jvm to the latest version which is: Java Runtime Environment 1.6.0.21 (http://www.filehippo.com/download_jre_32/)
- The latest version of JBinup is NOT XP/2000 friendly,unfortunetely.You need to use the penultimate one wich is: 0.90 Beta 7
PM me if you cant find it.
Can't believe the pbs you're running into !

I just thought I'd mention an additional add-on for your toolbox. A few weeks ago Bintube released what they call a "download accelerator" -- basically a localhost proxy that works with any news client. I'm not sure exactly how it works or just what it does, but it might be worth looking into.

Maybe it's something like Giganews accelerator or Stunnel, perhaps? It claims to compress headers, for instance, but does not mention how many of the three (or four) different header compression standards it supports.

http://www.bintube.com/accelerator.asp

Of course, when faced with a bit of a problem, I don't quit trying....!

Over the past several weeks I've been trying different 'flavors' of things, different usenet servers, different uploading s/w; found that of all the PowerPost 'clones' out there with 'more than 4 threads', that Camelsystems worked pretty well (12 threads with SSL via stunnel) but minor glitches drove me back into looking at the JBinup once again in the 'hunt' to get it to operate better.

I'm really unable to 'upgrade' (a misnomer if there ever was one) to a 'newer' OS than w2k, as the machine I'm uploading from has other 'uses' which require it and do not operate (i.e., never upgraded by the programmers) to work with Vista or (yuck) win7. (yep, I know the yuck factor was through the roof on Vista in the early days, I'll try Win7 again when the first decent service pack is out next year).

BUT, I found that despite early problems with Astraweb (due to how their message ID system works vs. newer systems with much longer ID strings), that fixes made it work super great. What was giving Jbinup fits was the high latency posting to servers a continent away or more (upwards of 20 hops, high ms delay, etc.), and using something much closer (Astraweb on the US west coast, just a hop (haha) skip and a jump from me internet wise), calmed it down 100%.

I wonder if the developers of JBinup tested it out with 'lousy' connections...!? Since it comes out of Europe, what they needed to do is test posting through multiple trans-oceanic links (submarine fiber) to see how it dealt with (or not) high levels of latency and such. It seems to be a bit too sensitive, even with setting the 'check' settings pretty far 'back'; I did some testing with a dual server type configuration (check server different than the posting one), but since it started working so well with a 'close' server, I put additional testing in that area 'on the shelf' for a bit.

Keeping my fingers crossed, but it seems extremely stable, again, with a 'close' server.

Bit of an Update:
Finally ran into some transmission problems, as a couple of the routers in my path to the usenet server went off on a tangent.... BUT, JBinup managed to recover with no lasting problems. I watched somewhat closely for a couple of hours, saw another 2-3 'hiccups' with those routers, and again, JBinup had no real problem recovering, and making the upload 'perfect. It was somewhat of a sight to see, but again, this was with a very close server. If it would just work like that with something a continent or two away, it'd be great!