Stupid Shit in Bug Reports Part Two


#1

While browsing twitter I saw this

and that made me think to that old post
Adobe take a lot of shit in their bug reports


then I read the bug report to see what’s going on

AIR-4198798 - FLV video no longer displays

Description

Problem Description: As a part of my AIR desktop application startup the PreLoader
plays a short .flv video.

Steps to Reproduce:

Actual Result: It has worked fine for at least five previous SDK releases, but the
Beta 32 release in February breaks -- the window is empty and the audio track
does not play.

Expected Result:

Any Workarounds:

and here all the shit I see there:

right from the get go the guy does not even bother to describe the “step to reproduce”
nor the “expected results”, just that, that’s bad

but it goes further, in the many comments to follow


Having no other means of dealing with the problem, and seeing from the Beta release notes that you ware “tweaking video” I tried to convert the media, but that did not change the symptom, nor fix the problem. .mp4 and .avi versions of the same video clip fail in the same manner.

yeah and it did not occurs to this user to submit the videos as part of the test
wether you use a .flv or .mp4 or .avi maybe the media is badly encoded
or maybe somewhere in the pipeline of the compilation something goes wrong


No luck with Build 103. To summarize:

A. The title of the bug should probably be changed because I do not believe that the bug is specific to .flv media. The tests fail the same way even if we change to .mp4 or …avi.

B. The bug was not present in Build 89.

C. It first showed up in my testing of Build 100.

D. Updating to Build 103 does not fix the problem.

Whatever testing you have been doing of “new and improved” ways to play video with newer hardware, it has broken the way in which video was being handled on vintage 2016 Nvidia cards which are robust enough to handle the 3D rendering the application does via Molehill.

oh you mean you only have bugs with BETA releases, but the final release is all fine
humm who knew? it seems that BETA releases are not stable …
maybe that’s why they are marked BETA!!!

but still “The tests fail the same way even if we change to .mp4 or …avi.”
hey let’s certainly not provide those files for people to test, it will certainly not help at all

and then come the judgement thing like

Whatever testing you have been doing of “new and improved” ways to play video …

did he called them assholes? well… he didn’t really say the words but that was definitively a diss

yeah that will help a lot to get a dev, without step to reproduce, without sample code, to go and look into the problem, it’s not like dev time is precious, and dev only look into bugs when you start to insult them… that’s granted …


After several hours of adding debugging code to help isolate the problem, I believe that the snippit attached as Bug.txt will let you most quickly hone in on the problem. [I’m sorry, but it is really no feasible, to create complete working application with the code, but, that said, there is nothing going on in the rest of the application that impacts on the failure.]

What has worked for eons:
A. A NetConnection is established via connect (null) for purely internal operation.
B. That was working and still works as confirmed by the NET_STATUS of Success.
C. A Net Stream is then created and its play (null) method is invoked because the media content is embedded in the swf file.
D. A ByteArray version of the Clip [which is a 5 second .flv video] is then appended to the stream which is attached to the Video object.

In proper operation, the clip plays and all is well. In the failed SDKs after Build 89, the stream reports:
NetStream.Play.Failed
NetStream.Play.Stop
The failure is black and white constant. Test with Build 89, it works. Test with Build 100 or 103 it fails, consistently, always with the same error report.

hummm… so the guy can spend “several hours of adding debugging code to help isolate the problem” and decide by himself what is worth sharing

