Debian Bug report logs - #674145

mplayer does not stop after playing a file with

Reported by: Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> Date: Wed, 23 May 2012 11:00:01 UTC Severity: important Found in version mplayer2/2.0-554-gf63dbad-1 Fixed in version 2.0-701-gd4c5b7f-1 Done: Reinhard Tartler <siretart@gmail.com> Bug is archived. No further changes may be made. Forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=56577

Toggle useless messages

Report forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Wed, 23 May 2012 11:00:04 GMT) (full text, mbox, link).

Acknowledgement sent to Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> :

New Bug report received and forwarded. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Wed, 23 May 2012 11:00:07 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: mplayer2: mplayer does not stop after playing a file Date: Wed, 23 May 2012 12:57:08 +0200

Package: mplayer2 Version: 2.0-554-gf63dbad-1 Severity: normal mplayer AUDIOFILE plays the file, but does not exit at the end. When several files are given in the commandline, mplayer stops playing after the first file and continues with the next file only after the return key is pressed. Regards, Martin -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.4.0 (SMP w/4 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages mplayer2 depends on: ii libaa1 1.4p5-39 ii libasound2 1.0.25-2 ii libass4 0.10.0-3 ii libavcodec53 6:0.8.2-2 ii libavformat53 6:0.8.2-2 ii libavutil51 6:0.8.2-2 ii libbluray1 1:0.2.2-1 ii libc6 2.13-32 ii libcaca0 0.99.beta18-1 ii libcdio-cdda0 0.81-5 ii libcdio-paranoia0 0.81-5 ii libcdio10 0.81-5 ii libdca0 0.0.5-5 ii libdirectfb-1.2-9 1.2.10.0-4.3 ii libdvdnav4 4.2.0-1 ii libdvdread4 4.2.0-1 ii libenca0 1.13-4 ii libfaad2 2.7-8 ii libfontconfig1 2.9.0-3 ii libfreetype6 2.4.9-1 ii libfribidi0 0.19.2-3 ii libgif4 4.1.6-9.1 ii libgl1-mesa-glx [libgl1] 7.11.2-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.8~dfsg.3+20120418gitf82ec715-6 ii libjpeg8 8d-1 ii liblircclient0 0.9.0~pre1-1 ii libncurses5 5.9-7 ii libogg0 1.2.2~dfsg-1.1 ii libpng12-0 1.2.49-1 ii libpostproc52 6:0.8.2-2 ii libpulse0 1.1-3.2 ii libsdl1.2debian 1.2.15-3 ii libsmbclient 2:3.6.5-1 ii libspeex1 1.2~rc1-3.1 ii libswscale2 6:0.8.2-2 ii libtheora0 1.1.1+dfsg.1-3.1 ii libtinfo5 5.9-7 ii libvdpau1 0.4.1-5 ii libvorbis0a 1.3.2-1.3 ii libx11-6 2:1.4.99.901-2 ii libxext6 2:1.3.1-2 ii libxinerama1 2:1.1.2-1 ii libxv1 2:1.0.7-1 ii libxvidcore4 2:1.3.2-9 ii libxxf86dga1 2:1.1.2-1 ii libxxf86vm1 1:1.1.2-1 ii zlib1g 1:1.2.7.dfsg-1 mplayer2 recommends no packages. mplayer2 suggests no packages. -- no debconf information

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Thu, 24 May 2012 01:06:02 GMT) (full text, mbox, link).

Acknowledgement sent to Uoti Urpala <uoti.urpala@pp1.inet.fi> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Thu, 24 May 2012 01:06:02 GMT) (full text, mbox, link).

Message #10 received at 674145@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi> To: 674145@bugs.debian.org Subject: Re: mplayer2: mplayer does not stop after playing a file Date: Thu, 24 May 2012 04:04:17 +0300

Are you using Pulseaudio output (or ALSA redirected through Pulseaudio)? My first guess is that you're hitting one of Pulseaudio's numerous bugs, where it keeps falsely reporting that there's still a significant amount of unplayed audio left; the player keeps waiting for the audio to finish playing.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Thu, 24 May 2012 11:51:05 GMT) (full text, mbox, link).

Acknowledgement sent to Martin Ziegler <ziegler@uni-freiburg.de> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Thu, 24 May 2012 11:51:09 GMT) (full text, mbox, link).

Message #15 received at 674145@bugs.debian.org (full text, mbox, reply):

From: Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> To: 674145@bugs.debian.org Cc: Uoti Urpala <uoti.urpala@pp1.inet.fi> Subject: Re: mplayer2: mplayer does not stop after playing a file Date: Thu, 24 May 2012 13:47:25 +0200

