Download great with Qnetworkreply::readall freeze for a few seconds

Asked

Viewed 84 times

3

When using QNetworkreply::readAll to save the data to a QFile, the moment the download arrives at the end occurs a quick freezing of 2 to 4 seconds and also varies according to the network or site I am downloading, soon after return to normal and the download ends.

It seems to me that the read buffer increases more than normal in the end

Follow an example of code:

int main(int argc, char** argv)
{
    QCoreApplication a(argc, argv);

    QFile file("C:/exemplo/bigfile.7z");

    if(!file.open(QIODevice::WriteOnly)) {
        return 1;
    }

    QNetworkAccessManager manager;

    QNetworkRequest request(QUrl("http://localhost/bigfile.7z"));

    QNetworkReply *reply = manager.get(request);

    QObject::connect(reply, &QNetworkReply::readyRead, [&](){
        QTime time;
        time.start();

        QByteArray ba = reply->readAll();
        file.write(ba);

        int duration= time.elapsed();

        qDebug() << "read" << ba.size() << " bytes of data. (" << duration << " msecs)";
    });

    QObject::connect(reply, &QNetworkReply::finished, [&](){
        qDebug() << "finished!";
        a.quit();
    });

    return a.exec();
}

This problem occurs when I try to download large files like 300mb for example, see the result:

resultado

Note that at the end of the download (almost at 99%) reply->readAll and write, takes 1617msecs and then 2741msecs, that is virtually 4 seconds, see that the readAll in the last two calls returned much more data.

This causes a small crash in GUI applications (which use QWidget).

  • William from what I’ve noticed you’re connecting the events after performing the get call and they’re referencing the reply and not the manager, which is probably why they’re not being fired. Try to put them before the get and the manager.

  • The example of their document works just like Guilherme, see for example this download implementation available: http://www.bogotobogo.com/Qt/Qt5_Downloading_Files_QNetworkAccessManager_QNetworkRequest.php

  • William, you didn’t post a [mcve] so you can’t be sure, but maybe the problem is the fact that you don’t connect to finished and doesn’t close the file at the end. I just did a test (with an example that I myself created here following what you described doing) and it worked perfectly with a file (video) over 700mb.

  • The code of my example: https://dl.dropboxusercontent.com/u/93473897/codigo.zip

  • I’m leaving now, but I see later. Give a tested with my code. :)

  • @Luizvieira Thank you, I’ll see your code ;)

  • I was going to comment that I ran your code here (with the same video I used in my tests) and had no problem whatsoever. :)

  • 1

    @Luizvieira seems that the problem varies according to the NETWORK that I am downloading, in the case almost all sites I surrounded had no problem, however the site of the company where I work generate dynamic downloads sometimes causes this and a static file in http://localhost always cause this, it may be the network that tries to speed up the delivery process, limit the read buffer seems that solved :)

  • 1

    Ah, good to know then that limiting the buffer used can help

Show 4 more comments

1 answer

1


I noticed that readyRead is high only at the end, maybe it is the application or the network that tries to advance the download process, this varies from network to network and according to the speed of the same, or is the problem may occur one time and another not.

In GUI applications it is this long recording time that causes the feeling of "locking" for ~4 seconds.

What you decided was to limit buffer, for this I used QNetworkReply::setReadBufferSize, see difference in result:

com setReadBufferSize

The reading did not exceed 1048576 bytes, which took between 2 and 10 msecs to record, ie did not spend half a second.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.