Ubuntu with CraftBukkit version git-Spigot-87e2f47-ef13ca4 (MC: 1.9) (Implementing API version 1.9-R0.1-SNAPSHOT)

Seems fixed on our latest update as well. No breakdown, no methodology, if you want precise advise then DM me and be sure you've tested with NO plugins. This bug is fixed according to me and others. Thank you MD_5. And thank you to the devs in general. I will have more precise bug reports in the future - I promise.

It does seem to be fixed on our server. It has been running smoothly ever since we applied the update. Great job md_5

I only had a few minutes to test after an update to 8e5eab26554f734da63ff4deb13068a69873e949, but it appears this did not solve the issue I am having.

I have a standard hopper chain into a dropper elevator. The bottom dropper will still get clogged and no longer move items. Removing a stack of items from the dropper will restart the elevator momentarily but It will then lockup again. The hoppers also stop passing items even if the next hopper in line has space.

I will post a world example as soon as possible, but It will not be before I get off work today. Maybe someone else can test their dropper elevator / hopper chain and confirm my findings.

A very quick check shows that it is indeed fixed.

Also the funny thing is, I think I found a much much easier reproduction case that worked 100% of the time and was about to open another issue because I thought it was a separate bug. But one of the recent commits seems to have fixed it (I assume the one that fixed this). It basically just involved facing east and placing a block, placing a chest to the left of the block, then standing like in this picture and placing another chest. The chest would reverse to face the other direction and stop playing sound. The chest still reverses direction, but ... still makes sound now.

@md_5 the comparators should have been faced away from the hopper, to show, if there's an item in the hopper

It seems to be fixed in my test world, too! Great job!
Thank god (or md_5) it didn't take months to fix!

Thanks so much! Us and our many farms will be happy. I'm building the updated spigot now and hopefully our actual server will be working.

nice! thanks so much!

I have confirmed this fixed in 8e5eab26554f734da63ff4deb13068a69873e949 with the world provided by Jacob.

@md_5

Doing a full, clean test tomorrow - it's late here in America. Going to use our current survival world, then a clean world - zero mods, just spigot. Going to try all previous methods, plus new ones. I will have breakdowns with screenshots and/or diagrams, if needed. I fully appreciate the attention this issue has been given and will test thoroughly and give a concise breakdown if one is warranted. You've got a day ahead on me, brah, hang on I'll pinpoint this shiz if it's still there.

Here via the attachment feature.

Because no one has provided clear reproduction steps for hoppers. At least with furnaces I can follow what is happening and be sure it is related to this issue specifically. I see a couple pieces of potentially bugged code, but once again I cannot test my fixes if no one gives me anything to test with.

I have a newly generated test world able to reproduce on the newest build for you with a furnace @md_5
Whats a good place to upload it

