Adam J. Sycz

I don't know how involved it is to code but I always wondered why entity to sound relationship within a time slice is 1-to-1? Within certain radius, new sound from an entity/block should not be generated/processed/emitted if the same type of (other) entity has the sound still playing. At the very least, to preserve ambiance, this should be capped at 3 and no more. Playing tens or hundreds of cows mooing in a pen makes neither any sense nor actually sounds any good with sound bytes eventually cutting each other out, not to mention causing way too many issues to be anywhere near worth it.

This definitely happens in SP after chunk unloading/reloading. Every, single, time. I don't have to break comparators though, any action involving redstone update next to it fixes her up. One of my (hopefully temporary) workarounds is to trigger a signal (from either detector rail or mob falling thru tripwire) next to comparator. It does not have to actually modify comparator's state directly. In one instance I have a redstone torch placed directly above the repeater amplifying comparator signal (hopper load); said torch is operated by falling mob tripwire. The torch is shining onto repeater from top 1 block above - so it has no effect on the actual circuit but seems it works well as my train no longer waits till infinity and I've tested it at least a dozen times now. I do similar thing at unloading station, where arriving cart triggers a signal (just a wire will do) running in the vicinity of the comparator.

One thing I noticed that the comparator attached directly to hopper/chest etc works fine. Trouble for me seems to be with comparators attached via block.