"Large number of updates" dialog blocks sync even when the device is idle

[strugee]

(Omitting the usual issue template because this is closer to a feature request than a bug, and is pretty open-ended.)

For a few days, my Kodi install has been displaying this message:

You have updates pending. This may take a little while before seeing new content. It might be faster to update your libraries via launching the Jellyfin add-on > update libraries. Proceed anyway?

I didn't hit "yes" because I misplaced my remote. The problem here is that the system clearly had ample time (multiple days) to run the sync, but didn't because it was stuck on the prompt. I see a couple possibilities:

• Just use the update libraries method in this case - this message isn't particularly helpful anyway, because there's really no way to judge a priori which one will for sure will be faster (so we should just make an educated guess for the user)
• If the dialog remains untouched for a while, just run the sync (maybe at like 4 AM or something when the device is less likely to be about to be used?)
• Try running an incremental sync in the background while the dialog is up. Seems technically complicated and, while better than the current experience, not exactly optimal UX.

Personally I'm in favor of the first option, I think. What user, especially a user who is not a core contributor, is actually making an informed decision when presented with this dialog?

[mcarlton00]

There's a few factors in play here, so I'll try to hit on all of them.

First off, to my knowledge that dialog only ever appears when Kodi first starts up. So presumably, it will only appear when a user is expecting to actively use Kodi, not when it's been sitting idle or in the middle of the night or something. The reason this exists is because you might have a lot of updates pending, but instead of waiting for the sync you just want to watch something now.

It might not seem like a big factor, but it's basically impossible to estimate how long each method will take (for us and the user), so it doesn't make sense to just pick one arbitrarily. 700+ updates might only take 2 minutes on my systems, but for somebody running a network of Raspberry Pis or low power devices, that could take 10s of minutes. Kinda a bummer if you want to watch a movie, but have to wait for "watched status" of a few hundred songs to sync first. So it makes sense to ask and let the user defer that update if they're in a hurry.

Running the update if the dialog hasn't been touched for an extended period of time possibly makes sense. The argument against this is that again, it's only meant to trigger on Kodi startup, which usually means the user is sitting there ready to interact with it. However I see this as the most likely candidate if we do anything in this direction. The biggest challenge here is how to wait for program flow while also triggering a countdown to what we should consider "idle". I don't think running it based on a time is a good solution, since everybody operates on different schedules and time zones. However I could see something like after an hour or so, probably configurable in the addon settings.

Incremental sync in the background while the dialog is up is likely to introduce all kinds of threading issues and complexity, so I'm going to say that's not an answer here.

[strugee]

Interesting, thanks for the response. Mine definitely did show up when I wasn't using the device... I wonder if OSMC restarted to apply updates automatically? Or maybe there was a hiccup in the power supply for some reason?

but it's basically impossible to estimate how long each method will take (for us and the user), so it doesn't make sense to just pick one arbitrarily

Right, but I'm thinking the average user wouldn't be able to pick one either. You have to have some idea about Jellyfin's API in order to actually pick something. I certainly don't know - I'm guessing that the "update" library method updates everything all at once in one API call, but the incremental sync makes lots of individual API calls, and that overhead will be significant on low-power devices? Is that the concern?

I wonder if we can keep track of statistics on how long each type of sync tends to take for the user's local network. Then with historical information we could make an intelligent suggestion.

[mcarlton00]

We don't do any sort of data collection, voluntary or otherwise. So there's no reason to generate statistics if they can never be retrieved. Plus it varies so much depending on device speed, device load, network speed, server load, etc that statistics are likely to change regularly from one sync to another.

It basically just exists for if somebody is wanting to watch something now and doesn't want to wait for the update sync. I'm guessing your device had to have restarted for some reason. Either a software update or a power blip or something. However, it's odd that a simple restart could have triggered that dialog. In that situation, you would be up to date at time A, restart the client (we'll assume 5 minutes for a very slow device), and then checking for updates at time B. I can't see how the server could have possibly generated so many changes in that short of a time. It only makes sense if the device/Kodi has been turned off for some extended period of time, during which the server had a lot of changes take place. I believe the default value for that is 999 items, so that's not an insignificant amount of changes that would happen within a few minutes.