Wrong download is resumed when restarted

[sharkwouter]

trafficstars

The last game which was downloading should be downloaded when Minigalaxy is restarted. Instead if downloads the game which was last added to the download queue.

[GB609]

From what i could tell, minigalaxy currently requeues all downloads for all games and up to 4 game files will then be downloaded in parallel. The queueing order more or less depends on the construction order of GameTile(List), which ultimately is the iteration order of Library.games, see Library.__add_gametile.

We'd first have to separate the library listing from the download restarting. We could then change the order before restarting the downloads, maybe depending on the download progress.

Possible order:

1. Percentage high -> low - this is not necessarily the fastest to complete, low percentages of very large games can still effectively amount to more absolute mb than higher percentages of smaller games
2. total remaining bytes low -> high
3. as defined in config.current_downloads - once i've finished LibraryEntry, the logic that updates the download list will retain its order

[sharkwouter]

I honestly don't know if this is still a problem since we implemented the download manager and downloading multiple games at once.

[GB609]

It depends on the amount of pending downloads. If it is <= number(download_workers) there is no real issue / difference. Technically, it'll start becoming an issue again when there are more then 4 game files pending at once. But that would mean that the user clicked "download" for about 4 games or more (less, if these games are multi file downloads)

[sharkwouter]

It seems this still exists.

[GB609]

i've started working on a fix for the order already. The first part was the addition of add_ongoing_download and remove_ongoing_download to config to make sure the list retains its order. The next step is under test, see https://github.com/GB609/minigalaxy/tree/bugfix/507

And the last part i want to change is the logic in LibraryEntry that builds the list of files to download because it does very strange things:

self.download_list = []
files_to_download = []
iterate files:
  files_to_download.insertFirst(file) #just why

self.download_list.extend(files_to_download)

download_finish_func:
  install(self.download_list[-1]) # pick last file, because they are added in inverse order

1. Why use a local, and extends download_list when download list is emptied before?
2. what is the point and use of reversing the list in the first place?

[sharkwouter]

I think we could also reverse the list when we first load it. I'll do a test with that.

[sharkwouter]

I was thinking something like this: https://github.com/sharkwouter/minigalaxy/commit/0e209994c0a928f41636fb8254a81606b5da7d42

[GB609]

This is an entirely different place. I was talking about how LibraryEntry.__download reversed the actual list of ongoing files when doing multi-file game downloads. In this place, the order theoretically should not matter because the game can only be installed when all are downloaded. Also, the in-game download order is not stored in config.

The list in config, however, should be in the order in which download was clicked. I've made sure of that with my last few bug fixes. The problem is that this order is not yet used to restart the downloads when building the library, because the resume is called when the GameTiles are created.

Unless i'm misunderstanding and you really mean to finish the last selected game download first? I personally would probably prefer to have them resume in the order i started them because the one that was started first by my click will likely be quicker to complete as well. Reversing that on restart is just prolonging the duration you have to wait for any game to finish.

Sorry for the confusion

[GB609]

Double post, but easier to track than my frequent edits: Once the download UI is there and i've enhanced download manager to differentiate between 'abort' and 'pause', this might become less of an issue (still need a sensible default behavior, though).

[sharkwouter]

Makes sense!

[sharkwouter]

Did we fix this one?

[GB609]

I'd have to double-check but i think i didn't. I think the last state was that the order becomes less important when the download ui is there.

[sharkwouter]

That is fair, I was thinking that too.

[GB609]

I'd say this is something we can do for 1.4.1