Complaint Amazon, Netflix... DRM-Fix

[IronicMan]

Maybe if they refunded a token amount per week until it's fixed so we at least know they are working on it and interested in fixing it, like even $2 per week

[Zammo]

Do StreamFab staff crack DRM themselves or are they waiting until someone in the scene does it and then they implement the cracked code ?

[Air]

Do StreamFab staff crack DRM themselves or are they waiting until someone in the scene does it and then they implement the cracked code ?

They buy it from someone.

[Exxar]

I find it very interesting they decided to recode low res video to low res video in 1080p. For what? It only takes longer now to download a video. Communication is key in a situation like this, and that is lacking. A lot!


And how come Streamfab isn't working for Amazon? The competition fixed that months ago!


I think it's high time to hold the dev's paycheck until he/she/they fix the problems.

[NewMelle]

Maybe if they refunded a token amount per week until it's fixed so we at least know they are working on it and interested in fixing it, like even $2 per week

I think it's high time to hold the dev's paycheck until he/she/they fix the problems.

It's more likely you'd pull crocodile teeth with tweezers.

[KidJoe]

6.1.7.2 is out. No mention of Amazon or Netflix, but they have fixes and features for others.

I don't care as much about these fixes and features, *IF* they have a TEAM of developers, some of whom are not dedicated to the DRM issues. BUT from the past discussions, that appears to not be the case.

DRM for Amazon and Netflix needs to be their TOP priority. Put everything else, even "quick to fix" bugs to the back burner until this is fixed.

[smithbrad]

With it being almost 2.5 months since the DRM change and no adequate solution for two of the top streaming sites, it seems logical, to me at least, that it isn't a prioritization issue. We've gone from a period of no solution to a hack re-encode solution to working on other issues.

To me, this indicates that they just don't currently have the needed expertise in-house. Otherwise, they would have done what most have asked and forged through it until completed, and not done these interim steps. Which means they either need to:
(1) find the necessary expertise,
(2) buy a solution (if that is an option), or
(3) another viable option to the DRM issue
(4) assume their current stance and hope they don't lose too many customers.

Regardless of which of the above, they need to try to keep the lights on as best as possibly, which seems to be their approach, by using what resources they have to solve what problems they can. All we can do is hope they are working on a plan for 1-3.

[fabuloustream]

With it being almost 2.5 months since the DRM change and no adequate solution for two of the top streaming sites, it seems logical, to me at least, that it isn't a prioritization issue. We've gone from a period of no solution to a hack re-encode solution to working on other issues.

To me, this indicates that they just don't currently have the needed expertise in-house. Otherwise, they would have done what most have asked and forged through it until completed, and not done these interim steps. Which means they either need to:
(1) find the necessary expertise,
(2) buy a solution (if that is an option), or
(3) another viable option to the DRM issue
(4) assume their current stance and hope they don't lose too many customers.

Regardless of which of the above, they need to try to keep the lights on as best as possibly, which seems to be their approach, by using what resources they have to solve what problems they can. All we can do is hope they are working on a plan for 1-3.

I agree with this. While other users want developer(s) to focus only on the DRM issue, I prefer the latter. They would have a list of issues/enhancements etc and would prioritize and weight each whether if it was quick win-win or item that requires more time. They would have already been testing internally for days and validate if it fixes the issue or provide a workaround that make the cut to be release. This is just how the software development is with some dependencies whether they find a solution in house or relies on others. If the developer just focus on DRM, we will not have any releases in between and that would piss off more users or give the impression that they aren't trying to fix other modules meanwhile. If you look at DRM as a whole, this doesn't only affect this but others as well or even from popular scene groups this year.

I welcome the new release with added support to select video and audio for other modules, a step to standardize all the modules similar to Amazon module.

[Chameleon]

I am giving odds it will take years, if ever. This program is kaput.

[Air]

Its over with SF. It would be a miracle if it worked again the way it should. Better look for alternatives.

[JeffDavis]

I find it very interesting they decided to recode low res video to low res video in 1080p

They didn't. They uncompress the full resolution video, then re-encode it at the same resolution. I also assumed they were upscaling low resolution video, as the StreamFab reps have never explained it very well. Germania did in posts #40 and #44 of this thread:

https://forum.dvdfab.cn/forum/software-support-english/youtube-to-mp3-youtube-video-downloader/438278-hulu-location-bug?p=438821

It's not an ideal workaround, as the original video stream (and maybe audio stream?) is re-encoded, adding more compression artifacts. They re-encode as H.264, which can be done more quickly than H.265, but still takes a significant amount of computing time on your computer. StreamFab hasn't disclosed the encoding settings they use (e.g. preset, CRF) for the re-encode, but they probably have to sacrifice quality to get a reasonable encode time. Some have reported the program crashing or locking up during the re-encoding. I used it a few times to download season 7 episodes of Young Sheldon from Amazon. The results were satisfactory, but that's with current year video produced by digital cameras (hence low noise and easy to compress) and each episode only 20 minutes long. For the time being I'm using version 6.1.6.7.

[Cats4U]

6.1.7.2 is out. No mention of Amazon or Netflix, but they have fixes and features for others.

I don't care as much about these fixes and features, *IF* they have a TEAM of developers, some of whom are not dedicated to the DRM issues. BUT from the past discussions, that appears to not be the case.

DRM for Amazon and Netflix needs to be their TOP priority. Put everything else, even "quick to fix" bugs to the back burner until this is fixed.

6.1.7.2 is a fraud, for the most part. The lines highlighted in blue in the changelog are the result of simply installing the latest version of ytdl.exe (renamed YouTubeToMP3Process.exe in SF). They did zero development themselves, but are taking full credit for the hard work in adding more sites that the YTDL developers did.

[NewMelle]

Until the release notes CLEARLY state the DRM issues have been addressed I'm not going to waste the the time to uninstall and reinstall. I spent far too much time troubleshooting something that is undeniably broken and likely unrecoverable. I still use SF for episodic TV since it offers more options and I rarely go beyond 480p for that. Star Trek Discovery and Star Trek Strange New Worlds being the exceptions. For that and Amazon movies I've moved on. At least until those guys get their balls caught in a vise anyway. I'm sticking with 6.1.6.7 as well.

[Chameleon]

The whole program is made up of other developers' hard work, from YTDL to both MKV programs and others.

[fabuloustream]

6.1.7.2 is a fraud, for the most part. The lines highlighted in blue in the changelog are the result of simply installing the latest version of ytdl.exe (renamed YouTubeToMP3Process.exe in SF). They did zero development themselves, but are taking full credit for the hard work in adding more sites that the YTDL developers did.

Not even the latest release 2 days ago but 3/10 release and maybe the forked ffmpeg too. Wish they utilize the latest MKV merge instead of an older 68.0. I wouldn't say zero development since they may have incorporated them but they still have to test and ensure the overall application/UI works as it should