here the content of Bug.txt

	var video:Video = new Video (480, 270);
	video.addEventListener (VideoEvent.RENDER_STATE,
		function (event:VideoEvent)
		:void
		{
			trace ("Video Rendering:", event.status);
		} // End of anonymous closure.
	);
	video.x = ((bounds.width - 480) / 2);
	video.y = ((bounds.height - 270) / 2);
	addChild (video);
	var duration:Number = 0;
	var nc:NetConnection = new NetConnection();
	nc.client = { onMetaData :
		function (mData:Object)
		:void
		{
			trace ("Video Meta Data:", mData.width, mData.height, mData.duration);
			video.width = mData.width;
			video.height = mData.height;
			duration = parseFloat (mData.duration);
		} // End of anonymous closure.
	};
	nc.addEventListener (NetStatusEvent.NET_STATUS,
		function (event:NetStatusEvent)
		:void
		{
			trace ("NetConnection Status:", event.info.code);
			var ns:NetStream = new NetStream (event.target as NetConnection);
			ns.addEventListener (NetStatusEvent.NET_STATUS,
				function (event:NetStatusEvent)
				:void
				{
					trace ("NetStream Status:", event.info.code);
				} // End of anonymous closure.
			);
			ns.addEventListener (IOErrorEvent.IO_ERROR,
				function (event:IOErrorEvent)
				:void
				{
					trace ("NetStream IOError:", event.errorID, event.text);
				} // End of anonymous closure.
			);
			ns.addEventListener (AsyncErrorEvent.ASYNC_ERROR,
				function (event:AsyncErrorEvent)
				:void
				{
					trace ("NetStream AsyncError:", event.error);
				} // End of anonymous closure.
			);
			ns.client = nc.client;
			ns.play (null);
			ns.appendBytesAction (NetStreamAppendBytesAction.RESET_BEGIN);
			ns.appendBytes (new Clip() as ByteArray);
			video.attachNetStream (ns);

			setTimeout (
				function()
				:void
				{
					setTimeout (
						function()
						:void
						{
							endAnimation();
						}, // End of anonymous closure.
						((duration * 1000) - startUp)
					);
				}, // End of anonymous closure.
				startUp
			);
		} // End of anonymous closure.
	);
	nc.connect (null);

that is almost hilarious, how the guy carefully take the time to comment that is // End of anonymous closure in case he got confused by it

ns.appendBytes (new Clip() as ByteArray); is a nice touch
where the fuck Clip is coming from? is that the FLV from the library?
humm maybe the library asset is fucked up, but yeah no need to provide that FLV file …

but basically that is some shitty code where you have everything mixed together, and THAT “will let you most quickly hone in on the problem”

is that a fucking joke?

[I’m sorry, but it is really no feasible, to create complete working application with the code, but, that said, there is nothing going on in the rest of the application that impacts on the failure.]

and I can tell you “you don’t know that”, and considering the marvellous “quality” code you just provided there you certainly do not know the shit what you’re talking about here

sorry, not sorry, provide a damn sample code and with the assets so other people can test that shit

but nooooooessss, instead the guy goes into explaining how the NetConnection and Net Stream etc. are supposed to work, because off course he knows better that some Adobe engineer that directly have access to the source code, but “ya know” to be sure he is just explaining that to them “here how your code should work, just fix it and I will tell you when I’m happy with it”

oh and cherry on the cake

it fails, consistently, always with the same error report.

but let’s not provide that error report

in fact, let’s not provide any errors or stack traces, or anything that could bring some helps or clues to solve the problem (if a problem exists in the first place)


Build 109 has now been released, so I have taken the time to download and test it, but there has been absolutely no change in this major show-stopper. I frankly don’t understand the policies and procedures of a software development organization whose only response to the report of such a bug is to state that it needs to be reviewed. The bug has been confirmed by other developers. Is voting some method for determining whether or not you plan to fix the problem? Could someone please have the courtesy to provide status. We have businesses to run, as well as you do, and we have to meet customer expectations. if there is no intention to fix this bug, we must convert the application to a framework platform that has serious, professional commitment to our industry. In the absence of any such intercourse here, one can only assume that there is no sense of a contract between you as a provider of software tools and we as consumers.

oh good on you … you have taken the time to download a new BETA release

but did you take the time to provide a code sample? nope
did you take the time to write the step to reproduce? nope
did you take the time to provide the video assets like .flv, .mp4 etc.? nope

oh bummer …

but instead this guy grant us with some deep understanding of why he has a bug and why it is not fixed yet

I frankly don’t understand the policies and procedures of a software development organization whose only response to the report of such a bug is to state that it needs to be reviewed.

that’s for sure dude you don’t understand

first, when your bug is classified under “need to be reviewed” it is a good thing
because it means a developer will look into it and review it to see if it is valid or not

but because you did not bother to provide sample code, sample assets, etc.
this developer will either come back to you and … guess what? … ask for a code sample
or simply classify the bug as “Can not reproduce” and move to the next one

that’s where Terry C. get it all wrong

The bug has been confirmed by other developers.

nope, other people commented that they have similar (more or less) behaviours
those are not confirmations, because those dev can not be trusted
and because those dev only comments stuff and do not provide any sample code, etc.
well … they can definitively not be trusted

so yeah nothing was confirmed

and the wild accusations start

Is voting some method for determining whether or not you plan to fix the problem?

is not providing a code sample and some basic video assets a way to tell us you are some kind of moron?