mplayer said that the output device was pulse: AO: [pulse] Wenn I use mplayer with the option "-ao alsa" everything works fine. Thanks! It might be interesting that the version of mplayer in the package "mplayer" does not hit this bug. It works also with the option "-ao pulse". Regards, Martin

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Fri, 25 May 2012 23:00:04 GMT) (full text, mbox, link).

Acknowledgement sent to Uoti Urpala <uoti.urpala@pp1.inet.fi> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Fri, 25 May 2012 23:00:04 GMT) (full text, mbox, link).

Message #20 received at 674145@bugs.debian.org (full text, mbox, reply):

From: Uoti Urpala <uoti.urpala@pp1.inet.fi> To: Martin Ziegler <ziegler@uni-freiburg.de> Cc: 674145@bugs.debian.org Subject: Re: mplayer2: mplayer does not stop after playing a file Date: Sat, 26 May 2012 01:55:59 +0300

On Thu, 2012-05-24 at 13:47 +0200, Martin Ziegler wrote: > mplayer said that the output device was pulse: > > AO: [pulse] > > Wenn I use mplayer with the option "-ao alsa" everything > works fine. Thanks! This is most likely a Pulseaudio bug then. > It might be interesting that the version of mplayer in the > package "mplayer" does not hit this bug. It works also with > the option "-ao pulse". The old code in MPlayer 1 exits the main play loop after all audio has been buffered, regardless of the amount of audio not actually played yet (a "flush all buffered audio" operation is performed later). So it's expected that this Pulseaudio bug does not have the same effect. The problem with the old code is that the player can become unresponsive for relatively long periods during the flush operation, even with audio output drivers that function perfectly. It would be possible to add some workarounds on the player side for this bug. But I'm not sure whether that would be worth it, as there are so many bugs in Pulseaudio, and 2.0 broke more things again. Trying to work around just this bug feels somewhat pointless in this situation. The current situation where Pulseaudio has become the standard sound output method but seems to lack developers to fix even fairly blatant bugs in basic functionality is unfortunate.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Wed, 11 Jul 2012 00:21:11 GMT) (full text, mbox, link).

Acknowledgement sent to Foo <synth17@gmail.com> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Wed, 11 Jul 2012 00:21:11 GMT) (full text, mbox, link).

Message #25 received at 674145@bugs.debian.org (full text, mbox, reply):

From: Foo <synth17@gmail.com> To: 674145@bugs.debian.org Subject: mplayer2 stops after each file... Date: Tue, 10 Jul 2012 20:16:59 -0400

Dear Maintainer, As Martin explained. When playing several files using the option '-ao pulse', mplayer2 stops after each file and one must manually hit ENTER to go/play the next file. IE.. $ mplayer -ao pulse foo foo1 foo2 But with '-ao alsa' mplayer2 plays the files one right after another. Can you please reassign this bug to pulseaudio? Thanks, Michel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Mon, 30 Jul 2012 17:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Reinhard Tartler <siretart@gmail.com> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Mon, 30 Jul 2012 17:21:03 GMT) (full text, mbox, link).

Message #30 received at 674145@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com> To: Uoti Urpala <uoti.urpala@pp1.inet.fi>, 674145@bugs.debian.org Cc: Martin Ziegler <ziegler@uni-freiburg.de> Subject: Re: Bug#674145: mplayer2: mplayer does not stop after playing a file Date: Mon, 30 Jul 2012 19:19:09 +0200

