If we connect a hopper towards and another out of a jukebox, they would be "activated" (i.e., locked) while the jukebox is playing, so no disc movement occurs. When the jukebox finishes playing, it unpowers, allowing the hoppers to give the jukebox a new disc. The whole process should take at most 2 ticks: the lower hopper takes away the disc, the upper hopper may need to wait for 0.1s, and then it should succeed in pushing a disc to the jukebox in the next tick.
But if the player leaves the area and unload the chunk when the disc is still playing, and leave the game, the jukebox no longer remembers that it is playing (this is marked to be "won't fix" in another bug). The jukebox thus unpower. But for some unknown reason (i.e., probably a bug), it unpowers for at least 0.4s, as can be seen in the experiment shown in the referenced video below. This makes it unnecessarily hard to build a jukebox multi-disc loop, requiring a multi-component circuit rather than a simple 4-tick repeater.
Ref:
https://www.youtube.com/watch?v=OFQqkTPiXmA
Note: the quartz blocks in the video enclose exactly one chunk.
Related issues
Comments
GoldenHelmet
GoldenHelmet
Could you explain in more detail what you expect to happen vs. what happens in the video? All I see is that one disc gets taken out of the jukebox and another one starts playing.
migrated
Note the piston on the left. If the signal generated by the jukebox lasts 3 redstone ticks (0.3s) or shorter, the 4-tick repeater should hide the signal gap, so there should be no time when the redstone torch is on. As a result, the piston should never have a chance to push. This is the expected outcome, and is indeed what'd happen if I do not logout the game and join it again (i.e., just move far away to unload the chunk and go back).
But if I relog as in the video, the piston pushed, indicating that the redstone torch emitted a signal before. This is deterministic: every time I do this the result is the same. If the rendering is fast enough I can see the piston pushed and retracted as the chunk is loaded.
When I discover the problem, I've connected the lower hopper to a chest, and I intended to use the signal to lock a hopper below the chest to prevent the discs in the chest to be drained. This circuit works perfectly, until I relog. Then a couple of discs are pulled out unexpectedly.
migrated
Note the piston on the left. If the signal generated by the jukebox lasts 3 redstone ticks (0.3s) or shorter, the 4-tick repeater should hide the signal gap, so there should be no time when the redstone torch is on. As a result, the piston should never have a chance to push. This is the expected outcome, and is indeed what'd happen if I do not logout the game and join it again (i.e., just move far away to unload the chunk and go back).
But if I relog as in the video, the piston pushed, indicating that the redstone torch emitted a signal before. This is deterministic: every time I do this the result is the same. If the rendering is fast enough I can see the piston pushed and retracted as the chunk is loaded.
When I discover the problem, I've connected the lower hopper to a chest, and I intended to use the signal to lock a hopper below the chest to prevent the discs in the chest to be drained. This circuit works perfectly, until I relog. Then a couple of discs are pulled out unexpectedly.
GoldenHelmet
I tested this for a while with various configurations of repeaters, dust, solid blocks, redstone torch, and piston, and got inconsistent results. The setup shown in the video does show the problem every time, but various other setups only fail to behave as expected some of the time. For example, with a single repeater set to 2 or 3 ticks of delay pointing into a sticky piston that retracts a redstone block when depowered, relogging may or may not trigger the sticky piston to retract if you relog while the contraption is within simulation distance.
While differential analysis of cases is difficult, I believe the primary problem is due to MCPE-58151, and the randomness when relogging close to the contraption is due to MCPE-180268 or both. In other words, it is not specifically a jukebox bug, but instead a repeater bug and a redstone-relog bug. If you agree that those issues can account for this one I will resolve the report as a duplicate. If you are not convinced we can try to dialogue further.
GoldenHelmet
I tested this for a while with various configurations of repeaters, dust, solid blocks, redstone torch, and piston, and got inconsistent results. The setup shown in the video does show the problem every time, but various other setups only fail to behave as expected some of the time. For example, with a single repeater set to 2 or 3 ticks of delay pointing into a sticky piston that retracts a redstone block when depowered, relogging may or may not trigger the sticky piston to retract if you relog while the contraption is within simulation distance.
While differential analysis of cases is difficult, I believe the primary problem is due to MCPE-58151, and the randomness when relogging close to the contraption is due to MCPE-180268 or both. In other words, it is not specifically a jukebox bug, but instead a repeater bug and a redstone-relog bug. If you agree that those issues can account for this one I will resolve the report as a duplicate. If you are not convinced we can try to dialogue further.
migrated
I agree that if the repeater forgets the amount of time that it should stay on after relog, it can be a problem. Agree to close the bug as duplicate for now, and I'll re-test it after 58151 is fixed (judging from the small number, probably won't be soon...).
I'm not sure how your modified design look like, but there is some randomness of the jukebox due to the two hoppers being unpowered at the same time. What will happen next may depend on which one goes first.
migrated
I agree that if the repeater forgets the amount of time that it should stay on after relog, it can be a problem. Agree to close the bug as duplicate for now, and I'll re-test it after 58151 is fixed (judging from the small number, probably won't be soon...).
I'm not sure how your modified design look like, but there is some randomness of the jukebox due to the two hoppers being unpowered at the same time. What will happen next may depend on which one goes first.
Could you explain in more detail what you expect to happen vs. what happens in the video? All I see is that one disc gets taken out of the jukebox and another one starts playing.