mojira.dev
MC-312671

Jukeboxes forget their playlist position when failing to find the next disc

As an addition of 26.4-snapshot-4, Jukeboxes now loop through the container above. This is done by remembering the position from which the last (usually current) disc is taken (playlist_position in the block entity), and search for the next disc. However, upon failing to find such a next disc, this position is always forgotten, despite the current disc being looped, which ought have kept this “last disc index“ unchanged.

As a consequence, when initially only one disc is in the list and more are added after this disc started playing, the search for the next disc is different when it haven’t looped (from the index of the initial disc) and have looped (from the beginning). Also, since JukeboxMenu short-circuits when the playlist position is unset, when the single disc has looped and other discs are added, no “Next Playing“ is shown on any of the later discs, despite there certainly existing an “next disc“ to be played. These consequences are weird enough that I suspect this is an oversight and is not intended.

Steps to reproduce

  1. Place a Jukebox and a Chest above, and insert into the Chest one single disc (not at the beginning of the Chest’s slots)

  2. Wait until the disc music loops at least once

  3. a) /data get the Jukebox and look for playlist_position field; b) Put two (preferredly not the same) disc in the Chest, one before and one after the first disc’s original position, and observe their tooltips; c) wait until the current music finishes, and observe which disc is being played next.

Expected behavior

a) playlist_position is still set, just like before looping; b) At least one of the items (probably should be the one after the initial position) are marked by “Playing Next“ in the tooltip; c) The disc after the initial position is played next.

Actual behavior

a) playlist_position is unset; b) No “Playing Next“ tooltip in either of the discs; c) The disc before the initial position is played next.

Comments 2

Humm, seems the description is consumed? Is it possible to recover that, or do I need to file the bug again?

Nevermind, I guess I’ll just have to recreate the description and edit into it.

dovisutu

(Unassigned)

Unconfirmed

26.4 Snapshot 4

Retrieved