Custom music discs cut off when vanilla disc would normally end

Confirmed in 1.19.4 pre-release 3.

Confirmed in 1.19.4 release candidate 2.

You don't need to list affected versions in the description; the affected versions field serves that purpose.

I know I don't need to list the affected versions of this bug on the description, but there are versions that I couldn't put on the affected versions box.

And having those intermediary/outdated versions listed adds nothing to the report.

Ok, I changed it.

Confirmed in 23w16a.

Confirmed in 23w17a.

Was this issue present in 1.19.3, when bedrock parity to the jukeboxes? I'm wondering if, along the way, the lengths of the discs were somehow hard-coded, forcing custom music to come to a dead stop. Would be nice to have an assignee right about now.

Confirmed for 23w18a.

Persist in 1.20-pre1.

Still a problem in 1.20 pre2.

Confirmed for 1.20-pre5. I now know why the lengths of discs are hard-coded and come to a dead stop at that time. This is all unfortunately as intended.
As part of Bedrock parity, when a music disc reaches the end of its track, it wants to allow for any other music discs to enter seamlessly, specifically through a hopper, as the current music disc is ejected. To replicate the goal:

1. Place a hopper, place a jukebox directly above it, and place another hopper connected to the jukebox.
2. Place two music discs into the hopper going into the jukebox. One disc will immediately begin playing, the other will remain in the hopper.
3. Once the first music disc has reached the end of its hard-coded length, it will immediately stop playing, and make its way to the hopper below the jukebox. Simultaneously, the second disc from the other hopper will be inserted and immediately start playing.

As you can guess, the game certainly doesn't care how long each record of the client's resource pack is, as each client can be on the same world with different packs with different lengths for a certain disc. That's why the lengths of the records are hard-coded, so that the mechanics of being swapped in/out of jukeboxes is the same for everyone. It undisputedly sucks that we have to kiss the idea of custom-length music discs goodbye, as it's been a staple since 2013 with Minecraft 1.6 allowing custom audio, but it is what it is. Hopefully there may be mods out for anyone who wants to bring back the old mechanics.

Not necessarily; it could still be allowed to keep playing, and send a stop command to clients upon pulling out only, rather than upon the duration being reached.

Given that this is a Bedrock bug as well, you may be right. I could've sworn that this wasn't always a bug on Bedrock since it was added, but looking at the related bug report, apparently I've been mistaken, and it's been an issue ever since hopper/jukebox mechanisms were added. On the topic of this Java bug, I agree that, if no hoppers are placed under the jukebox, the track should play indefinitely. But since this has never been correctly implemented in Java or Bedrock since the mechanism has been added, I'm not so sure it'll happen soon. We'll just have to wait and see.

Still occurs with official release of 1.20

Just noticed this issue in 1.19.4, it's completely broken one of my custom resourcepacks. Is there any workaround for 1.19.4 in particular that's been found? Could it be patched by a mod?

Still occurs with official release of 1.20.1 😞

Probably some helpful info: this is fixable. I remember when the Better Together Update for Bedrock came out, the hopper mechanics for discs and jukeboxes were implemented, AND the tracks were not abruptly cut off if they were longer lengths than default. Of course, it's bugged now in Bedrock and in Java. And with no mods available to fix, we sort of have to pray that someone notices this and decides to fix. I hope this information helps, not that it will speed things up probably.

This issue being fixed could be quite revolutionary for map developers if they would like to play a song longer than the original disc's duration.
The following Code Analysis and Fix is just one of many solutions that Mojang could do to fix this situation!

Code Analysis:

The following is based on a decompiled version of Minecraft 1.20.1 using MCP-Reborn.

net.minecraft.world.level.block.entity.JukeboxBlockEntity.java // Original

public class JukeboxBlockEntity extends BlockEntity implements Clearable, ContainerSingleItem {
    ...
    @VisibleForTesting
    public void startPlaying() {
        this.recordStartedTick = this.tickCount;
        this.isPlaying = true;
        this.level.updateNeighborsAt(this.getBlockPos(), this.getBlockState().getBlock());
        this.level.levelEvent((Player) null, 1010, this.getBlockPos(), Item.getId(this.getFirstItem().getItem()));
        this.setChanged();
    }
    ...
    public void setItem(int p_273461_, ItemStack p_273584_) {
        if (p_273584_.is(ItemTags.MUSIC_DISCS) && this.level != null) {
            this.items.set(p_273461_, p_273584_);
            this.setHasRecordBlockState((Entity) null, true);
            this.startPlaying();
        }
    }
    private boolean shouldRecordStopPlaying(RecordItem p_273267_) {
        return this.tickCount >= this.recordStartedTick + (long) p_273267_.getLengthInTicks() + 20 L;
    }
    ...
}

As we can see, there is no way to determine a custom length of a music disc, therefore the game stops it to the default record's duration. This can be seen at JukeboxBlockEntity#shouldRecordStopPlaying

Fix:

net.minecraft.world.level.block.entity.JukeboxBlockEntity.java // Updated