Why does it have to be reproduced with furnaces specifically? The bug affects hoppers and chests too (like in the world download I posted), and also other stuff like beacons and I heard redstone repeaters (haven't seen that one).

It is definitely not a furnace specific bug. Maybe furnaces would be easier to test with, and I actually did place a furnace in the world I posted on top of some chests, and the furnace reliably breaks for me.

ShawnDaGeek could you elaborate on this?

Also your instructions are pretty much useless to me. My best interpretation of what a "hopperchain" with comparators next to them is attached and nothing happens.
https://hub.spigotmc.org/jira/secure/attachment/11286/u02lomW.png

Pretend I'm five and you're trying to tell me how to reproduce this (with furnaces)

Confirmed for version git-Spigot-90839e6-0ff499c

When chunks are unloaded, priority for ticks is not restored when chunks are reloaded naturally by player.

When player logs out and logs back in the chunks are restored properly.

Effects: Hoppers, Furnaces....

I was having difficulty reproducing it from an entirely new world. But I found that copying the region file of my base that keeps breaking on the real server is enough to reproduce very reliably. We have multiple hoppers and furnaces in specific locations that continuously break, so even if not all of them break at once, something is usually broken.

If anyone wants to test to see if they can reproduce, world download is here: http://starcatcher.us/Moo/brokenspigottest.zip
At spawn there is a sign saying where to teleport to (world spawn couldn't be in the broken area or else the chunks would never unload). We put green arrows and signs pointing to the hoppers and chests that break. I also added a furnace in one of the broken locations, the furnaces in our storeroom freeze sometimes too.

It isn't the cleanest solution to reproduce, but on an entirely vanilla spigot with no plugins (version 90839e6-712213d, built and running on windows) it can be reproduced with this world almost every time you enter and leave the nether. It is very unlikely a plugin is causing it, but if it is whatever it did would be saved in that world (but the plugin list on my server that generated these chunks is entirely different than some other plugin lists I have seen, and again, loading this world in an entirely vanilla spigot can very reliably reproduce it.

Another note, things do break on server start. So you don't even need chunks to unload for this glitch to happen, the glitch will be there the first time the chunks are loaded. Unloading and reloading might cause different things to break.

Sigh, you're all killing me here.
I don't know what a hopper chain is, I don't know what a comparator does, and I can't just wave my magic fix this wand - it's potentially an extremely deep seated issue that could take months to fix (yes, when we were developing snapshot builds we had issues for months).

When I say simplest possible test case, I want furnaces because they do not rely on interactions between other blocks and chunks. Once again, provide a test case with a furnace.

furnace. furnace. furnace. furnace. furnace. furnace. furnace. furnace. furnace. furnace. furnace.

I just reproduced the issue:
build craftbukkit-1.9.jar with latest BuildTools.jar -> CraftBukkit version git-Bukkit-1865896 (MC: 1.9) (Implementing API version 1.9-R.01-SNAPSHOT)
no plugins!
run with java.exe -Xmx1024M -Xms1024M -jar "craftbukkit-1.9.jar"
eula=true in eula.txt
run again with java.exe -Xmx1024M -Xms1024M -jar "craftbukkit-1.9.jar"
op yourself
gamemode 1
tp 1000 65 0
build a hopperchain of ~40 hoppers, place comparators next to them for easy readout, put a stack of cobble into the first hopper
tp -1000 65 0
build another hopperchain of ~40 hoppers, place comparators next to them, put a stack of cobble into the first hopper
and now tp between the two places while the hoppers are running, refill the first hopper if the stack completely reached the last hopper
it took me about 20 tp jumps until one hopper chain stopped working

Please fix this, thank you!

Edit:
stopping and restarting the server fixes the hopper chain,
but it took me only 3 tp jumps, to break it again
I placed 25 empty double chests near to the chain that breaks (don't know if it matters)

Many people say they have the problem in the production server, yet it is hard to reproduce this problem on my local test server. I think the number of players or/and amount of server resources (CPU, RAM) might play in this problem.

I just tested it with no plugins at all, and the same hoppers broke in my world. Still going to try to reproduce it in an entirely clean world (the no plugin test where it broke was using a backup of the same map).

You don't have to leave for a significant time, we got the hoppers in our test server to break within minutes. We just went into the nether and back, upon getting back the same hoppers were broken.

Sigh, lets back up yet again.
1) You did not follow my instructions of testing on a clean server install, and have instead used plugins of which we're not even sure if that is a full list.
2) I don't know what a hopper fed furnace is or how to construct one. Lets please keep reproduction to only a furnace.
3) What is a "significant time". Minutes? Hours? Days?

Latest Spigot Build: git-Spigot-90839e6-0ff499c (MC:1.9) (implementing API version 1.9-R0.1-SNAPSHOT)

To reproduce: Build basic hopper fed furnace, add coal and items to cook. Leave chunk for a significant time allowing it to unload or restart server. Upon returning to the area, furnace will be frozen (will not cook) with items inside and hoppers will no longer transfer items from chest or into furnace.

Edit: Relevant plugins: Coreprotect, worldborder, MV-Core, LWC, HomeSpawnPlus 

I'm working on it now, setting up a blank test server where I can do some testing. The world i'm testing in now is already 600MB so probably wouldn't be a good thing to test on.

Well you will need to create and share a test world where it happens reliably in a spot.

@md_5, the issue is random and hard to reproduce. But it has been done without plugins (so many people wouldn't be following the issue if it wasn't)

Some other things that might help are that:

• It only happens in certain spots. The hoppers in my iron farm have never broken once (besides when someone threw a ton of boats in them), but the hoppers in my mob and melon farm break all the time
• It doesn't happen on chunk boundaries or care about those in any way. I'm not entirely sure on this, but it doesn't seem to be any kind of chunk issue (it still could be caused by unloading/loading chunks, it just doesn't seem to happen on chunk borders)
• Chests might be an easier way to test, broken chests won't play a noise. In my storeroom is is always the same chests that break and don't play sounds.

