[MPlayer-users] Bug 2 of 2: -framedrop gives lots of errormessages with h264

[Kichigai Mentat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 2, 2006, at 22.56, John Brown wrote:

> RC wrote:
>>
>> I don't understand why posting a full bugreport is so difficult  
>> for you.
>>  It's not exactly torture to go through all the steps.
>>
> Because the information that they are asking for is usually  
> unnecessary. If the developers are as busy as that, why do they  
> want to read all of that irrelevant information? I am talking about  
> my crashes; not about Ergazy's specific case.
>
> 1)If you compiled MPlayer successfully, why do your gcc, ld, and as  
> versions matter? What was the last bug that was caused because the  
> user compiled with gcc a.b.c when he should have used gcc d.e.f?  
> when was that?

This is a blanket solution. The bug report covers everything,  
including compiling problems, where those things can come into play.  
And given that different code is needed between GCC 3.3 and GCC 4.0,  
it's possible that an error in the code for GCC 3.3 would cause a  
problem, but using a binary compiled with GCC 4.0 wouldn't (though I  
might be wrong in this case). In Ergzay's case, he probably could  
have saved some trouble by just reporting the version of XCode he was  
using.

>
> 2) If you have a problem with some files but not others, and other  
> players can play the problem files, why isn't it sufficient to send  
> a sample file and a description of the problem? (By the way Ergazy  
> is wrong not to submit a sample.)The developers can do anything  
> that they want with the file. If they can reproduce the problem  
> then they will see for themselves everything that they want you to  
> send. If they can't, *then* the verbose output, backtrace, etc.  
> would help them to come up with a hypothesis.

Samples are, more often than not, helpful. This is one of those "If  
you know what's going on, you'll know if you really need to include  
one or not" things. Verbose output is VERY important, I think.  
Looking back on the mailing list, including verbose output has helped  
diagnose things pretty quickly. It's like if my copy of FireFox  
crashed, and I simply sent a bug report saying "My FireFox crashed.  
Can you fix it?" instead of including additional information. The  
backtrace, depending on the situation, is useful, but in this case, I  
think you're right.

>
> 3) Similarly, I really do not believe that it is generally useful  
> to know about the CPU, video card, sound card, etc. if your system  
> is working well otherwise. The operating system, certainly.

This is important in the world of cross-platform applications because  
it helps to know what exactly we're dealing with. When I was going  
through compiling MPlayer for my OS X machine, I actually ran into  
one or two PowerPC-specific problems. And knowing whether it's a G3  
versus a G4 can make a difference, depending on the features of the  
two CPUs. I'd say the optimized code for a PowerPC G4 CPU with  
AltiVec would be different enough from that of an i386 CPU, which is  
in turn different enough from an AMD64 CPU, to make the CPU an  
important thing to consider because of the coding differences.

In cases involving software decompression, knowing your video card or  
sound card aren't that important. But when we start talking about  
outputs like OpenGL, or XvMC, then it gets important. Amounts of RAM  
can be important too, but depending on the situation.

>
> 4) They say that you should not truncate the output, but do they  
> really need to see *all* the status lines? Unless there is a  
> warning or error message, one status line looks very much like  
> another, except possibly the last line which may be incomplete  
> because MPlayer crashed.

If you know what you're doing, it's probably safe, but if you don't,  
do the whole thing. People who know enough about the problem would  
probably do this anyway. People who don't would just follow the  
instructions listed.

>
> If the developers ned more information, they can ask. I do not see  
> the point of drowning them in useless information by following the  
> steps in the manual like a robot.

One: It saves time on the developer's part. Remember, they're doing  
this out of the goodness of their heart (and such wonderful goodness  
it is, too!). In addition, listing off this information can be the  
difference between diagnosing the problem in a single message, with  
about fifteen minutes turn-around, or chasing five or six different  
avenues over several days.

Two: In the event you have no idea what happened, by providing ALL  
possible information, the devs can probably make a better diagnosis.  
Also, remember, this is a blanket bug-report. This covers problems  
from being unable to compile a binary (where things like GCC and LD  
versions are important) to things as small as being unable to seek,  
or ghosts appearing when they don't show up in other media players.  
It's one of those "better safe than sorry" things.

>
> It just so happens that I am gearing up to report a crash.  
> Notwithstanding all of the above, if they think that they need all  
> of that verbiage, they will get it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEMNSTwAwn3hu8KxcRApgZAJ9TnM+Hm6as/m1ydLLhJzfDT3XpXACggrmB
SCXUHikwuk/4hmWi74MPAjM=
=7Nn3
-----END PGP SIGNATURE-----