public class JukeboxBlockEntity extends BlockEntity implements Clearable, ContainerSingleItem {
    private long customDuration;
    ...
    @VisibleForTesting
    public void startPlaying(ItemStack itemStack) {
        this.customDuration = itemStack.getTag() != null ? itemStack.getTag().getLong("CustomDuration") : -1;
        this.recordStartedTick = this.tickCount;
        this.isPlaying = true;
        this.level.updateNeighborsAt(this.getBlockPos(), this.getBlockState().getBlock());
        this.level.levelEvent((Player) null, 1010, this.getBlockPos(), Item.getId(this.getFirstItem().getItem()));
        this.setChanged();
    }
    ...
    public void setItem(int p_273461_, ItemStack p_273584_) {
        if (p_273584_.is(ItemTags.MUSIC_DISCS) && this.level != null) {
            this.items.set(p_273461_, p_273584_);
            this.setHasRecordBlockState((Entity) null, true);
            this.startPlaying(p_273584_);
        }
    }
    private boolean shouldRecordStopPlaying(RecordItem p_273267_) {
        return this.tickCount >= this.recordStartedTick + ((this.customDuration == -1 ? (long) p_273267_.getLengthInTicks() + 20L : customDuration * 20L));
    }
    ...
}

With an ingenious fix I came up with, and the help with CompoundTags, this updated piece of code allows players to choose the CustomDuration of Music Discs, since there's no possible way to calculate the duration of music discs through resourcepacks, players instead can choose the duration of a music disc based on seconds.

For example, to give myself a music disc that will automatically stop playing after 5 seconds would look like:

/give @s minecraft:music_disc_cat{CustomDuration:5}

Upon playing this disc, it will automatically stop playing after 5 seconds.

This can be used to now, bypass the vanilla duration.

For example, to give myself a music disc that will automatically stop playing after 5 minutes.

/give @s minecraft:music_disc_cat{CustomDuration:300}

The only way now is to use the /playsound command. It sucks so much, there should be an option or a server  plugin or even a mod to fix this. I have multiple packs, with disc changing music and they are all broken now. 

Just noticed this bug in 1.20.4, definitely not fixed yet!

Edit: this mod is now available for 1.20.1 as well, and I plan to release a 1.20.5 version as soon as 1.20.5 releases.

I have created a mod that implements a simple fix for this bug. The fix is implemented on the server side, and the mod is currently available for 1.20.4. The mod can be found here, with its source code available here.

The fix is implemented in the JukeboxBlockEntity class, which looks as follows (decompiled Minecraft 1.20.4, using Mojang's official + Parchment MC's mappings):

public class JukeboxBlockEntity extends BlockEntity implements Clearable, ContainerSingleItem {
    ...
    private void stopPlaying() {
        this.isPlaying = false;
        this.level.gameEvent(GameEvent.JUKEBOX_STOP_PLAY, this.getBlockPos(), GameEvent.Context.of(this.getBlockState()));
        this.level.updateNeighborsAt(this.getBlockPos(), this.getBlockState().getBlock());
        this.level.levelEvent(1011, this.getBlockPos(), 0);
        this.setChanged();
    }

    private boolean shouldRecordStopPlaying(RecordItem record) {
        return this.tickCount >= this.recordStartedTick + (long)record.getLengthInTicks() + 20L;
    }
    ...
}

Usually, when using a jukebox, the stopPlaying method will be called twice: first when the shouldRecordStopPlaying method returns true, and then again when the record item is removed from the jukebox. In the stopPlaying method we can find the following line of code:

this.level.levelEvent(1011, this.getBlockPos(), 0);

This line causes the server to send a level event packet with event code 1011 to the clients, which causes the clients to stop playing the record. The fix I implemented is very simple, and looks as follows:

if (this.getTheItem().isEmpty()) {
    this.level.levelEvent(1011, this.getBlockPos(), 0);
}

This fix causes the server to only send the level event packet to the clients once the disc is removed from the jukebox. This stops a custom record from being cut off when the vanilla one would end (which is when the shouldRecordStopPlaying method returns true), but otherwise has no impact on the vanilla behaviour of a jukebox. The only disadvantages I have noticed is that a jukebox stops playing note particles when the vanilla record would end, and that a hopper will remove a record from the jukebox as soon as the vanilla record would end. These could be fixed by implementing @Apollo's fix, with the disadvantage of requiring a custom NBT tag.

@eclipseisoffline First of all, bless you for this. Secondly, if the mod doesn't need to be installed on client, how can it work on Singleplayer worlds? I don't play on servers that use Fabric.

@Chase Hi, Minecraft singleplayer worlds run a server on the inside. This means that if you install my mod on your Fabric client, jukeboxes with custom discs will work again in singleplayer worlds. They still will not work on multiplayer, for that to happen the server you are playing on would have to install the mod. Unfortunately I don't think there's a solution for this, unless vanilla Minecraft implements a fix.

@eclipseisoffline This may not be the place to ask, but idk where else to go, but can I persuade you to port your mod to 1.20.1 Forge?

@Chase I usually don't code mods for Forge but since this is such a small mod I might make one if I have time within the next few days

Would Neoforge be okay? I'd rather not code for Forge due to controversies regarding it and Forge mods should be compatible with Neoforge.

i had to spend an hour fixing custom disc sound files, disc names, and textures because of this bug. i REALLY hope this gets fixed at some point, eclipseisoffline proved it can be fixed while still keeping redstone functionality, and it seems like an easy enough fix

Finally, an assignee! Thank you, Brandon

Amazing, it's finally been resolved!