[mythtv] GetMythDownloadManager -> download returning stale data?

Chris Pinkham cpinkham at bc2va.org
Mon Sep 10 15:27:14 UTC 2012

* On Wed Sep 05, 2012 at 09:43:15PM -0500, Robert Kulagowski wrote:
> The files are already pre-compressed on the server, so there's no
> delay there. I'm looking at how the themechooser does things as

If this is the case, then I wonder why you're seeing a 10-second delay
in downloading some of them.

> possible inspiration. I have no idea if users are on dial-up anymore,
> but for any files that are significantly large, 10 seconds may be too
> short a time to complete the download process if it's done in blocking
> mode.

The 10 seconds is for status updates, not completion.  Status updates are
sent out every so often as the download progresses.  You can watch these
with "-v file --loglevel debug" debugging turned on.  QNetworkAccessManager
send out updates and MythDownloadManager receives them and sends out
MythEvents for clients using the non-blocking mode of MythDownloadManager.

> block, would it just be easier set up a loop that checks the download
> directory for the correct number of files, sleep for 30 seconds if
> they're not all downloaded, repeat? Then, if all the files aren't
> downloaded within some reasonable time period, exit the loop, process
> the files that we did download and just move on...

You could, but that's a bit of a hack.  If you use queueDownload(), a
QMap to track queued files, and a customEvent() handler, the you could
either process files as they are downloaded or just delete their entry
from the QMap as they are downloaded so you know if anything was left
or if it was safe to proceed.  The ThemeChooser does the former, it
performs actions when the finished message comes in.  In the second
method, the queue-er could wait on a QWaitCondition after queueing and
the customEvent handler could wake up the queue-er whenever a file was
downloaded and the QMap was updated.  When the queue-er is woken up or
times out, it checks the size of the QMap.  If it is empty, then all
downloads were completed.  If the QMap has anything still in it, then
the wait must have timed out waiting for a download and you can either
process the files you did download or abort.

> A quick glance at mythdownloadmanager.cpp doesn't show any sort of
> timeout for the queueDownload; is there something that will clean up a
> zombie queued download?

There's no cleanup when running in non-blocking mode, you normally just
watch for status updates and will get back the updates for current position
and a finished message when the download completes or fails.


More information about the mythtv-dev mailing list