Could someone please have the courtesy to provide status.

hey asshole, you got your status, it is “it needs to be reviewed”
and it is like that because you lazy fuck did not bother to provide any code sample and any video assets to reproduce the bug

We have businesses to run, as well as you do, and we have to meet customer expectations.

I’m sure if some rando send you some incoherent email and told you fix to some shit in your app, without giving any indications whatsoever where the problem is, you will surely assign 2 dev into it without asking any questions, right ?

and now starts the baiting and threatening

if there is no intention to fix this bug, we must convert the application to a framework platform that has serious, professional commitment to our industry.
In the absence of any such intercourse here, one can only assume that there is no sense of a contract between you as a provider of software tools and we as consumers.

ah man that’s when you meta-yourself from simple moron to uber duper dickhead asshole

whoever Terry C. think he is (apparently a big shot) he is utterly wrong on the “contract”

Adobe here is providing a SDK, aka Software Development Kit, not just some mere “software tools”
and people who are supposed to use that SDK are developers, not just “consumers”

and what developers do? yes they write code
and what developers do when they face bug? they do write a sample code to reproduce the said bug

but all this, apparently, is way above Terry C. head
instead he wants some kind of intercourse (seriously?) or else he will use something else


and finally the funny part

I am the original submitter and I appreciate Ben’s support, but the bug is opened because playing videos on the Desktop is broken, I am happy if you get what you need for your mobile devices – when can I expect a fix to what you have broken on the Desktop?

yes Terry C. you are the original submitter of the bug and that makes you a so special snowflake
and no, just saying the thing is broken, not gonna help one bit in resolving the issue

funny how Terry C. mention he appreciates other people got their problem solved and how he keeps complaining his problem is not solved yet and how he is demanding when he can get some answer

but the bug is opened because playing videos on the Desktop is broken

man … yeah I get it, you made some herculean effort there to open a bug to tell us “it is broken”

but let me try to understand the problem here

  • you are producing an AIR app for desktop
  • when you use the latest NOT BETA release 32.0.0.89
    everything works fine
  • but when you use a BETA release
    wether 32.0.0.100, 32.0.0.103 or 32.0.0.109
    there, it does not work as expected

let’s look at the wikipedia entry for Software release life cycle

and in particular

Beta

Beta, named after the second letter of the Greek alphabet, is the software development phase following alpha. Software in the beta stage is also known as betaware .[3] Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.[4] Software in the beta phase will generally have many more bugs in it than completed software, speed or performance issues, and may still cause crashes or data loss. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it. Software beta releases can either be public or private, depending on whether they openly available or only available to a limited audience. Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as a preview , preview release , prototype , technical preview / technology preview ( TP ),[5] or early access .

Beta testers are people who actively report issues of beta software. They are usually customers or representatives of prospective customers of the organization that develops the software. Beta testers tend to volunteer their services free of charge but often receive versions of the product they test, discounts on the release version, or other incentives.

let me put some emphasis there

Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs. Software in the beta phase will generally have many more bugs in it than completed software, speed or performance issues, and may still cause crashes or data loss.


So yeah Terry C. if you are indeed in the business of producing software you should be aware of what BETA means and in this bug tracker you are basically complaining that a BETA has bugs which is a perfectly normal thing.

In fact, you mention the answer if your many demands

seeing from the Beta release notes that you ware “tweaking video”

yeah Adobe dev are tweaking video, they already know they are breaking things
and they are allowed to do so because it is a BETA release

yeah that is the kind of stupid shit you get in bug reports:
guy complaining there are bugs in BETA release, not even a joke


#2

My video player using air sdk 32.0.0.116 (latest version) and starling video texture in emulator doesn’t show


#3

NetConnection.Connect.Success
NetStream.Play.Start
NetStream.Pause.Notify
NetStream.SeekStart.Notify
NetStream.Seek.Notify
NetStream.Buffer.Full
NetStream.Play.Failed
NetStream.Play.Stop


#4

I already answered to you on the bug tracker

WHERE are the steps to reproduce?
WHERE is the sample code ?
WHERE are FLV samples to test?
HOW do you encode those FLV? have you tried with other formats?

maybe you should provide a REPRODUCIBLE BUILD so others could review your bug in the very same condition

see your problem is that you’re very good at complaining
but not very good at providing the informations to go and reproduce your bug

you do not understand that you need to provide an actual sample project with a build so someone at Adobe can unzip the project, run the build and so reproduce the bug

