But when the second dataReadProgress signal coincides with requestFinished AND the progressbar is updated/repainted with the new bytes_read value the IO is broken and the Qhttp instance misses a couple of packets. It seems that when your internet link is fast and the requestFinished signal comes before the second dataReadProgress signal the Qhttp IO can finish in time. The QProgressDialog is started modal and - by design - when started modal you have to explicitly '.call QApplication::processEvents() or QEventLoop::processEvents(ExcludeUserInput) to keep the event loop running to ensure that the application doesn't freeze.' (from QProgressDialog reference) The problem seems to occur more frequently on slow or congested links. The downloaded zips are incomplete but can be fully reconstructed from the tcpdump captures.

I've been experiencing the same problem and spent some time this week trying to find the cause. I am using stable and testing software source. WARNING: FindSubtitlesWindow::uncompressZip: open zip failed: -1000 FindSubtitlesWindow::uncompressZip: zip file '/tmp/archive_J.zip', output_path '', save subtitle as '.sub' FindSubtitlesWindow::archiveDownloaded: file saved as: /tmp/archive_J.zip FindSubtitlesWindow::archiveDownloaded: a temporary file will be saved in folder '/tmp/' FileDownloader::httpRequestFinished: request_id 10, error 0 FileDownloader::httpRequestFinished: request_id 9, error 0 FindSubtitlesWindow::itemActivated: download link: '' FindSubtitlesWindow::itemActivated: row: 1, col 1 FindSubtitlesWindow::currentItemChanged: row: 1, col: 1 FindSubtitlesWindow::currentItemChanged: row: 0, col: 0 FindSubtitlesWindow::updateRefreshButton: state: 0

FindSubtitlesWindow::updateRefreshButton: state: 6

Smplayer subtitles ubuntu