[MPlayer-users] Unexpected quasi-pause when switching desktops

[The Wanderer]

I've just noticed an unexpected behavior in MPlayer, which I'm fairly
sure didn't always happen in previous versions, but short of attempting
a random-stab bisect (which I'd expect to be difficult, given the
interactions with external code, from FFmpeg on out) I'm not sure where
to start in trying to track it down.


The specific version I'm working with is

MPlayer SVN-r38366-11 (C) 2000-2022 MPlayer Team

and it was built on July 14th of this year. The environment is Linux,
with -vo vdpau and -ao alsa.

My environment also includes the e16 window manager, using the "areas"
feature (the lesser-used of two different methods of providing virtual
desktops), and an easily-toggled button on every window which determines
whether that window is "sticky" and follows you between desktops instead
of remaining behind when you change desktops.


I initiated playback of a series of three videos from the command line,
and enabled the "sticky" behavior on that window. The first two videos
played back fine, and the third started fine as well.

At the start of the third video, I used the 'o' key to cycle through the
onscreen display modes until the elapsed time and total estimated
playback time were both visible.

A few minutes into the third video, I switched to an empty desktop,
disabled the "sticky" behavior, and switched away, intending to listen
to the audio and let the video part play on its own in the background.

Rather to my surprise, within about a second after I switched to another
desktop (and brought another window into focus in the process), audio
playback stopped. I switched back, and found that video and audio
playback alike had halted; the video was not updating, the OSD's
playback time was not advancing, and everything else seemed hung, much
as happens when playback is paused via the spacebar.

I pressed the left arrow key to seek backwards and the right to seek
forwards again, and playback resumed from right before the hung point; I
waited, and it passed the point where it had hung without issues.

I switched desktops again, and the problem repeated itself, hanging at a
new point. This behavior seems to repeat consistently, regardless of
what point the video is at when I switch away.

I checked the terminal where I'd launched the playback from, and there
were no message logged at the time of the playback halting. I reproduced
the problem by resuming playback again (via the seek method), leaving
the video window on another desktop, and switching directly to the
desktop with that terminal; that enabled me to see that the "current
timestamp" for both the audio and video streams, as displayed in the
terminal window, continued advancing for a moment after the audio
stopped playing but then remained frozen until further input.

Shortly after that point I exited the playback, having not found any
further ways to get information out of it. The very next thing I've done
is to write this mail.


Aside from potentially running with verbosity flags, or building with
debugging symbols and running inside a debugger, and trying to reproduce
the behavior again, do you have any suggestions for what might be going
on here or how I can try to track it down?

For that matter, do you think the added information from verbosity flags
would be likely to shed any light on the subject? Given that the
terminal didn't show any sign that the program thought anything was
wrong at that point, I'm uncertain whether the effort would even be
worth making.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20220826/a9f84376/attachment.sig>