or maybe you do understand that but you’re just very stubborn
and think copy/pasting half assed code fragment in a comment section inside an issue tracker
will be enough, it is not

see this one for example
WHERE are FLV samples to test?

maybe you are encoding those FLV in a particular way that make that bug happen

imagine a dev that quickly create a sample with its own FLV asset, see it working
guess what gonna happen?

he or she will just ignore your bug

the trick is not to tell people something has a bug but to prove them there is a bug
and to do that nothing is better than an actual working code sample that illustrate the bug

no, not text in comment section
but a zip file with .as sources, an actual *.flv asset to test with and a small ant build.xml

it is as simple as that: to fix a bug you need first to be able to REPRODUCE it
see: https://reproducible-builds.org/

the developers that are in position to fix that kind of bug are extremely busy
the easier you make it for them to reproduce your bug the more chance you have
for them to look into it

saying things like

Whatever testing you have been doing of “new and improved” ways to play video …

not gonna help one bit to motivate a busy developer to look into your problem
at best you will get an answer “can not reproduce”

you’re not so special that the rules do not apply to you


#5

Steps to Reproduce:
Set a project with any complexity, start playing a video through NetStream class instance.

Code snippet using regular stage:

public function Main() {
    stage.align = StageAlign.TOP_LEFT;
    stage.scaleMode = StageScaleMode.NO_SCALE;
    stage.frameRate = 31;
    stage.color = 0x9acdff;

    if(stage) onAddedToStage();
    else
        addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
}

private function onAddedToStage(event:Event=null):void {
    var nc = new NetConnection();
    nc.connect(null);

    var ns:NetStream = new NetStream(nc);
    ns.client = function(info:Object):void{};

    var v = new Video();
    v.attachNetStream(ns);
    addChild(v);

    trace(File.applicationDirectory.resolvePath("sample.mp4").exists);
    ns.play(File.applicationDirectory.resolvePath("sample.mp4").url);
    
}

Code snippet using stageVideo:
public function Main() {
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.frameRate = 31;
stage.color = 0x9acdff;
if(stage)
onAddedToStage();
else
addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
}

private function onAddedToStage(event:Event=null):void {
    stage.addEventListener(StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY, onStageVideoAvailability);
}

private function onStageVideoAvailability(event:StageVideoAvailabilityEvent):void {
    if(event.availability == StageVideoAvailability.AVAILABLE) {
        var nc = new NetConnection();
        nc.connect(null);

        var ns:NetStream = new NetStream(nc);
        ns.client = function(info:Object):void{};
        var opt = new NetStreamPlayOptions();
        opt.streamName = File.applicationDirectory.resolvePath("sample.mp4").url;

        var v = stage.stageVideos[0];
        v.attachNetStream(ns);
        v.viewPort = new Rectangle(0, 0, 320, 240);

        ns.play2(opt);
    } else {
        trace("stage video unavailable");
    }
}

Actual Result:
Plays nothing or only video depending on the platform

Expected Result:
NetStream can play both video and audio

Video formats: flv, mp4


#6

wow… are you serious right now?

OK, I gonna put that on “failure to communicate”
it seems you don’t understand English

so yeah, it would explain that, and all the other stuff


#7

a bit follow up on that

on that other thread on the Adobe forum here an answer

We’re doing a few things to resolve this bug. First we’ve stopped the auto update of the shared runtime, so users will no longer be pushed a release that breaks video. Next week we hope to release another shared runtime that will revert our video changes. Auto update will be turned back on at this time so that everyone gets a shared runtime with working video.

We will also release a new AIR beta (runtime and sdk), with the actual video changes we wanted in place to begin with. This beta will leverage the OS api’s for video rendering in a new accelerated video pipeline. We were shooting for next week for the beta, but with the revert and unscheduled runtime rebuild, it’ll probably be the week after next.

wow… amazing

unbelievable even

NOBODY among all the people complaining thought it was useful to mention
that this was happening with the SHARED RUNTIME

I checked out again, nope
nobody mentioned it

voila, we are here with morons telling us “it does not work”
they do not provide sample, they do not provide any details whatsoever,
and those guys basically have no fucking clue about releasing software

even less clues about reporting bugs

literally like going to the doctor and having this convo

  • doctor it hurts
  • where does it hurt?
  • it hurts pretty bad
  • can you point me where it hurts??
  • shut up do your job and make it less hurt

OMGWTFBBQ those people are hopeless