• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Token Conservation and Reclamation

Status
Not open for further replies.
Legit course of action. (fist-bump-respect).

I actually didn't read it online (I have a few 'leaving soon' blogs that I follow, but haven't found a good one for Hulu yet.) I read about it yesterday in another thread on here.
Which is when I realized my wife has never watched X-Files, and not knowing if she would like it (or if it still holds up some 28 years later) I didn't want to pay something like $300 for a full Bluray set of the show.

When I pasted that link, I just pasted the first one that wasn't a word salad. If I'm wrong, great. But like you .. I have the tokens to burn, so why take the chance ? :) If I'm wrong because I didn't fully vet what another forum member said was happening; totally bad on me and I apologize.

Code:
https://www.vitalthrills.com/hulu-july-2021-movies-tv-shows-and-originals/

They have pretty much all the streaming providers and usually post articles about what is coming and going from each every month.

Oh and X-files is not on the leaving this month list. Of course it could be wrong, but just FYI.
 
SMH at this thread.

General comments - not aimed personally at anyone who has posted in this thread:

Its no secret that a publicly available browser addon has recently been rendered useless as a means to obtaining the WV keys needed for decryption of the dash streams on all the sites covered by A/S. There are still methods, methods that were available before the addon was formulated; and indeed the addon was itself formulated in part from old methods still available / in use.

A/S has probably become some sort of a stop gap for this perceived hiccup in operations by a small number of medium-low level downloaders who supply on a commercial basis to the torrent sites until an upgraded addon is made public (it won't be). The major uploaders had their methods before the CDM was revoked and have not been affected.

I cannot see any logical reason for anyone to baulk at the generous token system provided by A/S.

Keep up the good work Team A/S.
 
Last edited:
still don't think there needs to be more tokens. I hate it when people start balking against features that were in placed when they bought a program.
 
still don't think there needs to be more tokens. I hate it when people start balking against features that were in placed when they bought a program.
There isn't and there probably won't be, 280 a week is more than 1000 movies or episodes a month. Enough for most people, and that is what Redfox wants to see, most people are happy. No software ever has 100% approval. It's okay though, it is just a discussion.:p
 
I'm surprised no one has mentioned the initial bucket. Right now, the bucket is 100, along with 5 providers, or 20 per provider. Would anyone have issues with adding 20 more to the initial bucket when you add a new provider (excluding RedFox management)? Of course, you still keep your token renewal rate at 280 per week. And make it a Pro only feature ... with each new provider, get 20 more tokens. You can also have an idea to increase the initial bucket and reduce the refresh rate (for example, 210 downloads per week with refresh rate of 48 minutes).

I do not support such plans. I am fine with what we have. I'm just pointing out how things can get tinkered with much too much. It's just a discussion, right?
 
Last edited:
you only get that initial amount ONCE, when you buy your license. Once those are up, they're gone. permanently. It's illogical to say "20 per provider" as hulu and HBO max weren't there inititially. Just AMZ and NF, thus it was 50 per provider, then D+ came along "knocking it down" to 33 per provider.

If you only use 1 provider then it's even "100 per provider", ONCE. Then just refils
 
If you only use 1 provider then it's even "100 per provider", ONCE. Then just refils
I understand how the system works completely. All I wanted to mention is that the management could increase the initial bucket to appease all the people who think they're being cheated when you add providers as that bucket is consumed only ONCE. That is not a significant hit in the raw download numbers as compared to increasing the refresh rate. I condone neither, and at least for me, I could tolerate half of what is allowed now.
 
I understand how the system works completely. All I wanted to mention is that the management could increase the initial bucket to appease all the people who think they're being cheated when you add providers as that bucket is consumed only ONCE. That is not a significant hit in the raw download numbers as compared to increasing the refresh rate. I condone neither, and at least for me, I could tolerate half of what is allowed now.

I suspect, and this is just a guess, that the 'initial pool' is simply the max pool being populated as 'full' when the new licence is created on the token server. I mean .. I guess they could just populate it at 120 .. maybe .. if it is stored as a simple integer and not something more fancy. if their logic doesn't check for hard numbers, and once some one burns down tokens it starts populating to 100 again.

*shrug*

They could also increase the token pool size, but not the 'respawn' rate. You would still only recover ~280 tokens a week, but be able to 'bank' more.

That would take care of my use-case scenario where I have days (weeks) of low activity, but sometimes need to burst download something because I wasn't paying attention, (or didn't have days to sit in front of my computer for hours clicking each download in a series.)
 
