smplayer 'hangs' on exit

[guzzi]

When exiting smplayer 0.6.9 when still playing a movie the desktop becomes inaccessible for about 40 seconds, then smplayer closes and the desktop works again. CPU usage does not go up. This doesn't happen when playing an mp3 file. Using MPlayer SVN-r32813-OS2-4.4.5 (C) 2000-2011 MPlayer Team.

[Silvan Scherrer]

did that work ok with qt 4.6? or was it always the case?

[rudi]

Here it works with 4.6.3. With 4.7.3, I get the same behavior as reported. Even though I'd say the delay is 30 seconds (which is the default timeout for QProcess). The interesting parts of the logs look like this:

4.6.3:

Debug: Core::stop
Debug: Core::stop: state: Playing
Debug: Core::stopMplayer
Debug: Core::tellmp: 'quit'
Debug: Core::stopMplayer: Waiting mplayer to finish...
Debug: MplayerProcess::parseLine: ''
Debug: MplayerProcess::parseLine: 'Cache not responding!'
Debug: MplayerProcess::parseLine: ''
Debug: MplayerProcess::parseLine: 'Exiting... (Quit)'
Debug: MplayerProcess::parseLine: 'ID_EXIT=QUIT'
Debug: MyProcess::procFinished
Debug: MyProcess::procFinished: Bytes available: 0
Debug: MplayerProcess::processFinished: exitCode: 0, status: 0

4.7.3:

Debug: Core::stop
Debug: Core::stop: state: Playing
Debug: Core::stopMplayer
Debug: Core::tellmp: 'quit'
Debug: Core::stopMplayer: Waiting mplayer to finish...
Debug: MplayerProcess::parseLine: ''
Debug: MplayerProcess::parseLine: 'Cache not responding!'
Warning: Core::stopMplayer: process didn't finish. Killing it...
Debug: Core::stopMplayer: Finished. (I hope)
Debug: DefaultGui::disableActionsOnStop
Debug: BaseGui::disableActionsOnStop
Debug: DefaultGui::saveConfig
Debug: DefaultGui::saveConfig: w: 1024 h: 690
Debug: Helper::qtVersion: 4703
Debug: ToolbarEditor::save: 'toolbar1'
Debug: ToolbarEditor::save: 'controlwidget'
Debug: ToolbarEditor::save: 'controlwidget_mini'
Debug: ToolbarEditor::save: ''
Debug: BaseGuiPlus::saveConfig
Debug: Core::saveMediaInfo
Debug: FileSettingsHash::saveSettingsFor: 'E:/Test/Record/Musik/petshopboys_01.MPG'
Debug: FileSettingsHash::saveSettingsFor: config_file: 'C:/Usr/Rudi/.smplayer/file_settings/9/9ad9cce181f45e74.ini'
Debug: FileSettingsHash::saveSettingsFor: output_dir: '9'
Debug: MediaSettings::save
Debug: Core::stopMplayer
Debug: Core::tellmp: 'quit'
Debug: Core::stopMplayer: Waiting mplayer to finish...
Debug: MplayerProcess::parseLine: ''
Debug: MplayerProcess::parseLine: ''
Debug: MplayerProcess::parseLine: 'MPlayer interrupted by signal 15 in module: uninit_vo'
Debug: MplayerProcess::parseLine: 'ID_SIGNAL=15'
Warning: Core::stopMplayer: process didn't finish. Killing it...
Debug: Core::stopMplayer: Finished. (I hope)
Warning: QProcess: Destroyed while process is still running.

[guzzi]

Didn't happen with any previous versions of QT4. Do you need more debug output or is the one by Rudi enough?

[rudi]

Assuming that diver hasn't added tweaks to the SMPlayer code to better cooperate with Qt/2, we most likely see a regression of the changes related to ticket #199. We will need to run SMPlayer using a version of QtCore4.dll that has QProcess logging enabled. I will try to do that on the weekend.

[Silvan Scherrer]

i did not tweak on SMPlayer code in the QProcess part :) And i also think it's a regression, as the same code runs ok with Qt 4.6

[rudi]

I tried to figure out what's going on here but it is really strange. It looks like SMPlayer is not writing to the MPlayer process. @Diver: where is the source code of SMPlayer with the OS/2 specific enhancements ? Could you try to recompile SMPlayer using Qt 4.7.3 and see if the problem persists ?

[Silvan Scherrer]

@Rudi: i try to build smplayer with Qt 4.7 soon, but if you want feel free to try it earlier ;-)
The source is at ​http://svn.netlabs.org/qtapps/browser/smplayer/trunk[[BR]]
There is a build_os2.cmd which should work out of the box

[rudi]

O.K., what we see is a message loop deadlock caused by the use of QProcess::waitFor...() functions in the main GUI thread. It will trigger only when MPlayer has a PM window open. I'd say that this is an example of poor coding on the SMPlayer side, which happens to work in version 4.6.3 only by accident. See the warning here: ​http://doc.qt.nokia.com/latest/qprocess.html#waitForFinished

So I suggest to change SMPlayer as seen in the attachment.

[rudi]

Replaced waitForFinished() by an eventloop

[Silvan Scherrer]

@Rudi: thx for the finding and the fix. i will add it hopefully this week and release a new version

[Silvan Scherrer]

please try ​ftp://ftp.netlabs.org/pub/smplayer/smplayer-0_6_9-b3.zip

[guzzi]

Works flawlessly. Fixed.

[Silvan Scherrer]

thx for testing

[psmedley]

I think there is a problem with waitForFinished() in 4.7

Scribus fails when trying to check if Ghostscript exists:

The code snippet is:
bool testGSAvailability( const QString& gsPath )
{
fprintf(stderr,"testGSAvailability( const QString& gsPath )\n");

QStringList args;
args.append( "-h" );
QProcess proc;

qDebug() << gsPath;
qDebug() << getShortPathName(gsPath);

proc.start(getShortPathName(gsPath), args);

if (!proc.waitForStarted(5000))

return false;

proc.waitForFinished(5000);
return (proc.exitCode()==0);

}
gsPath is e:/gs/gs8.71/bin/gsos2.exe and args = -h

proc.waitForFinished(5000) never returns. when I add a debug printf before and after it, only the first one prints...

[Silvan Scherrer]

opened a new ticket:266 for the waitForFinished() issue