Once you find a chest / furnace / hopper that breaks in a location, that location should work well for testing. Setting up a massive contraption could help more though, since the bug only occurs randomly which makes it hard to know when it is fixed.

You could treat all instances separately, but all the blocks mentioned have similair traits and produce the same symptoms under the same circumstances when methodically testing them
I would advise to test it more thoroughly and on a larger scale to prevent anomalies in your data and to also confirm wether or not it is "all chunks" or "just some"
and possibly figuring out a shared trait between the chunks if it is "just some", and to comfirm it happens to those chunks that belong to the "just some" every time, or that it's different every run

That sounds like a far more complicated test case than the issue being described here. Also not passing between edges on load is likely a different issue entirely.

This issue as it stands is primarily about furnaces being unable to smelt when a chunk is unloaded. Something which I cannot reproduce.

@md_5
`place hoppers feeding into each other inside every chunk in a square of atleast 8x8 chunk
`place hoppers feeding into eachother on the edge of the chunks (feeding from one chunk, to the other)
`Place a stack of items in one of the two hoppers for every chunk
`build a minecart track that goes trough all the chunks, and after that leaves the are for at least n=(renderdistance*16)+64
`hop in minecart
`go trough all the chunks with the minecart
`go n=(renderdistance*16)+64 blocks away with the minecart
`return to area
`Check every hopper for ones that are frozen in time

`Repeat process for both Spawn chunks, and not spawn chunks

`Repeat process go trough all the chunks with minecart,but instead of using the tracks to leave the area try portalling to the nether for both Spawn chunks, and not spawn chunks

`Repeat process go trough all the chunks with minecart but instead of using the tracks to leave the area try teleporting to a far distance for both Spawn chunks, and not spawn chunks

Once again, cannot reproduce using the instructions provided above. Please ensure you are testing with ZERO plugins in a CLEAN server. We cannot look into an issue which we cannot reproduce on our servers. Please provide steps to reproduce which occur in a FRESH server folder.

<~md_5> I've logged out, I've teleported away, I've flown away. In all cases my furnace is still working fine

Hew, i am unable to replicate this in git-Spigot-90839e6-0ff499c. Followed the steps to down to kickall. Do you have any plugins that would catch furnace events, such as jobs or plot management running?

No, not resolved in git-Spigot-90839e6-0ff499c. I replicated it and the hopper/sorter bug a couple hours ago using the exact same methods I described in my previous comment here.

Seems to be resolved in git-Spigot-90839e6-0ff499c Confirmed.

Trying to replicate @hew daily steps to break.

It doesn't happen with the vanilla server so clearly a spigot bug.

The issue even exists with no plugins
No vanilla issue?

ahh.. Let's not hope it is the worst case scenario, corrupted chunks...

Guess it more likely its a deep Bukkit issue then... .. ?

One of the earlier comments said that he encountered it with no plugins at all, so I don't believe that it is caused by plugins.

Happens to us with only spigot and logblock installed
When I add dynmap however mobs also stop moving altogether in certain chunks, same goes for arrows enderpearls pressure plates and other entities
Without dynmap furnaces hoppers brewingstands and possibly more that I cant think of on the spot still stop working when the player leaves the are and comes back until everyone near that area relogs (at the same time)

I can also confirm the server I'm seeing this problem on does not have OnTime installed.

Nope we only use Dynmap, WorldEdit and MultiVerse and I can say for sure that this is not only happening when teleporting.
It also happens when someone just leaves an area and comes back or logs out, the chunks unload and logs back in.
Also like already mentioned it does not only affect hoppers and funances. It effects every ticking block (I observed this behaviour with Redstone repeaters, Hoppers & Furnances).

I don't have OnTime installed and I still have this issue on my server.

There isnt by any means we all use OnTime? Because Ive been working now on localizing where the bug is, and it ended up on the plugin OnTime. I've singel checked doublechecked, and trippedchecked with different locations in the world with burning furnaces. And it appeard they all where frozen when OnTime was loaded, and bug gone when OnTime was disabled.

Tested here too. It's definitly about the load of the chunk it appears.