I suspect, and this is just a guess, that the 'initial pool' is simply the max pool being populated as 'full' when the new licence is created on the token server. I mean .. I guess they could just populate it at 120 .. maybe .. if it is stored as a simple integer and not something more fancy. if their logic doesn't check for hard numbers, and once some one burns down tokens it starts populating to 100 again.

*shrug*

They could also increase the token pool size, but not the 'respawn' rate. You would still only recover ~280 tokens a week, but be able to 'bank' more.

That would take care of my use-case scenario where I have days (weeks) of low activity, but sometimes need to burst download something because I wasn't paying attention, (or didn't have days to sit in front of my computer for hours clicking each download in a series.)

I agree. This could be a nice enhancement along with batch downloads and a token counter. Let the token queue build to more than 100 tokens (120...160..) before being lost forever...
 
I am astounded that this is so hard to understand.
1. You start out with 100 tokens.
2. If you use one and wait 36 minutes you will have 100 again.
3. It is constantly replenishing the bucket every 36 minutes not to go over 100 until 280 is reached, but the original bucket is never actually gone. It's a bucket of 100 that is constantly refilling every 36 minutes until 280 is reached in 7 days.
 
I am astounded that this is so hard to understand.
1. You start out with 100 tokens.
2. If you use one and wait 36 minutes you will have 100 again.
3. It is constantly replenishing the bucket every 36 minutes not to go over 100 until 280 is reached, but the original bucket is never actually gone. It's a bucket of 100 that is constantly refilling every 36 minutes until 280 is reached in 7 days.
It's so hard to understand because the 280 number is meaningless and yet you keep using it. The bucket is 100 tokens. If you use 100, you have to wait 2.5 days for 100 tokens to refill. What does 280 a week have to do with anything except being a marketing bullet point?
 
I agree. This could be a nice enhancement along with batch downloads and a token counter. Let the token queue build to more than 100 tokens (120...160..) before being lost forever...
If the goal of the token system is to actually protect providers from banning users as has been stated, this is a poor solution. I would assume anyone who is using all of their tokens and running into the limit is doing so by downloading a bunch of stuff in a short time frame. Increasing the bucket so now someone is downloading 200 or 300 items one after another is going to look even more suspicious. But beyond that, I would imagine a bigger frustration for people hitting the download limit would be that it takes over half an hour to get another token just to do a single download and then they are waiting another half an hour for another download. Everyone keeps asking for batch downloading, you're going to wind up with a queue that only downloads 40 items a day regardless of whether the bucket has 100 or 1000 tokens. A much better solution would be to just lower the refresh rate for tokens to something like 5 minutes. It would only take a little over 8 hours versus 2.5 days now to refill completely, it would make batch downloading much faster, and someone streaming 1 title every 5 minutes is going to look a lot less suspicious to the provider than someone streaming 300 titles in 3 hours every few days.
 
If the goal of the token system is to actually protect providers from banning users as has been stated, this is a poor solution. I would assume anyone who is using all of their tokens and running into the limit is doing so by downloading a bunch of stuff in a short time frame. Increasing the bucket so now someone is downloading 200 or 300 items one after another is going to look even more suspicious. But beyond that, I would imagine a bigger frustration for people hitting the download limit would be that it takes over half an hour to get another token just to do a single download and then they are waiting another half an hour for another download. Everyone keeps asking for batch downloading, you're going to wind up with a queue that only downloads 40 items a day regardless of whether the bucket has 100 or 1000 tokens. A much better solution would be to just lower the refresh rate for tokens to something like 5 minutes. It would only take a little over 8 hours versus 2.5 days now to refill completely, it would make batch downloading much faster, and someone streaming 1 title every 5 minutes is going to look a lot less suspicious to the provider than someone streaming 300 titles in 3 hours every few days.
You are so wrong. Do the math. You have a bucket of 100 Tokens. If you use 1 it will be refilled in 36 minutes. It will constantly be refilled until you reach 280 downloads in 7 days. What don't you understand about that? If you download 16 movies you will have 32 more downloads in approximately 8 hours. but you cant go over 100. It will replenish 180 at 1 every 36 minutes.
 
You are so wrong. Do the math. You have a bucket of 100 Tokens. If you use 1 it will be refilled in 36 minutes. It will constantly be refilled until you reach 280 downloads in 7 days. What don't you understand about that?
I do understand it. I was proposing an alternate solution.
 
Status
Not open for further replies.
Back
Top