When a new torrent is being added, I've noticed that the non-silent dialog box blocks all downloads/uploads. This gets to be problematic when I want to change a bunch of options for the torrent in question. It's even worse if I click on a magnet link instead of downloading a torrent file, as the magnet could take some time to download, and by that time, I may have left the computer to do something else (or even just left that desktop to work on another one), which will then pause all my torrents, whether running or queued.

I've also noticed that if I click on a magnet, then decide that I need to leave, and then choose to download the torrent instead, when the magnet finally does download, it notices that it's already running/queued and pops up a message to that effect. This also seems to block all downloads, which means that if I have left (usually the case), nothing gets downloaded/seeded until I return and notice.

I think these are both bugs.

Addendum: I'm using the latest (at the time) SVN code.

This can't happen, modal dialogs do not block anything, seeing that the event loop continues.

George said:
"This can't happen, modal dialogs do not block anything, seeing that the event loop continues."

Yet it _does_ happen: when a magnet is downloaded, it pop-up a windows. and while that windows is open, all download activity stop.
Sure the event loop 'continue', but that does not prevent a poorly placed mutex lock, for instance, to eventually dead-lock everything else...


ok so I browsed the code a bit.
could it be possible that the slot void Core::onMetadataDownloaded(const bt::MagnetLink& mlink, const QByteArray& data,bool silently)
is invoked as a callback from libktoreent.. the former block on the Dialog call (the silent options doesn't seems to be honored or settable in the application for this case), so if it is a synchronous callback, then libktorrent get stuck until we get out of this... hence the observed behavior ?

shmget wrote:ok so I browsed the code a bit.
could it be possible that the slot void Core::onMetadataDownloaded(const bt::MagnetLink& mlink, const QByteArray& data,bool silently)
is invoked as a callback from libktoreent.. the former block on the Dialog call (the silent options doesn't seems to be honored or settable in the application for this case), so if it is a synchronous callback, then libktorrent get stuck until we get out of this... hence the observed behavior ?

It seems that Qt prevents you from entering a timer handler recursively, resulting in the call that updates libktorrent to not get called anymore until the dialog's event loop is done. Using a queued connection to onMetadataDownloaded, you can prevent this.

Will fix it shortly.

Will fix it shortly.

Thanks for looking into it.

While you are in the vicinity, could you add a preference to be able to set the bool siliently to TRUE for magnets ? (or use the existing preference 'open multiple torrent silently' for that purpose)

something like (completely untested... not even compiled)

Code: Select all

        bool ViewModel::dropMimeData(const QMimeData* data, Qt::DropAction action, int row, int column, const QModelIndex& parent)
        {
                Q_UNUSED(row);
                Q_UNUSED(column);
                Q_UNUSED(parent);
                if (action == Qt::IgnoreAction)
                        return true;
               
                if (!data->hasUrls())
                        return false;
               
                QList<QUrl> files = data->urls();
                foreach (QUrl file,files)
                {
+                  if (Settings::openMultipleTorrentsSilently())
+                  {
+                      core->loadSilently(file,QString());
+                  }
+                  else
+                  {
                   core->load(file,QString());
+                  }
                }
               
                return true;
        }



As of 4.1beta1 there is an option to open all torrents silently, magnet links included.