Opened 15 years ago
Last modified 15 years ago
#1383 new defect
mplayer-1.0_rc2 returns successfully after failure
| Reported by: | Owned by: | reimar | |
|---|---|---|---|
| Priority: | normal | Component: | core |
| Version: | unspecified | Severity: | normal |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
Description
I reported this first on the Gentoo bugzilla at https://bugs.gentoo.org/show_bug.cgi?id=254823 .
This is what I get after SIGTERMing the mplayer process (mplayer 'videostream
or some large video file' -dumpstream -dumpfile tmpfile ; echo "Terminated with
status $?"):
MPlayer interrupted by signal 2 in module: dumpstream
Core dumped ;)
Exiting... (End of file)
Terminated with status 0
Sometimes I also get these lines before the "core dumped" success message:
read error:: Interrupted system call
pre-header read failed
Attachments (1)
Change History (6)
by , 15 years ago
| Attachment: | mplayer-async-quit.diff added |
|---|
comment:2 by , 15 years ago
| Summary: | mplayer-1.0_rc2 returns successfully after SIGTERM when dumping a stream → mplayer-1.0_rc2 returns successfully after failure |
|---|
I have also noticed mplayer returning successfully after printing the erronous "read error:: Resource temporarily unavailable" message to the standard error output before. However, I'm not quite sure yet whether this happens immediately before exiting, but I'm looking into it.
comment:3 by , 15 years ago
(In reply to comment #2)
I have also noticed mplayer returning successfully after printing the erronous
"read error:: Resource temporarily unavailable" message to the standard error
output before. However, I'm not quite sure yet whether this happens immediately
before exiting, but I'm looking into it.
I was wrong about this, everything was *kind of OK* with this actually, nevermind these two comments please.
comment:4 by , 15 years ago
I can't seen either behaviour to be any better, MPlayer was requested to terminate (via SIGTERM) and it did that without any further issues, so in my view this is no more an error than MPlayer exiting when you press 'q'.
If you e.g. used SIGKILL you should get an error (though MPlayer does not shut down cleanly then).
It might make sense to use a more elaborate return values system like e.g. tar uses, but that is rather counter-intuitive, and someone would have to come up with a system that makes sense.
Regardless of this, your patch would only change the -dumpstream case, not the general case, and thus is incomplete.
comment:5 by , 15 years ago
(In reply to comment #4)
I can't seen either behaviour to be any better, MPlayer was requested to
terminate (via SIGTERM) and it did that without any further issues, so in my
view this is no more an error than MPlayer exiting when you press 'q'.
If you e.g. used SIGKILL you should get an error (though MPlayer does not shut
down cleanly then).
It might make sense to use a more elaborate return values system like e.g. tar
uses, but that is rather counter-intuitive, and someone would have to come up
with a system that makes sense.
Regardless of this, your patch would only change the -dumpstream case, not the
general case, and thus is incomplete.
Originally I tried to use mplayer to dump thousands of mms:// streams, but doing so in a shell script proved to be difficult since whenever mplayer failed to download the stream completely, it would still return successfully. Hence I had to stop using it in favour of another downloader, since parsing mplayer's messages would be difficult to implement "properly". And I must say that I don't have that much interest (nor time) in fixing this bug now to provide a cure-all patch for the badly-formatted code. Sorry.
Proceed as you see fit. All the best!
mplayer-async-quit.diff