What I tested with 2 players (yes, without Dynmap) on spigot server updated today. 3 versions behind.

• Furnaces/Hoppers/everything that is triggering get frozen.
• Leaving area deactivating chunk dont help... But logging out and in again reset the issue, as long the chunk is loaded at login. Login from somewhere else, and teleport in will cause the issue to either continue, or to not reset.
• Issue DO NOT dissapear when disabling Dynmap from server. *** <- Just checked that out, with disabling dynmap.jar file completly.

Im not Einstein, and not a good programmer, but... sure this cant be connected to the teleport event malfunctions that have occured since 1.9? just thought the misleading "numbers of location/direction" could affect the chunkload, on those entities that didnt get the spark to start doing their stuff. lol

Hope there is a solution to this. Thanks for all help!

I can confirm this too (private server with about 30 active users).
It is very annoying as it breaks many contraptions we built :/

This bug is not "Minor" - this is server breaking.

We did some testing last night on 2 different versions of Spigot but, since then, Spigot has updated again so I don't know if this applies to the absolute latest. However, as of those other 2 versions this problem still existed...somewhat.

To replicate the problem on CraftBukkit version git-Spigot-f04e043-52c7fc0:
1) Put items in a furnace or auto-smelter (we used an auto-smelter)
2) /tp or run to where the furnace's chunk is definitely unloaded.
3) ALL people on the server then need to log out. We left one person on the server, in AND out of spawn chunks just to see, and couldn't replicate the issue - everyone has to log out.
4) Log back in, go to the furnace, it'll be hung mid-smelting.

To FIX the problem on CraftBukkit version git-Spigot-f04e043-52c7fc0:
1a) One or all players stand in the furnace chunk, have everyone on the server log out, and then log back in.
BUT WAIT - sometimes the fix is:
1b) One or all players stand in a chunk next to the furnace chunk, have everyone on the server log out, and then log back in.

To replicate the furnace problem in CraftBukkit version git-Spigot-90839e6-c5d27c5:
1) We don't know...couldn't replicate it. It seems fixed buuuuut, wait, there's another issue...

If you have a auto-sorting machine using a long line of hoppers and hoppers below those with the 22 items in them to sort out specific items - the standard auto-sorter we all know and love - then DO NOT USE IT YET! Chances are it's broken. We have an auto-sorter that spans 3 chunks across and 2 chunks wide and is about 80 blocks high (3 floors). Why would 80 blocks high matter, right? We're talking about chunk problems and chunks go from bedrock to sky, right? Wrong.

We tested our auto-sorter with CraftBukkit version git-Spigot-90839e6-c5d27c5 and followed the items through the entire sorter. We had to stand in the chunk where the hoppers start, log out, and log back in to get those to move the items along. The items would go all the way to the edge of the next chunk and stop. So again, we'd have to go into that chunk and relog. We did this for every chunk in the 3x2 chunks on the first floor of the sorter. We assumed that, after the first floor and having relogged all the chunks that the items, which did not have a chest to be sorted into, would travel all the way down to the overflow chest on the 3rd floor. Wrong. We had to relog in every chunk, on every floor, until it finally reached the overflow chest. The bug is specific not only to the chunk, but to an area of the chunk. It's bizarre.

Obviously we can't use our auto-sorter and many other hopper-based contraptions we have (anyone out there got automated farms?). This. Bug. Is. ANYTHING. But. Minor! This breaks our server.

Just throwing my voice in here as this is a problem on our server even after disabling dynmap. Dynmap does seem to make the problem worse. I think my ticket was closed as a duplicate to this one.

https://hub.spigotmc.org/jira/browse/SPIGOT-2009

Having the same problem on my server. This makes a lot of redstone projects pointless. A solution would be most appreciated.

Also confirmed on my server as well. borderline gamebreaking with redstone heavy users.

I don't understand why this issue still has no assignee, and is marked "minor". It is clearly affecting lots of people, and is very game breaking. Yet on Stash you can see that right now new API methods are being implemented. Shouldn't this be in the very top of the todo-list? Is there some way of getting the devs to look at it?

Can also confirm this happening on my server as well with almost anything that is running when a chunk unloads/server restart

I have found that hoppers, brewing stands that freeze up start working again after you relog (possibly causing the chunks to load again) on my server

