Opened 11 years ago

Last modified 11 years ago

#1383 new defect

mplayer-1.0_rc2 returns successfully after failure

Reported by: Ristioja@… Owned by: reimar
Priority: normal Component: core
Version: unspecified Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

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)

mplayer-async-quit.diff (686 bytes) - added by Ristioja@… 11 years ago.
mplayer-async-quit.diff

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by Ristioja@…

mplayer-async-quit.diff

comment:1 Changed 11 years ago by Ristioja@…

A patch to fix this. Appears to work.

comment:2 Changed 11 years ago by Ristioja@…

  • Summary changed from mplayer-1.0_rc2 returns successfully after SIGTERM when dumping a stream to 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 Changed 11 years ago by Ristioja@…

(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 Changed 11 years ago by reimar

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 Changed 11 years ago by Ristioja@…

(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!

Note: See TracTickets for help on using tickets.