Resume Menu with the last frame of the movie

[rickemail2]

I tested on PowerDVD by pressing down several times when entering the settings menu. If I pressed 3 times - it focuses the 4th item after animation finishes. Does it work for you?

Hi Alexey, yes, your test makes sense. I checked the generated JAR and the new implementation does use a real FIFO queue, so repeated keys like DOWN → DOWN → DOWN can be preserved correctly in a simple menu.
The issue I found appears in more complex navigation, especially when commands are entered while the menu state/segment is changing. Before a key is added to the FIFO, BDS checks currentSegment.rcPressedInterest. If the current segment does not accept that key at that exact moment, the event is discarded before it reaches the queue.
This is why sequences that cross state changes can still lose commands, while a simple repeated DOWN test works. Deluxe appears to capture every key event first and queue it before interpreting the current menu state.
So the FIFO itself seems fine; the main difference is the filtering before the key enters the queue.

[rickemail2]

I tested on PowerDVD by pressing down several times when entering the settings menu. If I pressed 3 times - it focuses the 4th item after animation finishes. Does it work for you?

Hi Alexey, I read the manual and noticed that “Defer keys during animations” is limited to 5 stored key presses and also clears them after about 3 seconds or on some navigation changes.
That explains my test results. The feature is working as designed, but Deluxe behaves differently: it uses a true FIFO and preserves every key press individually, in the exact order received, without this small fixed limit.
Would it be possible to remove the 5-key limit and keep all deferred key events until they are processed? That would make the behavior much closer to Deluxe discs.

[Alexey Kolesnikov]

Hi Ricardo,
Yes, I will increase the limit and adjust some other parameters.

[rickemail2]

Hi Ricardo,
Yes, I will increase the limit and adjust some other parameters.

Hi Alexey, regarding the deferred-key limit: I found that the current implementation uses MAX_DEFERRED_KEYS = 5. Since you mentioned increasing the limit, could you please consider raising it to at least 32?
I tested a FIFO implementation with 32 queued keys and it behaves much closer to the Warner/Deluxe-style navigation I’m trying to reproduce, especially when pressing directions rapidly during carousel animations.
I’m not saying 32 is an official Warner-defined value, but it seems like a very safe practical capacity and would avoid hitting the limit during fast input.

[rickemail2]

Hi Ricardo,
Yes, I will increase the limit and adjust some other parameters.

Hi Alexey,
I tested the new Defer keys implementation again, both with During animations and During animations and transitions. Unfortunately, the behavior is still not the same as on official Deluxe Warner discs.
If I press UP/DOWN/LEFT/RIGHT many times quickly and then stop pressing, BDS often stops before reproducing all the pending movements. On Deluxe discs, the menu continues executing every buffered key in the exact order until the queue is empty.
I checked the generated JAR, and the main difference seems to be in replayDeferredKeys(): it copies the stored keys, clears the deferred queue, and sends the whole batch back to Show.handleKeyPressed() without waiting for each navigation/animation to finish before sending the next key.
Because of this, several keys can be processed while the menu is still in the same old state, or some can be rejected and lost. Increasing the queue to 32 keys or increasing the retention time does not completely solve this.
What seems to be needed is a serial consumer:
take 1 deferred key → execute navigation → wait until animation/transition finishes → take the next key → continue until the queue is empty
That is the behavior I am trying to reproduce from Deluxe.
For example, if I press:
UP → DOWN → UP → DOWN → UP
very quickly, after I release the remote the menu should continue visually executing all five movements in that exact order. Currently BDS often stops before completing the whole sequence.
The new queue is definitely an improvement, but the replay logic still feels different from Deluxe. Could you please check whether the deferred keys can be consumed one-by-one only after each movement/animation is completed?

[Alexey Kolesnikov]

Hi Ricardo,
Could you send me the full, but small project, that I can mux and see the issue?

[Alexey Kolesnikov]

Basically, you can try to replace MediaManagement.java in Classes folder with https://blu-disc.net/download/MediaManagement.7z - does it solve the issue? If not - I need a project.

[rickemail2]

Basically, you can try to replace MediaManagement.java in Classes folder with https://blu-disc.net/download/MediaManagement.7z - does it solve the issue? If not - I need a project.

Hi Alexey, I tested the update, and the navigation FIFO now works as expected. I pressed Up and Down several times in succession, then stopped, and the queued commands continued to execute in the order I had pressed them.

This is exactly the behavior I was looking for. Thank you for the fix!