Printable View
Blocknews is running a special of 100 gigs for $8.99 for a usenet block. It's limited to the first 1,150 takers. All usenet blocks are non expiring. This is a limited time deal.
http://twitter.com/#!/usenetnow
http://billing.blocknews.net/signup.php
Existing customers can take advantage of this deal by going into their account center and choosing the 100 gig deal from there.
Damn I wish I could jump on this but i am a broke ass bitch right now. :(
BlockNews has been a reliable Usenet provider, and at this price, it's a steal. Thank you. :)
i signed up but getting a lot of incompletes? maybe its jsut the file?
this is ripoff
Great point. Well represented.Quote:
Originally Posted by johhny
As long as binload works , there is no need to pay for usenet
goog luck getting anything beyond 380+days :D
besides,, i like comfort.. and comfort means getting max speed :cool:
You must not know how block accounts work but this was a great deal. Added two to my account before they were gone.Quote:
Originally Posted by johhny
Looks like a great offer, I'll probably buy it.
Anyone remotely interested in a good block account or even just usenet should jump on it.
Too late, they are all gone like a week or two ago.
I just have to post back and say that I've found this to be a complete waste of money. I've never needed a block account in the years I've been using Usenet but I thought with some of the changes coming forth with my ISP that it might be a good idea to get one. I tried using the block account for the very first time tonight to fill in some articles missing from all of the episodes of the first season of Boardwalk Empire.
Generally speaking, Blocknews doesn't have anything I need and their 1100+ days of advertised retention is nonsense. I'm onto the fourth episode I need blocks for, and while Blocknews has had some articles, I have not been able to grab enough to complete any of these episodes.
My immediate impression is this was a total waste of ten bucks.
Who is your main usenet provider could be the same that feeds Blocknews.Quote:
Originally Posted by Skiz
Aren't you the rabid giganews fan boy? Obviously whateve you are using is no better if you have to turn to backup servers so I don't know why you would single out just blocknews when you even said they did hve at least a few articles you didn't. That would tell me they are at least as good or a tiny bit better wouldn't it? ;-)Quote:
Originally Posted by Skiz
I know they were there when I grabbed them sometime ago...which release did you get? I got the immerse releases way back and they worked fine.
Are you saying that all of the episodes you downloaded are so incomplete (on both servers combined) that even PARs won't fix them?Quote:
Originally Posted by Skiz
It never hurts to post some hard evidence. Here is a sample 315 day old release of Boardwalk Empire's first season, first episode:
[47089]-[FULL]-[#a.b.teevee@EFNet]-[ Boardwalk.Empire.S01E01.iNTERNAL.720p.HDTV.x264-SYS ]
and using SuperNZB, its completion checked on Blocknews (US server):
http://i39.tinypic.com/2873hpv.jpg
Not a perfect score, but I think probably MUCH better completion than Giganews on this release, and I'm guessing that these incompletes are different (random) missing articles, compared to Giganews' typical (and predictable) DMCA-takedown pattern.Code:http://i39.tinypic.com/2873hpv.jpg
So assuming that no upload errors occurred when the files were being posted (which would affect completion everywhere) using Blocknews as a fill for Giganews should add up to virtually-100% completion.
Would you care to back up that statement with some actual facts?Quote:
Originally Posted by Skiz
No? OK, so maybe I'll have to provide some of my own then.
Here's a sample 1168 day old file (near Binsearch's limit) in a.b.mp3.audiobook -- still on the server:
The ball's in your court, Skizo :lol:Code:http://binsearch.info/?b=Janet+Dailey_Something+More&g=alt.binaries.mp3.audiobooks&p=nic88%40verizon.net+%28bjgeiger%29&max=250
well.. i dunno about blocknews.. but i ve just checked 334 days posts(the whole first season of BE) on AW
here are results:
Spoiler: Show
But i must say that AW is having completion problems between ~120-260+ days due to their technical fuck ups i guess. But at least hbo shows are not gunned down by mafia
That's what I'm finding, yes. Mainly because Blocknews has nothing. For example, trying to complete S01E04, Blocknews has 1 article. Everything else in the collection turns up as 'Article Not Found'. E05? Blocknews had 2 articles. Etc...Quote:
Originally Posted by zot
I can't see whatever image you've posted.Quote:
Originally Posted by zot
Giganews has completed most of the collection. As stated, Blocknews could not offer enough to complete, and certainly was not "better than Giganews".
Attachment 91594
huh? do you mean only 1 article for the whole episode is available on BN?Quote:
trying to complete S01E04, Blocknews has 1 article.
Then what does the picture you posted above show? giganews? im a bit lost
Yes, for S01E04, Blocknews had 1 part. For S01E05, Blocknews had 2 parts. All the others came up as 'Article not found'.Quote:
Originally Posted by Hypatia
The above screen is what Giganews was able to complete on it's own.
For that post try Astraweb or free XSusenet backing up Giganews.
mesamen
thats not the point... seeing that BN has only 1(!) block available is a damn shame. as for xsusnete what one is gonna do when these files are not within the retention of it's servers(~400days)?
also xsusenet is very very buggy (atleast for free usage)
sabnzbd+ says too many connections after a day or two of usage and becomes unusable after 3
so i keep registering and re-registering to make the problems go away
the oldest file i am dling is 348days old
lets see if it finishes correct
Ditto. I think we all need to stop relying on embedding images. (but anyway, why post an image of Giganews' completion - the subject here is Blocknews)Quote:
Originally Posted by Skiz
I can't see Hypatia's posted image either, or the link to that Mysterbin page, so I had to hit "reply with quote" and fish out the URLs from the post text before I could see his Astraweb's completion results, (which at a perfect 100% is impressive). It seems that for the last year or so, Blocknews has always had a few random incompletes throughout its retention range, while Astraweb's completion is either 100% (usually) or ... in the toilet.
I'll repost these possibly-hidden items:
Zot's screenshot of Blocknews completion:Hypatia's screenshot of Astraweb's completion:Code:http://i39.tinypic.com/2873hpv.jpg
Hypatia's hidden link:Code:http://imageshack.us/photo/my-images/213/clipboard02ph.jpg
(I also updated my last post to show that image's download URL)Code:http://www.mysterbin.com/advsearch?q=Boardwalk+Empire+s01*+720p+ctrlhd&match=normal&minSize=100&maxSize=max&group=&maxAge=1194&complete=2
I looked at the release [39281]-[FULL]-[#a.b.teevee@EFNet]-[ Boardwalk.Empire.S01E04.720p.HDTV.x264-CTU ]-[01/43] - "boardwalk.empire.s01e04.720p.hdtv.x264-ctu. posted 394 days ago, completion which is hit *relatively* hard on Blocknews, with Blocknews' completion that looks to be close to 99%. It looks like it has 10% PARS, so it should repair quite easily.
http://i42.tinypic.com/zkizqh.jpg
http://i42.tinypic.com/zkizqh.jpg
According to my completion check above, Blocknews alone should easily complete that file (with pars) that Giganews could not. (assuming that we are both working with the same s01e04 that was posted 394 days ago.) My guess is that you probably don't have your news client set up correctly with Blocknews as a fill server. If you were to disable Giganews, and re-download the file over again using only Blocknews, it should work. It's also possible that you did not grab all the pars (or file segments) that were posted. (I'm forced to make a lot of assumptions and guesses whenever people are unable to detail the problem fully)Quote:
Originally Posted by Skiz
Skiz, whatever the reason for your (Giganews + Blocknews) download failures, the fault does not appear to lie with Blocknews.
(^It's tinypic that's the problem. Even if I click the link, it still doesn't load)
This is odd... If it go to Mysterbin and create an nzb of the 's01e04 ctu 720' release, it will complete. If it create an nzb of the same episode here on FST, I get 1 completed file. Maybe this whole problem had something to do with how FST stores older nzbs? :idunno:
Now my problem is that I can't get quickpar to associate the newly downloaded pars with the previously incomplete set from GN. It sees them like they're from two completely different sets. :dabs:
SuperNZB completion checker
I don't trust its accuracy for any news server. Each time I run it on the same NZB I get different results, and I know it isn't the server doing that.
I think the Giganews/Blocknews combo comes up short on that post, but the only way to prove it is with an actual download.
EDIT:: more...
Parts missing = 1.0%
10% PARS
You can compare 1:1 only if the source block size equals the article size, but in that post it's 9x article size, and the PAR2 files are damaged.
Don't click the link -- copy and paste it. FST creates Stealth-links. Clicking a link will go to Filesharingtalk.com and then get forwarded to the site named on the link, but the process often does not work. This is why I usually create [code ... /code] text to post URLs in, rather than just posting the web address, thereby letting FST alter it. If Tinypic is being blocked for some reason, then one solution is to try a proxy.Quote:
Originally Posted by Skiz
You should compare NZBs. Although it's more accurate to open them and look inside, just comparing the file sizes can be diagnostic: if one NZB is smaller than the other, then something obviously must be missing.Quote:
Originally Posted by Skiz
Whenever re-running a par set after you make any file substititions, you need to go into \Application Data\QuickPar and delete the files that have "boardwalk empire (etc)" in the title. so that when you run Quickpar again, it starts its analysis fresh from the beginning, rather than skipping over the file names it (thinks) it already checked before.Quote:
Originally Posted by Skiz
Sometimes pars get reposted. I don't know if these 'new' pars are interchangeable with the old pars; perhaps not.
On a few rare occasions, I've had to re-name files that looked like they contained the exact same file name, but actually used different text.
Although I've never noticed any discrepancy, I'd like to know how much it might vary between runs, especially if any significant amount. (maybe I need to do more testing) I always welcome someone putting up their own stats that contradict mine. :)Quote:
Originally Posted by mesaman
I use SuperNZB on Readnews servers because its checking engine is much faster than any other NZB completion checkers on Readnews. (I use NZB Download Checker for all other servers) I didn't have the time (or bandwidth) to download the actual file, which of course would have been the only true test of actual completion. So I was giving rough estimates and making assumptions -- which I'd love to see someone disprove my stats rather than just raising doubts.
The main reason SuperNZB completion checker varies between runs is that it randomly shows missing parts in the wrong rows. Also, a timeout, when the Readnews server takes more than 10 seconds to send a response to the 'head' command, is counted as a missing part. Let's assume though that the total is correct and your stats are 1.0% missing parts and 10% PARS. You then assume that the files should repair quite easily on Blocknews alone. Do you understand why your assumption is way off the mark?
I already did that. I had to because you posted it as a code, but it still doesn't load. As I said before I think it's a problem with tinypic. I haven't been able to get that site to load for a couple months now. Sucks, because I have hundreds of photos saved there. :dabs:Quote:
Originally Posted by zot
My guess is that's the issue. I'd already cleared Quickpars "cache" and tried rescanning several times using different naming structures but I can't get it to work. I guess I'll just redownload the entire thing from FTN or something. :idunno:Quote:
Originally Posted by Skiz
Bad news - it seems the 'block' party is over :(
I did more thorough checking, and can say that file was almost certainly DMCA'd off Blocknews/Usenet-News. (i.e., every file in the set has two articles missing) So for this release at least, using Blocknews as a fill for Giganews is not going to help. This is a real game-changer. I've got to take back everything I said earlier, when I believed that Blocknews was (still) flying under the radar.
We've got to assume that more takedowns are on the way. Sad day, sad week. :cry:
@Skiz, this file is complete on free servers xsnews and Binload right now (but might be deleted within a few days)
@Mesaman, I now understand what you mean - the SuperNZB completion checker is full of errors and misses many incompletes.
zot
oh well. should we shoot the messenger? :)
ps ive checked s01e04 ctu on AW -everything is ok.
i wonder how long will it last7
I don't think it means Readnews is getting DMCA notices, I think that older posts on Readnews are roughly mirroring the completion of Highwinds, because of the peculiar newsfeed arrangements that Readnews has set up.
All the articles that Blocknews does have for that post are fed to it by Highwinds (shown in Path header). When Highwinds was having completion issues not related to DMCA takedowns, many of the missing articles were also missing from Readnews servers. I don't know why Readnews is so dependent on one newsfeed from a single competitor for its older retention range.
im inclined to agree on this one. its quite possible
I downloaded it with blocknews with us server as main and eu one as backup and came up only 26 blocks short of a repair. I am surprised the slack couldn't be taken up with a giganews account. I know I got these sometime ago and they were fine. Ahh well. They are several hundred days old so they become a huge target with each passing day. But I don't really know if it is dmca or not.Quote:
Originally Posted by zot
Looks like a great offer, I'll probably buy it.Quote:
Originally Posted by Malcontent
I'm a blocknews user since a year and im very pleased with their service as long we are talking about the fresh stuff...
But their claim "With our storage spool constantly growing, retention is now at 1,150+ days for binaries" on the website is bullshit. The oldest thing that i could still get was around 600 days old.
My opinion is that this is a great service if you dont want access to really old posts. Worth its money. But they really should correct their claims on the website.
I don't know....I just got a show earlier that was 1192 days old and it was fine. I have the EU server set as backup as well amd I think it helps too. I guess like all the rest it depends what you grab.Quote:
Originally Posted by tryfailrepeat
Excellent point, but that appears to be an entirely different issue, as I doubt that this problem was from a server-propagation error.Quote:
Originally Posted by mesaman
When a pay-TV release is missing the first article of every rar/par file --as was the case here-- that would normally be a telltale sign of a DMCA takedown, which would happen a minimum of several hours (but more likely several days/weeks) AFTER the articles were already propagated downstream to the next NNTP server in the path (a process that happens immediately after posting). So therefore a takedown would only affect the servers of the company that received the notice.
I would assume that having the same random articles missing on two or more different servers in the propagation path would probably be from an upload or propagation error, but it would indeed be a strange coincidence if the missing articles in propagation just happened to fit the pattern of a DMCA takedown, as well as being a strange coincidence that the problem was only noticed long after the file was posted (and presumably downloaded many times).
It's not by any means absolute proof (and I hope I'm wrong about this) but it certainly seems to me more like a takedown, rather than a upload/propagation error. Time will tell.
Sorry, wrong assumptions and bad use of terminology on my part. In my own mental 'rule-of-thumb' I was more or less quickly "eyeballing" the numbers, and seeing about one missing segment in every 100MB file and seeing the number of par MB being roughly 10% of the release MB (which is not at all the same as the par set's percent redundancy) just *felt* like it would still work. Of course if I had not been not so lazy a better way would have been to actually count the blocks (assuming that the pars were even based on the same size as the rar articles).Quote:
The main reason SuperNZB completion checker varies between runs is that it randomly shows missing parts in the wrong rows. Also, a timeout, when the Readnews server takes more than 10 seconds to send a response to the 'head' command, is counted as a missing part. Let's assume though that the total is correct and your stats are 1.0% missing parts and 10% PARS. You then assume that the files should repair quite easily on Blocknews alone. Do you understand why your assumption is way off the mark?
But this brings up another question: is there any reason (or advantage) why pars would be sized NOT to match the article's size setting?
That's why Readnews is peculiar; the servers work as expected for newer posts, but older retention is different. There's a longer response time after the article command is sent, and the article finder operation that's internal to Readnews might not even use the normal NNTP peering commands like IHAVE. They don't explain in detail what the setup is that provides the older retention but insist it's all legit with Highwinds.
There seems to be a poster requirement to include 10% pars, whether or not source block size matches article size. It's faster to create 10% pars if the source blocks are large, even though doing that renders the pars less efficient. Yes I know, it makes no sense but that's how it's done.
Well if this doesn't make it more confusing when I download episode 4 now it comes down fine and unpacks okay. Before it was missing 26 blocks. Maybe something is fixed....maybe something is screwing with us or just maybe the usenet gods don't like me but I swear it didn't work before. Lol