We found a workaround that only works for beacons, you can just have redstone running around it, constantly triggering updates. The second the redstone is removed though, the beacon will go back to being broken (even though it looks like it should be working). So it's not a permanent fix in any way.

I hope the actual issue gets fixed though, because a lot the hoppers in our farms (always the same ones) keep breaking.

Confirmed on our server as well. Just as described.

Okay, it happens in Craftbukkit too.

Yes, despite testing it over and over and not being able to repro on paperspigot, I put it on my production server and the issue popped up again, though it seems less common now. I'll try and recreate it on craftbukkit.

I can confirm the error is present in both Spigot and Paper Spigot worlds on our servers.

The error isn't also persistent. The user that caused me to open this ticket had issues right until yesterday now all fine. Another user though...

Oro, I doubt it. I was able to recreate it after first entering an area after a full restart. That means it might still have to do who the chunk is saved, but it seems more likely a load issue.

I tried to recreate this in paperspigot, but couldn't, despite a few attempts at restarting and loading/unloading chunks. Went back to spigot and it happened immediately again. I think that's useful information.

Can confirm that logging out, logging in often corrects the issue so you don't need to tear the build down.

Also, curiously, if you have clearlagg installed, use the unload chunks command while away from the area and then return, this will usually fix the issue too.

So it sounds like something in how chunks are unloaded when leaving the area.

Would be nice to see this bug as a major rather than minor, as it's broken my awesome auto furnace/sorter

Complete exit and re log in seems to fix it sometimes

Having the issue as well. For me it's always the same chunks. Interestingly one of the problem areas, I have a mass smelter/hopper chain where majority are in the problem chunks and two smelters/hopper combinations are not. Those two always reliably work, but every single one in the problem chunk stop.

I have a nether portal several chunks away, not as close as some have mentioned.

No plug-ins and just Spigot (which currently reads 12 revisions behind)

Be happy to give any more info to help find it.

This is a major issue on my server as well. which is only running two plugins (DynMap and PurpleIRC). It is certainly a higher priority than "Minor".

Has someone experienced this on Craftbukkit?

This has been a large issue on our "vanilla" 1.9 server. We have had to tear down many red stone devices and avoid hoppers and furnaces as much as possible. Please move this up to a major level issue. We also don't run any mods, but use spigot for its better performance. Thanks cam

This is a serious break and should have been placed under "major" bug, not "minor" Please read the priority descriptions better next time.

This bug breaks the function of normal items, to where they usually have to be broken and replaced to function again. This isn't "critical" as it doesn't cause it to crash or anything, but it is, indeed, serious.

Some state that "unloading and reloading the chunks" tends to work - I have YET to have this work. I TP out, the chunks go inactive, I TP back and that is what causes the error, but I've never had it fix the error. Relogging also doesn't appear to work.

This was found on a Vanilla server - as in - No Mod Plugins. Just 1.9 MP. No grief control, no creeper nerfing, nothing. Flat out "just downloaded" 1.9.

Cat73, only hopper-transfer and hopper-amount is used after 1.8.3, and your hopper-transfer value is default.

If it's related to anything in the spigot config, it may have to do with tile entity throttling via max-tick-time.tile value. I doubt it, but maybe.

Temporary solution
The spigot.yml file here can be modified to the following
hopper-alt-ticking: false
ticks-per:
hopper-transfer: 8
hopper-check: 0

This method will increase the cost of the server

@PseudoKnight, i'm still getting this without dynmap so that isn't the problem. (note that with dynmap i'm getting a similar but far worse problem with frozen chunks, but that isn't related).

From what I can tell it always seems to be the same things. The hoppers on my mob / sugar cane farms always break, but the hoppers on my iron farm never have. The chests without sound always happen in the same positions too.

It's really annoying, for now we just constantly replace the hoppers on the broken farms.

Ran into this today. (including the chest sounds not working in some chunks) It's like the hopper's TileEntity is not being added to the tick list on chunk load. Could this be from Dynmap? I plan to try and test it, but who knows if I can reproduce it on my test server. I can't shut down my production server to test that.

Thanks @quat, works a treat! Haven't spotted anything significant in the NBT data for chests that make sound vs those that don't so far, so that may have shot that theory down

^ Yes there is, /blockdata X Y Z {} will print the block's NBT data to the chat. Curly braces are important.

