What explains our FR5 tray-full wait when pockets are still empty?

We use two tray types. I thought it happened on both, but the clips I can actually identify all show the deeper carrier with twelve pockets.

Then say that, rather than both. Do you have a count of placed sleeves at the stop in any of those identified clips?

Also show which recipe the screen says it is using. Not asking you to switch recipes to see what happens, just put the visible selection beside the tray identity already in your evidence.

Chloe's pairing should help. One old support ticket of mine had two plausible video matches because a message was reused. I'd rather have one clearly identified occurrence here than a compilation of stops that might belong to different jobs.

SamBrown, eight sleeves in the identified tray. Chloe, the selected recipe is named for this sleeve family, not the tray. The retained application history reports capacity reached at eight.

Eight sounds suspiciously specific now. What's the other tray's capacity?

Eight pockets. That is why I asked the integrator to compare the selected configuration, rather than asking the operator to fill the remaining pockets another way.

Could be the older tray setting, yes. But let the integrator confirm where that eight comes from; it could also be a deliberately restricted use of the larger tray.

SamBrown's point matters for the person reading the eventual fix note too. Twelve physical holes doesn't mean somebody here should type twelve into an unknown setting.

Has the integrator got the configuration that was actually loaded, Thomas, or just the copy that was intended for that carrier?

Loaded copy and supplied copy both retained. The integrator found the eight-pocket configuration under the twelve-pocket shortcut. Its current handling layout expects the larger carrier; the shortcut still selects the old capacity file.

That's a much better support answer than your tray looks full.

Will the correction cover the shortcut used on the other shift too? I've seen a repaired desktop entry live beside an old one on another account.

Both shift accounts are in the integrator's check. It has corrected the mapping and is checking the two defined tray jobs separately, with the appropriate tray identities and pocket counts.

Can the operator see which tray job that shortcut selected now, instead of getting only the sleeve-family name?

Worth fixing that wording while the mapping is fresh. You shouldn't need this whole thread to explain why the same sleeve uses two tray jobs.

Did the larger tray get through its intended pocket sequence after the correction?

Yes. The supervised verification completed the defined twelve-pocket sequence, and the eight-pocket job still stopped at its own capacity. Both shift shortcuts selected the intended files. The screen now names the tray job as well as the sleeve family. Thanks, Priya, for asking what full meant here. The empty-pocket video showed our complaint; the configuration comparison explained it. We've closed this ticket with those checks attached.