[205.2] Deleting video take two

Bugs will be moved here once resolved.

Post » Wed May 27, 2015 12:15 am

The original video was way to big to upload, so I did something brave and against all odds and tested it with a completely different video file and can hardly believe it my self, but I managed to reproduce it!!! :shock:

Anyway, the video file is a gift to you, so whenever someone report a problem that require you to use a video file, you are very welcome to use that one for testing purposes, that way you always have one when you need one for testing.

Attach a Capx
https://dl.dropboxusercontent.com/u/109921357/Video_bug_2/Video_bug_2.rar

Problem Description
If a video is playing and you destroy it, it will keep playing the sound in the background. Also if you delete the file from the disk it will not be deleted, until you close down the application or the video reaches the end.

Attach a Capx
https://dl.dropboxusercontent.com/u/109921357/Video_bug_2/Video_bug_2.rar

Description of Capx
Play a video and destroy the element and delete the file from the disk.

Steps to Reproduce Bug
  • 1. Add a path to a Webm file and press Load and play video.
  • 2. When the video is playing press the Destroy video and delete file button.

(A workaround is the set the video playtime to its duration before deleting.)

Observed Result
Video object is destroyed. But file is not deleted and audio keep playing.

Expected Result
That the video was deleted, audio stopped and file was deleted from the disk.

Affected Browsers
  • Chrome: (YES/NO)
  • FireFox: (YES/NO)
  • Internet Explorer: (YES/NO)

Tested with NWjs 0.12.0

Operating System and Service Pack
Windows 7

Construct 2 Version ID
r205


Closing, please make sure your bug reports are reproducible (this means including the video file you used - I cannot reproduce what you are doing without it)
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,828

Post » Fri Jun 05, 2015 1:13 pm

You could still make it easier to deal with this type of bug report: it unnecessarily refers to paths that don't exist on my computer. This means I can't just open the .capx and press run to see the issue - I am forced to make changes, and that increases the chance I do something differently to you and don't reproduce the issue. I could not reproduce the problem with the file deleting, it deleted just fine after I made the changes for anything useful to happen. The audio-keeps-playing issue actually reproduces with a project file in Chrome so you didn't need NW.js, hard-coded paths or file deletion. Please take this seriously as I deal with a very large number of bug reports and it can really slow things down if bug reports take extra work to deal with. Anyway, the issue should be fixed for the next build.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Sat Jun 06, 2015 11:12 am

Ashley wrote:You could still make it easier to deal with this type of bug report: it unnecessarily refers to paths that don't exist on my computer. This means I can't just open the .capx and press run to see the issue - I am forced to make changes, and that increases the chance I do something differently to you and don't reproduce the issue. I could not reproduce the problem with the file deleting, it deleted just fine after I made the changes for anything useful to happen. The audio-keeps-playing issue actually reproduces with a project file in Chrome so you didn't need NW.js, hard-coded paths or file deletion. Please take this seriously as I deal with a very large number of bug reports and it can really slow things down if bug reports take extra work to deal with. Anyway, the issue should be fixed for the next build.


Appreciate that it gets fixed.

Regarding the whole bug report thing, I take it seriously and report a lot of issues, which normally gets closed even though the bugs still exist. I fully understand that for you to fix bugs you want simple programs to test. And in most cases I provide them, except when the issues requires to add 1-2 objects and follow the description in the bug report.

Regarding you having to change path in order to test it, I don't see how I could get around that. In earlier bug reports where I have used a path to a generic location such as "C:\" the bug reports have been closed because it should be in my user folder. Since my username is different from yours, what exactly can I do? If I use "C:\" you close it because it needs to be in the user folder, and if I put it in the user folder you complain that you have to change it, because it doesn't match your path, it doesn't exactly leave a lot of options.

From another bug report you answered:
The original report still has a few issues:
- you are not sharing the images you are testing with (i.e. the Test.jpg file). You need to share everything your bug report uses to ensure I can reproduce exactly what you are doing.
- you are still submitting reports based on accessing files in C:\, which is normally an admin-restricted folder. To rule out admin permissions as the cause of any problem, only access files in the application folder or user folder. (A global variable with the root path would be a good idea, so it can easily be changed if need be.)

I'm going to close this report again, please file new issues (one issue per thread) respecting the above if you want this investigated further.


When someone make a bug report, they do it because they are not always sure what the problem is and where exactly the problem occurs, so in some cases several issues might be in the report, its not always easy to know exactly what is relevant or not, so you make the report as close to what you did when you experienced it, and if your test capx does the same as the original problem, then you provide that capx or description, regardless of whether all of it is related to the problem. You can't always expect your users to know exactly what causes certain issues, before they make a bug report, I think.
So if you test the provided capx or read the description and you can reproduce it, and some things turns out to not be related to the problem, that's just good, then its easier for you to focus on the actual problem. No one expect bugs to be fixed straight away, but to see your bug report getting closed, due to something that is not even related to the bug it self, is really annoying for the user, because they didn't make the report to annoy you. But it gives the impression that your bug report was closed because there was a spelling error or something and therefore you don't care. (Know that's not the case, but just to underline it)

When it comes to bugs that involves files, how can you be sure that the files used are not copyright protected and therefore users are not able to share them or the size of the files are to big like in my case etc.?
So even though I wrote that the file was a gift to you as a bit of a joke, I actually meant it. Because I don't get why you don't have a set of test files that you use, that you know works, since you know that the one I send you works, you can use that. If the files (Audio, video, image) people are using were corrupted they would most likely not work in the first place, so wouldn't be reported anyway.

So as I said, no one expect bugs to be fixed straight away, just that they at least gets looked at, I bet you that in 99% of the cases if you instead of closing reports made a dialog with those reporting them, if you can't reproduce it or think something is missing, you would get far better feedback and happier users, you answer people before closing bug reports anyway, so whether they are in closed forum or in the open, shouldn't really matter, especially if the user reporting the bug, still experience it.
B
44
S
11
G
2
Posts: 1,182
Reputation: 6,828


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 3 guests