Checkpoint information is shown on the Downloads Page just after Tribler is run

[drew2a]

Describe the bug
Instead of downloads, I see the checkpoint information on the Downloads Page just after Tribler is run. Some time later it turns to the normal downloads.

To Reproduce

1. Search for Ubuntu
2. Download any torrent with low seeders count
3. Close Tribler
4. Open Tribler
5. Go to the Downloads Page

Expected behavior
I expect to see the download but I see the checkpoint information instead.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Tribler's version: main a25df64ad67e263fe84f65a0faa4753737bf914b

[qstokkink]

This is actually not a bug but a feature (introduced in #7024) and it has been designed like this:

tribler/src/tribler/gui/widgets/downloadspage.py

Lines 186 to 197 in 8158747

	checkpoints = result.get('checkpoints', {})
	if checkpoints and self.loading_message_widget:
	# If not all checkpoints are loaded, display the number of the loaded checkpoints
	total = checkpoints['total']
	loaded = checkpoints['loaded']
	if not checkpoints['all_loaded']:
	# The column is too narrow for a long message, probably we should redesign this UI element later
	message = f'{loaded}/{total} checkpoints'
	self._logger.info(f'Loading checkpoints: {message}')
	self.loading_list_item.textlabel.setText(message)
	self.schedule_downloads_refresh()
	return

However, we've had a bug for years where the core would not answer any requests while the checkpoints were still being loaded. So, this feature remained hidden.

[drew2a]

@qstokkink, good to know. :)

Perhaps we could fix the layout for it and leave it as it is?

Although I liked the previous (buggy?) behavior, where a user sees downloads in the familiar layout, but with a "waiting for..." status.

[qstokkink]

The feature was implemented to fix #7032, which states the following:

the user can wait until Tribler starts successfully, albeit with a "Loading" page showing for a very long time.

Apparently, the "waiting for..." or "loading" status was unacceptable to the original reporter (@kozlovsky) and having some form of progress shown was necessary.

Personally, I have no strong opinions on this issue. Both the previous resolution and the proposed resolution are fine by me.

[drew2a]

This behavior was introduced in

• Made TorrentDef.load async and threaded #7666

I've tested it with the following commits:

• d018d66. Works correctly.
• f610c82. Works incorrectly.

Related to (has a common root cause):

• Cannot add a download without a populated file list  #7768

[qstokkink]

@kozlovsky since you introduced this behavior in #7024, are you OK with reverting your changes?

[kozlovsky]

@qstokkink I'm investigating this

[kozlovsky]

The checkpoint counter was initially added to avoid user confusion when Tribler starts with an empty list of downloads. Some users were scared then that "all downloads have disappeared". After the recent updates in the main branch, the delay between the moments when Tribler started and when downloads appeared became even more extensive.

As it turns out, downloads are displayed with a delay because of a blocking call inside the first DownloadManager.load_checkpoint invocation. DownloadManager.load_checkpoint calls DownloadManager.start_download, which in turn calls DownloadManager.start_handle. Then, the entire load_checkpoins loop pauses until enough DHT peers are available before calling ltsession.async_add_torrent to start the actual downloading.

It is possible to fix the issue by splitting DownloadManager.start_handle into two parts, calling the second (delayed) part as a separate task. Then, all checkpoints can be restored without any significant delay.