• 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.

Question Please Fix this Annoying Processes.

whpony96

Member
Thread Starter
Joined
Oct 31, 2011
Messages
24
Likes
6
Please fix the complete program lockup upon the end of a file download. When any movie or TV episode downloads AnyStream goes into a locked state during compiling of the file. Once the compiling is complete the program becomes active again. There is NO logical reason for this to happen and I know for a fact that this was corrected before and then it returned.
 
Please fix the complete program lockup upon the end of a file download. When any movie or TV episode downloads AnyStream goes into a locked state during compiling of the file. Once the compiling is complete the program becomes active again. There is NO logical reason for this to happen and I know for a fact that this was corrected before and then it returned.
When a file is almost completed, you cannot add or search. Let the file complete, it only takes a few seconds.
 
Pretty sure the video and audio streams are muxing together to make one file. This is the cause of the freeze. It's normal and honestly not that bothersome because it doesn't take that long.
 
I'm also stuck during 5 to 20 seconds for each download. It's the same problem when you download too fast, the interface is stuck.

It's normal and honestly not that bothersome because it doesn't take that long.
Normal I don't know, only the dev can tell, but the interface shouldn't be impacted by the downloading. The interface and the download process seem to be on the same thread.
 
I'm also stuck during 5 to 20 seconds for each download. It's the same problem when you download too fast, the interface is stuck.


Normal I don't know, only the dev can tell, but the interface shouldn't be impacted by the downloading. The interface and the download process seem to be on the same thread.
It's just at the end of the file until it's finalized. Just let it be. Thats all it is. Just let the file finalize, and all is well.
 
My laptop is 14 years old and I've never experienced the issue described here. At the very end of a given download a second at most elapses prior to the confirmation message being displayed stating the download completed. I have yet to have the program freeze or lock up on me. One's mileage may vary I suppose.
 
My laptop is 14 years old and I've never experienced the issue described here. At the very end of a given download a second at most elapses prior to the confirmation message being displayed stating the download completed. I have yet to have the program freeze or lock up on me. One's mileage may vary I suppose.
It does happen with weak CPUs or bandwidth, but it's not an issue. The file is being completed, just leave the program alone, it's no issue if you are using the queue. Just stop playing with the program until the file is finalized.
 
This likely happen because the anystream thread handling the message pump is also used for muxing. If the Windows message pump isn't processing windows messages within 4 seconds or so when an application is running, Windows will mark that thread as "not responding" since it starts assuming that the application may have entered an infinite loop. In this case it hasn't, and will resume processing Windows messages after the muxing has completed. It is not related to weak CPU or bandwidth but can be less noticable on more powerful systems.
 
Um, my PC is FAR from slow. i7 6850k, 32GB DDR4 ram, and the OS on a 1tb Samsung 960 Pro nVME SSD and three Seagate IronWolf 20TB drives. Where is Anystream cashing the video and audio files when it combines them? The reason I ask is my 1TB SSD nVME drive is doing zero reading or writing at all while the combining of files is being completed.
 
Last edited:
This is noticeable on my machines, and it ranges from 5 seconds to 45 seconds (the latter when there is some sort of problem, which happens only a few times a month, and it still completes the file.) I live with it.
 
Um, my PC is FAR from slow. i76850k, 32GB DDR4 ram, and the OS on a 1tb Samsung 960 Pro nVME SSD and three Seagate IronWolf 20TB drives. Where is Anystream cashing the video and audio files when it combines them? The reason I ask is my 1TB SSD nVME drive is doing zero reading or writing at all while the combining of files is being completed.
Those 100's to 1000's of individual pieces being downloaded are being written to your OS drive. When decoded and combined, they are also being written to you OS drive unless you changed the end location in the settings. The process uses less than 1% of your drives capability, so unless you believe in Devine intervention...your NVME is being written too. I'd probably look for a better program to monitor your disk activity. FFMPEG will use every resource it can to do the job it's being asked to do, When AS calls it, it's not going to stop and check if you want to do something else...it going to do the job and do it as fast as it can so you can then continue on using the program.
If it's a small episode and your computer isn't running anything else...you won't even notice it. If it's an 18gb movie and you are doing other things...it's going to take a little longer to finish. It's always worked that way and is not a bug.
 
It is not a bug per se, but it is unusual in Windows software to stop checking Windows messages in the message pump during an applications lifetime, even under high loads. That makes the application look unresponsive.

I think many of us see it, even if we do not have slow computers. I just adapt to it since I'm aware of it.
 
I've noticed it too. I wouldn't say I have a top end PC, but I really don't think it's weak either (i5 7600K CPU). In the earlier versions of AS, I remember there was a window that popped up saying that the file was being processed, please wait (or something like that). AS had come a long way since then.

Honestly, this "issue" has never bothered me. I know it's an important part of the process and it's never locked up for more than a few seconds. Even I can wait that long! 😅
 
yeah, i dont think thats gonna happen. afaik stuff you download via AS is downloaded in chunks and then muxed at the end, or if not chunks then audio and video separately and then muxed at the end. i sport a 35w 5650ge, 64gb of ram, i download to a SATA hdd, and i barely notice it. you could try downloading to NVME, i did in the past but then i got tired of copying from NVME to HDD when everything was finished and ready for archiving. i now just download to the HDD that has the most free space, which in my case is the last bought one, lol, aka the only one left with free space. i dont do 4k, but i tried it and yeah, those do take a moment or two to mux.
 
Ok, I hate to admit it, but I'm experiencing that lately, too.
No matter if I set the download location to the SATA SSD or to the M.2 NVME SSD (which is like 10x faster) ... when downloading Picard S03E01 in HEVC (around 900MB) Anystream hangs about 20 seconds at the end of the loading bar.
I noticed no spike in disk utilization at that time.
The CPU on the other hand gets to around 15%, which would seem like one core fully utilized.
Now if that process could use all the cores, my guess is that the "hanging" would be drastically reduced.
But that is for a dev to decide, if even possible.
Oh yeah, and I'm on Win 10, maybe that's the culprit and all my babbling before was nonsense. 😒
 
The files have to mux, and it takes about 3 seconds you can't play with the program, does everyone think they can stop playing with the program while this is happening? If you don't play with it, it will mux and go on the following file.
 
Now if that process could use all the cores, my guess is that the "hanging" would be drastically reduced.

I doubt it would help. Given it's a single file, it would probably be affected by Amdahl's law. I think the only thing that would work is to run it in a non-pump thread. But given it's only for a short time, it may not even be worth the bother.
 
Last edited:
It would probably resolve it all if you just don't mux in the thread that handles the windows messages (the thread that creates the main application window). Start another thread and mux in that, and continue to check windows messages in the message pump in the thread that creates the window and it will not show up at all, no matter how long it takes to mux.
 
The files have to mux, and it takes about 3 seconds you can't play with the program, does everyone think they can stop playing with the program while this is happening? If you don't play with it, it will mux and go on the following file.
If it only took 3 seconds I wouldn't care. It takes 15 to 30 seconds not 3. But what I don't understand is why the program has to "lock -up" this makes ZERO sense to me. Why can't it perform that task in the background?
 
I have already explained. Sorry, you have an issue with it. ;)
 
Back
Top