Is anyone else experiencing this issue? During the remux phase the system locks up and becomes unresponsive. CPU utilization remains under 4% for the system.
-
-
I have the same problem yesterday.
Go on your download/queue page and at the bottom left you can choose "do nothing" -
That's not the same issue. It is already selected. I've noticed FFMpeg starting up and finishing and for a while after that completes, the system locks up and SF shows (not responding).Comment
-
Yes, this has been an ongoing thing for me for over a year. It does it with some of the downloader modules and not as much with others. The worst ones in my experience are with amazon and discovery. It's not so bad for peacock, tubi, and paramount, but it does happen to make my computer either crawl or stop responding. From what I am noticing it's really bad if your cache drive and save drive locations are on seagate drives that have SMR technology. When streamfab is trying to overload the drive with data, it tends to make the computer non-responsive at times until the drive becomes responsive. In my prior posts from around a year ago, I was submitting the same type of problem asking why the program is choking my system. As I learned more about SMR drive technology it became more apparent that had a lot to do with the problem (but certainly not completely the problem).Originally posted by rswiders View Post
One of the ways I came to this conclusion is that when streamfab writes files to disk, it makes multiple copies and file operations to output one file. A couple of other users have stated this recently. While using the competitor software, it runs much more intelligently where it saves chunks to the output file as it grabs it which causes the program to run much much smoother. With streamfab it's different since multiple file operations are happening at one time it floods the drive. When the drive becomes flooded it slows down, if not temporarily locks up the computer until the drive can breathe again. This is where the majority of the issue is happening in my case. Try to avoid SMR drives as much as possible. They suck! They are bad enough to use economically, but streamfab does not help the issue at all.
Here's the wiki info if you want to read up on it:
For a few years I thought my hard drives were dying on me. That wasn't the case at all after changing at least a couple dozen of them out. It came to be the horribly slow SMR technology they put into those drives that I knew nothing about. The complaints were that seagate and wd were both using the technology without notifying the customer in recent years. WD had the worst from what I understand. They were labeling some of their later red drives as NAS ready drives. They should not be that way in my opinion because they can't handle many I/O at one time which causes them to be temporarily unresponsive as all the data is written to and cleared from the drive's cache until it's moved to the platters. There's a lot of information on it out there to which you can find in any search engine. It's quite an interesting read because it makes you think you're not really going bat-shit crazy thinking the problem is with newer faulty drives or something internal.
Again, this is based on my research and from my own experience. I wouldn't necessarily say it was streamfab's fault, but I do believe they could do a better job at creating the final copy of a download without having to process so many I/O read/write functions for one final output file.Comment
-
Again, not my issue. I don't have platter drives but solid state M2 drives. I can try and do some performance monitoring when the remux process is happening and see if I/O operations are the cause.Comment
-
What is your output format? MP4 or MKV? If MKV, have you tried changing the setting to use MKVToolNix (MKVMerge) instead of FFMpeg?
Mona and the developer will want a copy of your StreamFab.log and a name or two of specific files that are causing this Remux problem. Also, which stream module is this occuring on?Comment
Comment