Comparator not updating status after reloading chunks

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.

Best workaround for now is to essentially BUD the comparator. I place a piston right next to it conected with redstone to a buttonand when I log onto my world I hit that one button and all the pistons in my base go off and reset the non-updating comparators essentially. Really big fix though, since I'm sure it won't be a problem in 1.5 :S

I have 256 comparators in my base only for item sorting, I don't want to build 256 pistons, which will make my setup a lot larger, just for a bug which should be fixed.. I don't understand why mojang doesn't look into this one, it's a major bug.. So everyone thumb it up?

Unable to reproduce in 13w04a, both with comparators directly pointing from the hopper or with a block in-between.
Teleported 10 million blocks away and logged out from SMP for several minutes, logged in and returned. The storage minecart was able to move away after it emptied out the contents of the hopper.
Please upload screenshots to make sure your redstone wiring is correct.

Thanks for going to so much trouble to try to recreate the issue, Martin.

Unfortunately, the problem is indeed still present in 13w04a. I tested the same rail/hopper configuration, even broke the comparators and placed them back, just in case that made any difference. It did not.

Lag was practically eliminated from this test because the SMP server being tested was accessed directly by the op player on the LAN, no other players were on.

I did manage to simplify the steps to recreate the problem, and even confirmed a new clue: the problem may be directional. Or direction affects it in some way.

I made four pistons activated by button/comparator. Only one of them is affected by this defect right away. The one in my example that has problems is the one in the front left of the picture:

http://imgur.com/GxfZmU2

This screenshot was taken while looking North. So the comparator being affected is the one pointing East. But this behavior seems random. I have another comparator affected by this defect in a completely different circuit pointing South ( the piston is triggered by a block powered from the top).

Just logging out and logging back in triggers the bug, in this case. Subsequent tests did not reveal the same issue each time, so this is highly intermittent.

Also confirmed that block updates do indeed clear the problem temporarily.

http://youtu.be/eckWeXK2Nck Here you go.

Can confirm for CSP, SMP. Always happens to me after server restart. For instance, automatic chicken egg dispenser stops shooting and just keeps collecting eggs (comparator pointing out of the dispenser persists in OFF state)

Can confirm. Very annoying.
Looks like the Same Bug as the One with the repeater back in Time.
If a chunk is not loaded. The comparator freezes in the state (on/off) if the chunk is kicked out of the memory.

Tips to reproduce in smp:

1 Build up this setup: http://m.youtube.com/watch?v=pwEc8ZbWqWE
2 Throw items in the dropper at the bottom.
3 see the items fly.
4 restart the game/unload the chunks
5 redo step 2
6 if items doesn't get pushed through the dropper place a block beneath the comperators
7 laugh about my English ;P

Ok, I know now why it doesn't work and what to do to fix it:
For some reason (I realy don't know why, same happened with dropper duplication) you have to replace all containers placed before 13w04a. I did this yesterday with my 128 hoppers, and after a whole night of inactivty (server was online) It does work. Also a restart doesn't affect it anymore. It's very strange but it does work now.

@Zipron Brendt, can't confirm. Still gets stuck for containers placed after 13w04a.

Hmm, this is very strange, It seems that with some it works, and others it don't.. I don't get it.. But yes indeed you're right, still bugged..

I can make this happen repeatedly with command block output by moving away so the chunk unloads. After heading back in, I need to cause a block or redstone update to the affected comparator to make it start working again.

Video: http://www.youtube.com/watch?v=T4D2AR-b-tI

Can comparators receive random block updates?

http://www.youtube.com/watch?v=UxaP8qtlffA
Client: Windows 8 Pro (JRE 6 Update 38 64bit)
Server: Fedora 14 (JRE 6 Update 38 64bit)

Kimitsu Desu, I was actually thinking about this last night while I couldn't sleep XD, currently they don't, but they should! It makes perfect sense to me, and it would keep everyone from abusing a really usefull bug. I hope that is added!

@Calvin what bug are you talking about? Also, I personally don't think that solving this problem by kickstarting comparators with random block updates is a good idea. Very bad for reliability.