tag 674145 important retitle 674145 mplayer does not stop after playing a file with pulseaudio backend, breaks playback of multiple files stop On Sat, May 26, 2012 at 12:55 AM, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: > On Thu, 2012-05-24 at 13:47 +0200, Martin Ziegler wrote: >> mplayer said that the output device was pulse: >> >> AO: [pulse] >> >> Wenn I use mplayer with the option "-ao alsa" everything >> works fine. Thanks! > > This is most likely a Pulseaudio bug then. > > >> It might be interesting that the version of mplayer in the >> package "mplayer" does not hit this bug. It works also with >> the option "-ao pulse". > > The old code in MPlayer 1 exits the main play loop after all audio has > been buffered, regardless of the amount of audio not actually played yet > (a "flush all buffered audio" operation is performed later). So it's > expected that this Pulseaudio bug does not have the same effect. The > problem with the old code is that the player can become unresponsive for > relatively long periods during the flush operation, even with audio > output drivers that function perfectly. > > It would be possible to add some workarounds on the player side for this > bug. But I'm not sure whether that would be worth it, as there are so > many bugs in Pulseaudio, and 2.0 broke more things again. Trying to work > around just this bug feels somewhat pointless in this situation. The > current situation where Pulseaudio has become the standard sound output > method but seems to lack developers to fix even fairly blatant bugs in > basic functionality is unfortunate. Thanks for this investigation. As a followup to the conversation on IRC this afternoon, I have noticed this commit in mplayer2.git: http://git.mplayer2.org/mplayer2/commit/?id=de435ed56eafee040fe286151e51b94c144badc7 For full context, I'm quoting the excellent and very verbose commit message in full here: ao_pulse: work around PulseAudio timing bugsHEADmaster Work around PulseAudio bugs more effectively. In particular, this should avoid two issues: playback never finishing at end of file / segment due to PulseAudio always claiming there's still time before audio playback reaches the end, and jerky playback especially after seeking due to bogus output from PulseAudio's timing interpolation code. This time, I looked into the PulseAudio code itself and analyzed the bugs causing problems. Fortunately, two of the serious ones can be worked around in client code. Write a new get_delay() implementation doing that, and remove some of the previous workarounds which are now unnecessary. Also add a pa_stream_trigger() call to ensure playback of files shorter than prebuf value starts (btw doing that by setting a low prebuf hits yet another PulseAudio bug, even if you then write the whole file in one call). There are still a couple of known PulseAudio bugs that can not be worked around in client code. Especially, bug 4 below can cause issues when pausing. Below is a copy of a message I sent to the pulseaudio-discuss mailing list, describing some of the PulseAudio bugs: ================================================== A lot of mplayer2 users with PulseAudio have experienced problems. I investigated some of those and confirmed that they are caused by PulseAudio. There are quite a few distinct PulseAudio bugs; some are analyzed below. Overall, however, I wonder why there are so many fairly obvious bugs in a widely used piece of software. Is there no maintenance? Or do people not test it? Some of the bugs are probably less obvious if you request low latency (though they're not specific to higher-latency case); do people test the low-latency case only? 1. The timing interpolation functionality can return completely bogus values for playback position and latency, especially after seeking (mplayer2 does cork / flush / uncork, as flushing alone does not seem to remove data already in sink). I've seen quickly repeated seeks report over 10 second latency, when there aren't any buffers anywhere that big. I have not investigated the exact cause. Instead I disabled interpolation and added code to always call pa_stream_update_timing_info(). (I assume that always waiting for this to complete, instead of doing custom interpolation, may give bad performance if it queries a remote server. But at least it works better locally.) 2. Position/latency reporting is wrong at the end of a stream (after the lack of more data triggers underflow status). As a result mplayer2 never ends the playback of a file, as it's waiting forever for audio to finish playing. The reason for this is that the calculations in PulseAudio add the whole length of data in the sink to the current latency (subtract from position), even if the sink does not contain that much data *from this stream* in underflow conditions. I was able to work around this bug by calculating latency from pa_timing_info data myself as follows (ti=pa_timing_info): int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss); latency -= ti->transport_usec; int64_t sink_latency = ti->sink_usec; if (!ti->playing) // this part is missing from PulseAudio itself sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss); if (sink_latency > 0) latency += sink_latency; if (latency < 0) latency = 0; However, this still doesn't always work due to the next bug. 3. The since_underrun field in pa_timing_info is wrong if PulseAudio is resampling the stream. As a result, the above code indicated that the playback of a 0.1 second 8-bit mono file would take about 0.5 seconds. This bug is in pa_sink_input_peek(). The problematic parts are: ilength = pa_resampler_request(i->thread_info.resampler, slength); ... if (ilength > block_size_max_sink_input) ilength = block_size_max_sink_input; ... pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE); ... i->thread_info.underrun_for += ilength; This is measuring audio in two different units, bytes for resampled-to-sink (slength) and original stream (ilength). However, the block_size_max_sink_input test only adjusts ilength; after that the values may be out of sync. Thus underrun_for is incremented by less than it should be to match the slength value used in pa_memblockq_seek. 4. Stream rewind functionality breaks if the sink is suspended (while the stream is corked). Thus, if you pause for more than 5 seconds without other audio playing, things are broken after that. The most obvious symptom is that playback can continue for a significant time after corking. This is caused by sink_input and sink getting out of sync. First, after uncorking a stream on a suspended sink, pa_sink_input_request_rewind() is called while the sink is still in suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1 and calls pa_sink_request_rewind(). However, the sink ignores rewind requests while suspended. Thus this particular rewind does nothing. The problem is that rewrite_nbytes is left at -1. Further calls to pa_sink_input_request_rewind() do nothing because "nbytes = PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and the call to pa_sink_request_rewind() is under "if (nbytes != (size_t) -1) {". Usually, after a sink responds to a rewind request, rewrite_bytes is reset in pa_sink_input_process_rewind(), but this doesn't happen if the sink ever ignores one request. This broken state can be resolved if pa_sink_input_process_rewind() is called due to a rewind triggered by _another_ stream. There were more bugs, but I'll leave those for later. ----cut---- Just to be sure, are there other commits that are related to this particular bug? The explanation above (as well as the code changes) read reasonable to me so that I'm inclined to work at an update for testing. BTW, I guess that http://git.mplayer2.org/mplayer2/commit/libao2/ao_pulse.c?id=bb908027178fe8bfd7d6e3fc255dea8c5051cd4a should get included into wheezy as well, but let's track that in another bug report. Thanks for your time, Reinhard -- regards, Reinhard

