StreamFab 6.1.6.7 x64..... And Why You Should Be Using This Version

[Ninko]

Cats4U I'm not surprised you're getting annoyed with what you're having to deal with all the time. I'm sure MOST of us users, me included, appreciate what you're doing in the background to get all this fixed for us! Keep going!

[smithbrad]

Cats4U I'm not surprised you're getting annoyed with what you're having to deal with all the time. I'm sure MOST of us users, me included, appreciate what you're doing in the background to get all this fixed for us! Keep going!

I agree with this, completely.

However, as to why I didn't see the need to send log files is because based on my experience the physical results trumped the log files. Log files are a great debugging tool, especially for one that has detailed knowledge of the code. They can use the logs to determine the area in the code of question and then step through that code while processing to detect the exact issue. Since we don't have access to the code and knowing what the output should be for a particular download before the DRM issue and through every release up to the latest, the physical evidence in my view, is better than the log files. It just seemed to me that no matter how many threads I posted it in, my analysis was not being taken seriously.

[Cats4U]

You weren't being taken seriously because you refused to follow our standard procedure of sending in your StreamFab.log. https://forum.dvdfab.cn/forum/softwa...eamfab-section This is the way we do things here. It is no different from what information that Mona expected of users with problems when she was here.
One thing that is different now is that anyone that refuses to provide a StreamFab.log is now suspected of using a cracked version of StreamFab.com. It became known that on a popular third-party StreamFab forum that caters somewhat to illegal activity at times, someone had posted in the past telling users of cracked versions of SF not to attach a StreamFab.log to a message here because we can tell that you are using a crack. I'm always honest with the users, and I'm honest now, you were checked to see if you had a legally registered SF license, and you do. As for the other user in this recent conversation that also refused to provide a log file, they have not been able to be confirmed as a registered licensee yet. The investigation continues.
Having put that out there, that is absolutely not my reason to asking for a StreamFab.log. Since Jack and I refuse to use any version of SF that does re-encoding in any of its modules, reading someone else's log is the only way that we can know what is going on with a download. It does not matter whether YOU think you know what is going on, WE need to know by either running the tests ourselves or by reading someone else's log files. Only then can we send it up the ladder to finally reach the Developer and hopefully get whatever problem there is fixed. Do you know how many times we've had users 100% certain that StreamFab had a bug and that was the reason they couldn't download something, only for us to show them that it was operator error? I'm not downplaying your knowledge or your findings. It is just that the information we find is what will reach the Developer, not yours. That's the way the system is set up, for right or wrong.

[smithbrad]

You weren't being taken seriously because you refused to follow our standard procedure of sending in your StreamFab.log. https://forum.dvdfab.cn/forum/softwa...eamfab-section This is the way we do things here. It is no different from what information that Mona expected of users with problems when she was here.
One thing that is different now is that anyone that refuses to provide a StreamFab.log is now suspected of using a cracked version of StreamFab.com. It became known that on a popular third-party StreamFab forum that caters somewhat to illegal activity at times, someone had posted in the past telling users of cracked versions of SF not to attach a StreamFab.log to a message here because we can tell that you are using a crack. I'm always honest with the users, and I'm honest now, you were checked to see if you had a legally registered SF license, and you do. As for the other user in this recent conversation that also refused to provide a log file, they have not been able to be confirmed as a registered licensee yet. The investigation continues.
Having put that out there, that is absolutely not my reason to asking for a StreamFab.log. Since Jack and I refuse to use any version of SF that does re-encoding in any of its modules, reading someone else's log is the only way that we can know what is going on with a download. It does not matter whether YOU think you know what is going on, WE need to know by either running the tests ourselves or by reading someone else's log files. Only then can we send it up the ladder to finally reach the Developer and hopefully get whatever problem there is fixed. Do you know how many times we've had users 100% certain that StreamFab had a bug and that was the reason they couldn't download something, only for us to show them that it was operator error? I'm not downplaying your knowledge or your findings. It is just that the information we find is what will reach the Developer, not yours. That's the way the system is set up, for right or wrong.

Just forget it. I've been in software development for 30+ years. What I provided was more concrete proof then any logs. As stated, I've downloaded and tested each version, from what I recall someone said you haven't even installed the latest versions that encode. I've done customer support also for over 30+ years, and I rely on whatever information users provide, not just logs. If that is all these developers respond to then that is their loss. if my input is of no use here then fine, I won't offer it anymore. I'm done.

[fabuloustream]

Confirmed 6.1.7.0 is working partially. Downloaded Road House twice yesterday, one is >3 GB and one is less than 600 MB, recalled it was about 2.6 GB when it was downloading. Examined both file and showed identical bitrate in h264 despite setting it to h265. You can try to download it again at another time or restarting the app. After closing out the app, check Task Manager and kill any processes still running with the app and QCef.exe before launching it again. Will try to provide logs if I can replicate it as I cleared it later that day.

[Occidio]

I would definitely say "partially", decided to retry Romancing the stone on amc, i could only get it in 540 before so I am testing 6.1.7.0 out now and it stated it is downloading at 1080 but the processing is taking a long time with a pegged gpu. If this is just re-encoding, i will wait till the next version comes out. Would rather wait for native 1080 instead of a re-encode because if its at the same quality as Unifab performs, no thank you.

[smithbrad]

You weren't being taken seriously because you refused to follow our standard procedure of sending in your StreamFab.log. https://forum.dvdfab.cn/forum/softwa...eamfab-section This is the way we do things here. It is no different from what information that Mona expected of users with problems when she was here.
One thing that is different now is that anyone that refuses to provide a StreamFab.log is now suspected of using a cracked version of StreamFab.com. It became known that on a popular third-party StreamFab forum that caters somewhat to illegal activity at times, someone had posted in the past telling users of cracked versions of SF not to attach a StreamFab.log to a message here because we can tell that you are using a crack. I'm always honest with the users, and I'm honest now, you were checked to see if you had a legally registered SF license, and you do. As for the other user in this recent conversation that also refused to provide a log file, they have not been able to be confirmed as a registered licensee yet. The investigation continues.
Having put that out there, that is absolutely not my reason to asking for a StreamFab.log. Since Jack and I refuse to use any version of SF that does re-encoding in any of its modules, reading someone else's log is the only way that we can know what is going on with a download. It does not matter whether YOU think you know what is going on, WE need to know by either running the tests ourselves or by reading someone else's log files. Only then can we send it up the ladder to finally reach the Developer and hopefully get whatever problem there is fixed. Do you know how many times we've had users 100% certain that StreamFab had a bug and that was the reason they couldn't download something, only for us to show them that it was operator error? I'm not downplaying your knowledge or your findings. It is just that the information we find is what will reach the Developer, not yours. That's the way the system is set up, for right or wrong.

The funny thing about all this is that I wasn't reporting a bug for the developers to respond to, which is what would have required a log. I was just offering evidence to others that were asking the question about whether it was still re-encoding. I fully expected to be validated by the development team, which in the end I was. I'll leave now and wait for a potential release that someday performs HD downloads again.