Bug: Minimized Emby for Windows app backlogs UI data updates

[DaninFuchs 1]

Hi all. First and foremost; LONG time user, long time supporter. Love Emby, love the app, strong advocate. I've been converting anyone who will listen, lol.

 

I've noticed this a dozen times but I never manage to document it. Sometimes I minimize the Emby Theater app and leave the PC on overnight. Mostly by mistake. When the app is minimized, it seems to backlog UI updates, and then replay them as quickly as it's able to when the window is restored.

 

FWIW; I'm on Windows 10 but it's not 10-specific. I'm using Emby Server 4.8.0.58 and the Microsoft Store version of "Emby for Windows" 1.1.514.0 but it has been happening for over a year so it's not version-specific.

 

This is difficult to explain -- say I'm on the dashboard. I minimize the app, go to bed. When I wake up and restore the window, the entire night's events will replay in the Admin dashboard. Under the Now Playing header, I can see myself watch a show or two before bed, as well as anyone else who watched anything on the server overnight/early morning. Scheduled Task events will appear and, again, "replay" as quickly as they can. Activity like logins and Alerts all replay in parallel to the rest.

 

It seems harmless enough, but during this time, the Emby Theater client puts a fairly high load on the CPU and the network. I saw a sustained 55Mbit/sec load -- purely because the Emby Theater client refreshes the thumbnail on the Now Playing section every time the UI updates, and the UI is literally udpating as quickly as it can be fed processor time and data to show. One side effect of this is a literal packet flood on the network.

 

I'm not sure if Emby Theater client behavior is different outside LAN, but this could result in extremely high cellular data for some users if it isn't, and they're on a hotspot or other metered data connection with their laptop or such.

 

I -also- suspect that during this time, some or all of that data is being stored in memory -- I'm not sure if it's on the client side or the server side. I doubt it's client-side as my screenshots only show a few dozen MB of RAM usage.

 

Attached are four crappy screenshots.

 

First shows a crop of Emby Theater, and Task Manager showing network activity. All* of this traffic is Emby Theater. You can see it indicating Ridiculousness under "Now Playing" -- I was in bed, the app was minimized, and I was watching the show on my TV in the other room. Also note ~31% CPU usage. This is an i7-8600K, and the only thing -active- is Emby Theater fast-replaying.

 

Second shows the same crop of Emby Theater and Task Manager. This is about thirty seconds later -- long enough for me to save the previous screenshot, switch tabs, and take another. Note Ridiculousness has advanced around a minute in the mean time -- there's a Library Scan going in the background while I'm, playing Ridiculousness, so its updates are slowing down the fast-replay effect. I didn't think to leave it exposed in the screenshots.  Note also in Task Manager, Emby Theater taking 25% CPU and 46MBit network. The window is inactive -- it's -only- fast-replaying the night's events.

 

Third shows a crop of my desktop and the Task Manager, the instant after I closed the Emby Theater app.  Note the INSTANT disappearance of network traffic. Note that my CPU graph still -looks- like it's at ~30% but the number reads 14% CPU load. This is because it hasn't had time to lower the averaging it uses after closing Emby Theater, but it's already started to.

 

Fourth screenshot shows Task Manager a handful of seconds later. Still zero significant network traffic, and now the CPU graph has had time to flatten out.

 

This is a regular thing. If you wish to verify my claims, log in to an Emby server as an admin, open the dashboard on the Windows Emby Theater client (maybe other platforms?) and minimize it, then go watch something on another client a few times. Give it long enough to do a few scheduled tasks. Un-minimize it (helps if you have Window Animations turned off in Windows so it appears instantly) and watch the replay. I just did it while doing some edits to this message -- it happens in under ten minutes, but if your network/server/desktop are fast, you'll probably need more than ten minutes of replay to see it happen.

 

If that's not enough evidence, I'll literally set up a screen recording and a network trace. Just say the word.

 

My thought is that it may be Electron-related, and execution is suspended while minimized, and thus it has to play "catch-up" when restored. My thought is, if this behavior absolutely cannot be properly fixed, instead; check timestamps on the catch-up data vs "now" and suppress UI redraw and thumbnail retrieval during catch-up. Also -always- suppress thumbnail retrieval when it's the same thumbnail as it was last update -- check if the episode/movie is the same, if it is then the thumbnail definitely doesn't need updated; there 100% won't be a thumbnail change until the media being watched is different. UI redraw is likely the majority of CPU load, and thumbnail retrieval is definitely the majority of network traffic. Avoiding those two, network requests and CPU load would still be higher during catch-up but much further from impactful.

While I'm here -- I also noticed that Library Scan scheduled tasks on my library replay REALLY slowly during this behavior. I have a REALLY big library -- perhaps it would be performant to re-examine what triggers a UI update during a library scan, and trigger it less often? My guess based on behavior is that in-server "progress update" events are triggered by the scanner module and sent per-item during the scan, and then clients are notified also per-item -- this should be done once per percentage, or per tenth-percentage. On my library, per-item UI progress updates would result in more than 10,000 UI update events in a single scheduled scan of all content. We definitely don't need to be that granular. We have a progress bar so we know what "done" is -- perhaps UI update trigger logic should be "0.1% or per-update, whichever is less often"?

 

Thanks for your attention. I know it's a lot but I'm trying to be thorough to cover everything in one place. Let me know if I missed anything, or if you need more data.

[Luke 42080]

Hi @DaninFuchsyes I know what you are referring to. Good news is that we are working on a new windows app that does not exhibit this behavior, so stay tuned.

[DaninFuchs 1]

Awesome, that's good to hear. I guess since you might see this, a keyboard hotkey which can toggle fullscreen wether or not media is playing is at the absolute top of my wishlist for the Windows app. Thanks, and be well!