Changed Bug title to 'mplayer does not stop after playing a file with' from 'mplayer2: mplayer does not stop after playing a file' Request was from Reinhard Tartler <siretart@gmail.com> to control@bugs.debian.org . (Mon, 30 Jul 2012 17:21:05 GMT) (full text, mbox, link).

Severity set to 'important' from 'normal' Request was from Reinhard Tartler <siretart@tauware.de> to control@bugs.debian.org . (Mon, 30 Jul 2012 18:42:06 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Mon, 21 Jan 2013 06:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Reinhard Tartler <siretart@gmail.com> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Mon, 21 Jan 2013 06:57:03 GMT) (full text, mbox, link).

Message #39 received at 674145@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com> To: Martin Ziegler <ziegler@uni-freiburg.de>, 674145@bugs.debian.org Subject: Re: Bug#674145: mplayer2: mplayer does not stop after playing a file Date: Mon, 21 Jan 2013 07:54:25 +0100

On Thu, May 24, 2012 at 1:47 PM, Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> wrote: > mplayer said that the output device was pulse: > > AO: [pulse] > > Wenn I use mplayer with the option "-ao alsa" everything works fine. Thanks! > > It might be interesting that the version of mplayer in the package "mplayer" > does not hit this bug. It works also with the option "-ao pulse". Can you please test this with the mplayer2 package that I have just uploaded to experimental, and report back? I believe it has been fixed, but as mplayer is unable to connect to my pulseaudio daemon running outside of the chroot, I am unable to test this properly. thanks! -- regards, Reinhard

Reply sent to Reinhard Tartler <siretart@gmail.com> :

You have taken responsibility. (Mon, 21 Jan 2013 08:51:09 GMT) (full text, mbox, link).

Notification sent to Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> :

Bug acknowledged by developer. (Mon, 21 Jan 2013 08:51:09 GMT) (full text, mbox, link).

Message #44 received at 674145-done@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com> To: Martin Ziegler <ziegler@uni-freiburg.de> Cc: 674145-done@bugs.debian.org Subject: Re: Bug#674145: mplayer2: mplayer does not stop after playing a file Date: Mon, 21 Jan 2013 09:48:35 +0100

Version: 2.0-701-gd4c5b7f-1 On Mon, Jan 21, 2013 at 8:53 AM, Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> wrote: > I tried now a WAV-File. mplayer 2 plays it and > exits normally. Thanks for reporting back. I'm closing the bug with this email. -- regards, Reinhard

Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=56577'. Request was from Samuel Bronson <naesten@gmail.com> to control@bugs.debian.org . (Tue, 26 Mar 2013 21:33:07 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> :

Bug#674145 ; Package mplayer2 . (Thu, 16 May 2013 16:21:04 GMT) (full text, mbox, link).

Acknowledgement sent to hamidreza yazdani <hamidreza1016@gmail.com> :

Extra info received and forwarded to list. Copy sent to Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> . (Thu, 16 May 2013 16:21:04 GMT) (full text, mbox, link).

Message #51 received at 674145@bugs.debian.org (full text, mbox, reply):

From: hamidreza yazdani <hamidreza1016@gmail.com> To: 674145@bugs.debian.org Subject: having problems with smplayer playlist Date: Thu, 16 May 2013 20:49:24 +0430

hello dear Gnu-linux lovers i was using smplayer with a USB speaker. when i selected a series of tracks to be played on playlist the player stopped after playing a single track . i took the first advice although i took advantage in a different way. i changed my sound card in the options>preferences>general>audio and oh my god it worked. i am new to xubuntu and wow its great ! windows sucks !

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org . (Wed, 06 Nov 2013 07:33:08 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.