I checked lots of chests in my base; some made sounds (every time opened/closed) and some didn't. I saw no notable pattern in their co-ords - there could be two right next to each other, not straddlng chunk borders, and one would make sound and one wouldn't. I the tried one single chest that wasn't making sound, I destroyed it and placed a new single chest there in the exact same place, and the new one did make sound. The chest was empty before and after, so I don't think it's down to the chest's inventory contents or anything.

Is there a way to inspect the NBT data for a block to look for differences?

Yeah, it seems anything that involves those chunks unloading and loading can sometimes fix it - as per my previous comment, teleporting to spawn so the chunks unload then teleporting back can work.

I'm seeing this problem with the defaullt Spigot hopper-related settings (alt-ticking" false, and ticks-per hopper-check and hopper-transfer both 8, and hopper-amount 1); I also tried changing the ticks-per values to 7 for both, but the problem continues.

For what its worth logging out and back into the server can often fix the bug. Its not always 100% but if you do it enough times it seems to work. We have one player who needs to do it three-four times to get a z spawner working correct.

Not ideal but is a temp workaround.

It's confirmed chunk based, and, it appears at the same time this effect occurs, chests make no noise opening/closing.

I had this happen to some chest/hopper/furnace/hopper/chest system and behind it (in the same chunk, 12 blocks away) the chests made no noise, but 4 blocks away the chests worked/sounded fine. next to furnace.

Can confirm beacons affected on our server too. Seems to be any element that needs to have its status saved when a chunk is unloaded. Whether its saving incorrectly or loading back up incorrectly it affects brewing, furnaces, hoppers, beacons for an increasing number of users on our server.

In light of that I'd humbly request maybe a higher priority than minor. It effectively makes redstone a no go as theres no guarantee leaving your chunks won't require the whole thing torn down and rebuilt.

I've also had this problem on our Spigot 1.9 server, kept fully up to date, as have other players. I verified earlier that a hopper had stopped feeding items to a chest - it had items in its inventory, but they weren't being pushed. I teleported myself to the world spawn point, waited, then teleported back, and the hopper started pushing items.

EDIT: I've seen it affect other hoppers too - e.g. a chain of hoppers, each pushing to the next - several were full, then one just wasn't pushing to the next hopper in the chain, so it and those after were all empty. The hopper that wasn't pushing wasn't on a chunk boundary, but was a block away from one.

I've also seen a beacon stop working, too.

Not for this error no, but there other bug reports (closed sadly) that I experience that exhibits this behaviour. SPIGOT-1653 for instance

Is there anything in the server log file, like "Attempted to place a tile entity (net.minecraft.server.v1_9_R1.TileEntity...) at 0,0,0 (BEDROCK) where there was no entity tile!"?

It seems to be chunk based. In some chunks, all hoppers will stop working in my experience, and then other hoppers right next to them, but across a chunk border, will work fine. Don't know if related, but we are also experiencing similar behaviour with beacons not activating their effects.

I have same problem on my network that running latest spigot 1.9

I've just spotted something similar on our server. In an array of four furnaces near a portal, three work fine but a fourth - that happens to be in the same chunk as the portal, is exhibiting this glitchy behavior.

Not had time to extensively test this yet.

This also affects brewing stands, and chests to a degree (the chests do not play a sound when you open or close them)

You can temporarily resolve the problem by removing the affected block and replacing it. Block updates or the like don't do anything. (This of course sucks pretty bad if you have a complex redstone system)

It might have something to do with the nether portal? We have a portal in chunk 15 4 9, and my furnaces to the east in chunk 19 4 10 are not affected, while the ones in 20 4 10 are. The server render distance is 10 chunks.

In the affected chunks it can be standalone furnaces or complex furnace/hopper arrays, the elements just freeze on a chunk reload. That said one of the players found a temporary workaround if it helps shed any light on the cause. I need to review it but they tell me:

"I found a temporary fix for my problem, before tpaing or unloading my chunks via teleport I can just hop into my nether portal and do that it fixes it"

Experienced this a lot with hoppers, haven't noticed with furnaces, but I don't have a setup of that kind. Other people on my server has though.

Actually, I can also replicate this if I too build a furnace in this players area, leave, unload chunks and come back - the furnaces i built are all frozen. I can't replicate in other areas of the map.