I’ve found the problem: mplayer recently, and incredibly stupidly, changed the behavior of the (-identify) option, to NOT exit but play back the file anyway, killing its whole point, for <idiocracy lawyer>“reasons”</idiocracy lawyer>. (Obsessive minimalism, usually caused by an anxiety disorder, to be exact.) Unfortunately, smplayer correctly uses this, to fill its playlist. This means that smplayer waits for and then timeouts and is forced to kill mplayer every time something is added to the playlist. To “fix” it, the mplayer developers suggest the hack of adding (-frames 0) to the parameter list, instead of fixing their code… because apparently, that way it’s “cleaner”… (*facepalm*) So smplayer would need to change (-frames 1), in the (-indentify) call to mplayer, to (-frames 0), in order to still work with the new “cleaned up” (read: crippled due to developers being pussies) versions of mplayer. Reproducible: Always Steps to Reproduce: 1. Start smplayer. 2. Open the playlist (Ctrl-L). 3. Drag a file from your file manager to the playlist. Maybe another one. (I’ve mainly tried mka, mkv, mp3, and mp4.) Actual Results: It is impossible to add more files to the playlist until the timeout happens. Expected Results: There should not be any noticeable delay. It should be possible to add more files right away. This might already be fixed in newer versions of smplayer. So I recommend first trying the live (-9999) version, and making a new ebuild that uses a version that already incorporates the change, if it works. Alternative fix: Wipe out the global metastases of psychopaths and sociopaths who created a world of fear to stay in power, let the world calm down, and let the developers heal. Might take a couple of decades though. ;)
does this still happen with more recent versions, e.g. 16.x ?
(In reply to Davide Pesavento from comment #1) > does this still happen with more recent versions, e.g. 16.x ? I have smplayer 16.4.0-r1 here, and if anything, it has gotten even worse. I added 12 songs to the playlist, and after an hour, it was still hanging. top did not show it hogging the CPU though. So it appears to wait for something.
Can you report the problem to smplayer developers please? It could be an upstream bug and I don't think we can do much about it. Thanks.
Created attachment 431722 [details, diff] Should set -frames to 0, but somehow it doesn’t… This is weird… I made a patch to set -frames to 0, but smplayer still uses -frames 1. (ccache wao disabled.)
Created attachment 431724 [details, diff] Should set -frames to 0, but somehow it doesn’t… Oops, forgot to mark it as a patch.
I have submitted the bug upstream: https://sourceforge.net/p/smplayer/bugs/747/ I also found a temporary workaround: In the settings, under “Playlist”, disable “Get info automatically about files added (slow)”.
Created attachment 431754 [details, diff] hanging-identify.patch Alright, this patch fixes it. I will track if upstream integrates it.
Upstream has just merged this into “SVN r7729”, whatever that means, since I can only see r5274 as the most recent commit on SourceForge. Does that mean we can close this? Or wait until(|if?) the ebuild is actually available?
(In reply to Navid Zamani from comment #8) > Upstream has just merged this into “SVN r7729”, whatever that means, since I > can only see r5274 as the most recent commit on SourceForge. https://www.assembla.com/spaces/smplayer/subversion/commits/7729 > Does that mean we can close this? Or wait until(|if?) the ebuild is actually > available? We should backport the patch before closing.
(In reply to Davide Pesavento from comment #9) > We should backport the patch before closing. Alright. Do you want to do that? (Since you’re a dev, and I’m not.)
Done, thanks a lot for your work! https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9dd5ed38a1e7779b4c8b7b5ae1f339206722cda0
