Freeze with 0 FPS in certain parts of specific worlds

Please force a crash by pressing F3 + C for 10 seconds while ingame and attach the crash report here. If possible, do this in one of these laggy areas.

Minecraft has crashed!      
      ----------------------      
 
Minecraft has stopped running because it encountered a problem; Manually triggered debug crash
 
A full error report has been saved to C:\Users\Darren\AppData\Roaming\.minecraft\crash-reports\crash-2013-03-24_20.54.48-client.txt - Please include a copy of that file (Not this screen!) if you report this crash to anyone; without it, they will not be able to help fix the crash :(
 
 
 
--- BEGIN ERROR REPORT f138c2e2 --------
Full report at:
C:\Users\Darren\AppData\Roaming\.minecraft\crash-reports\crash-2013-03-24_20.54.48-client.txt
Please show that file to Mojang, NOT just this screen!
 
Generated 24/03/13 8:54 PM
 
-- Affected level --
Details:
                Level name: MpServer
                All players: 1 total; [bdw['Mardog11'/491, l='MpServer', x=-325.50, y=143.32, z=100.03]]
                Chunk stats: MultiplayerChunkCache: 441
                Level seed: 0
                Level generator: ID 00 - default, ver 1. Features enabled: false
                Level generator options: 
                Level spawn location: World: (8,64,8), Chunk: (at 8,4,8 in 0,0; contains blocks 0,0,0 to 15,255,15), Region: (0,0; contains chunks 0,0 to 31,31, blocks 0,0,0 to 511,255,511)
                Level time: 149398615 game time, 150460525 day time
                Level dimension: 0
                Level storage version: 0x00000 - Unknown?
                Level weather: Rain time: 0 (now: false), thunder time: 0 (now: false)
                Level game mode: Game mode: survival (ID 0). Hardcore: false. Cheats: false
                Forced entities: 68 total; [qn['Pig'/7584, l='MpServer', x=-256.22, y=76.00, z=106.63], qi['Chicken'/7585, l='MpServer', x=-264.63, y=78.00, z=108.41], qi['Chicken'/7588, l='MpServer', x=-259.66, y=81.00, z=118.28], qi['Chicken'/7589, l='MpServer', x=-266.59, y=73.00, z=163.34], qi['Chicken'/7590, l='MpServer', x=-269.53, y=75.00, z=178.47], qi['Chicken'/73628, l='MpServer', x=-372.47, y=69.00, z=121.47], bdw['Mardog11'/491, l='MpServer', x=-325.50, y=143.32, z=100.03], rh['item.item.egg'/73629, l='MpServer', x=-371.34, y=69.13, z=121.19], rh['item.item.egg'/7575, l='MpServer', x=-275.31, y=48.13, z=93.28], qi['Chicken'/7574, l='MpServer', x=-284.38, y=49.00, z=100.41], rh['item.item.dyePowder.black'/7573, l='MpServer', x=-273.88, y=59.13, z=77.13], qi['Chicken'/7578, l='MpServer', x=-277.53, y=48.00, z=96.81], qi['Chicken'/7577, l='MpServer', x=-279.47, y=50.00, z=101.47], qi['Chicken'/7576, l='MpServer', x=-287.81, y=58.00, z=99.72], rh['item.item.egg'/7581, l='MpServer', x=-287.88, y=50.13, z=104.28], qg['Bat'/81275, l='MpServer', x=-295.46, y=43.32, z=118.84], qg['Bat'/80141, l='MpServer', x=-293.19, y=25.27, z=78.63], qg['Bat'/81060, l='MpServer', x=-350.59, y=26.57, z=59.81], qr['Squid'/81114, l='MpServer', x=-334.00, y=61.69, z=60.86], qr['Squid'/81115, l='MpServer', x=-329.33, y=61.60, z=64.41], qr['Squid'/81112, l='MpServer', x=-329.63, y=62.18, z=60.69], qr['Squid'/81113, l='MpServer', x=-331.93, y=61.69, z=60.85], qi['Chicken'/64453, l='MpServer', x=-307.56, y=62.41, z=138.56], qg['Bat'/80941, l='MpServer', x=-363.35, y=46.49, z=58.25], nf['entity.ItemFrame.name'/64423, l='MpServer', x=-314.06, y=51.50, z=-22.50], nf['entity.ItemFrame.name'/64424, l='MpServer', x=-316.94, y=51.50, z=-22.50], nf['entity.ItemFrame.name'/64425, l='MpServer', x=-315.50, y=49.50, z=-19.06], qg['Bat'/81805, l='MpServer', x=-385.18, y=55.00, z=41.11], qg['Bat'/81803, l='MpServer', x=-382.75, y=55.02, z=43.54], qg['Bat'/82093, l='MpServer', x=-375.50, y=27.00, z=92.50], qg['Bat'/81825, l='MpServer', x=-338.18, y=30.11, z=115.58], qg['Bat'/79690, l='MpServer', x=-316.37, y=45.26, z=52.76], qg['Bat'/82141, l='MpServer', x=-384.50, y=22.00, z=76.50], qg['Bat'/78614, l='MpServer', x=-334.25, y=25.10, z=135.25], qg['Bat'/78616, l='MpServer', x=-328.25, y=30.10, z=128.41], qg['Bat'/81680, l='MpServer', x=-348.91, y=29.01, z=49.08], qg['Bat'/81925, l='MpServer', x=-263.50, y=43.00, z=58.50], rn['entity.MinecartRideable.name'/66691, l='MpServer', x=-325.50, y=142.50, z=100.03], qg['Bat'/81730, l='MpServer', x=-337.25, y=25.70, z=120.42], qg['Bat'/81732, l='MpServer', x=-337.96, y=25.15, z=123.28], qg['Bat'/82034, l='MpServer', x=-363.50, y=29.00, z=34.50], rh['item.item.dyePowder.black'/71820, l='MpServer', x=-354.97, y=60.13, z=164.56], qg['Bat'/79396, l='MpServer', x=-395.00, y=45.48, z=131.42], rh['item.item.dyePowder.black'/77706, l='MpServer', x=-333.81, y=60.13, z=65.72], qi['Chicken'/7827, l='MpServer', x=-255.44, y=74.00, z=168.44], qi['Chicken'/7821, l='MpServer', x=-263.41, y=47.00, z=80.47], qn['Pig'/7852, l='MpServer', x=-300.50, y=58.00, z=104.16], qo['Sheep'/7850, l='MpServer', x=-301.25, y=64.00, z=39.13], qi['Chicken'/7851, l='MpServer', x=-292.56, y=63.00, z=40.56], qg['Bat'/82183, l='MpServer', x=-289.50, y=25.00, z=60.50], qg['Bat'/82182, l='MpServer', x=-291.50, y=25.00, z=63.50], np['Painting'/406, l='MpServer', x=-134.50, y=80.50, z=138.06], np['Painting'/355, l='MpServer', x=-130.50, y=75.00, z=132.94], np['Painting'/354, l='MpServer', x=-133.00, y=74.50, z=132.94], qg['Bat'/82192, l='MpServer', x=-379.50, y=21.00, z=67.50], qg['Bat'/82193, l='MpServer', x=-381.50, y=21.00, z=67.50], np['Painting'/353, l='MpServer', x=-136.00, y=75.00, z=132.94], qi['Chicken'/74670, l='MpServer', x=-389.28, y=67.00, z=167.78], qi['Chicken'/74668, l='MpServer', x=-390.59, y=71.00, z=112.53], qi['Chicken'/74667, l='MpServer', x=-387.44, y=67.40, z=118.56], qi['Chicken'/71791, l='MpServer', x=-349.41, y=71.00, z=94.63], qg['Bat'/81472, l='MpServer', x=-365.75, y=31.57, z=72.17], qg['Bat'/81473, l='MpServer', x=-364.77, y=32.32, z=70.44], rh['item.item.dyePowder.black'/71794, l='MpServer', x=-349.63, y=59.13, z=164.22], qi['Chicken'/71792, l='MpServer', x=-344.31, y=67.00, z=121.47], np['Painting'/310, l='MpServer', x=-130.06, y=75.00, z=123.00], np['Painting'/323, l='MpServer', x=-130.06, y=74.50, z=121.50], qg['Bat'/82300, l='MpServer', x=-267.50, y=40.00, z=119.50]]
                Retry entities: 0 total; []
Stacktrace:
                at bdt.a(SourceFile:282)
                at net.minecraft.client.Minecraft.b(SourceFile:1881)
                at net.minecraft.client.Minecraft.run(SourceFile:535)
                at java.lang.Thread.run(Unknown Source)
 
-- System Details --
Details:
                Minecraft Version: 1.5.1
                Operating System: Windows 7 (x86) version 6.1
                Java Version: 1.7.0_15, Oracle Corporation
                Java VM Version: Java HotSpot(TM) Client VM (mixed mode), Oracle Corporation
                Memory: 104919304 bytes (100 MB) / 519110656 bytes (495 MB) up to 1037959168 bytes (989 MB)
                JVM Flags: 2 total; -Xms512m -Xmx1024m
                AABB Pool Size: 43088 (2412928 bytes; 2 MB) allocated, 3 (168 bytes; 0 MB) used
                Suspicious classes: No suspicious classes found.
                IntCache: cache: 0, tcache: 0, allocated: 1, tallocated: 63
                LWJGL: 2.4.2
                OpenGL: ASUS EAH5450 Series  GL version 4.1.10834 Compatibility Profile Context, ATI Technologies Inc.
                Is Modded: Probably not. Jar signature remains and client brand is untouched.
                Type: Client (map_client.txt)
                Texture Pack: NautiluS39.zip
                Profiler Position: N/A (disabled)
                Vec3 Pool Size: 2788 (156128 bytes; 0 MB) allocated, 17 (952 bytes; 0 MB) used
 
java.lang.Throwable
                at net.minecraft.client.Minecraft.l(SourceFile:1164)
                at net.minecraft.client.Minecraft.K(SourceFile:574)
                at net.minecraft.client.Minecraft.run(SourceFile:526)
                at java.lang.Thread.run(Unknown Source)
--- END ERROR REPORT 199360ec ----------

http://www.fileflyer.com/view/acKlAAG

Can confirm.

Console:

Something's taking too long! 'root.tick.level.connection' took aprox 1962.67523 ms
Something's taking too long! 'root.tick.level' took aprox 1964.822737 ms
Something's taking too long! 'root.tick' took aprox 1968.755671 ms
Something's taking too long! 'root' took aprox 1982.688869 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1966.920684 ms
Something's taking too long! 'root.tick.level' took aprox 1968.995693 ms
Something's taking too long! 'root.tick' took aprox 1971.082171 ms
Something's taking too long! 'root' took aprox 1983.495772 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1974.85659 ms
Something's taking too long! 'root.tick.level' took aprox 1977.086017 ms
Something's taking too long! 'root.tick' took aprox 1978.749383 ms
Something's taking too long! 'root' took aprox 1991.304295 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1980.356634 ms
Something's taking too long! 'root.tick.level' took aprox 1982.692965 ms
Something's taking too long! 'root.tick' took aprox 1984.179386 ms
Something's taking too long! 'root' took aprox 1996.331665 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1969.742385 ms
Something's taking too long! 'root.tick.level' took aprox 1972.023011 ms
Something's taking too long! 'root.tick' took aprox 1973.324705 ms
Something's taking too long! 'root' took aprox 1985.498693 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1966.240346 ms
Something's taking too long! 'root.tick.level' took aprox 1968.28095 ms
Something's taking too long! 'root.tick' took aprox 1969.907452 ms
Something's taking too long! 'root' took aprox 1986.727478 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1961.383366 ms
Something's taking too long! 'root.tick.level' took aprox 1963.612793 ms
Something's taking too long! 'root.tick' took aprox 1965.859013 ms
Something's taking too long! 'root' took aprox 1976.895145 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1973.163324 ms
Something's taking too long! 'root.tick.level' took aprox 1975.548806 ms
Something's taking too long! 'root.tick' took aprox 1978.207079 ms
Something's taking too long! 'root' took aprox 1988.548948 ms
Something's taking too long! 'root.tick.level.connection' took aprox 1958.673485 ms
Something's taking too long! 'root.tick.level' took aprox 1960.981554 ms
Something's taking too long! 'root.tick' took aprox 1962.526957 ms
Something's taking too long! 'root' took aprox 1972.152444 ms

I am having this issue with 13w22a in SP and my SMP server. It doesn't give any console messages, but there is bad lag in a couple spots within the vicinity of a lot of redstone devices.

I'm having this issue in 1.7.4 in SMP- extreme frame rate drops (to 0) in specific locations. Occurs in same locations for all clients. Console messages when debugging are similar to the console output shown above. I restored a backup of the entire world directory (from a point where this didn't occur) and the issue still occurred. I rolled back to 1.7.2 (clients and server) and the issue still occured.

Still happening in 1.7.5

Similar behavior. Just one (or a couple) of chunks in my world.

No obvious redstone/spawner/villager issues.

This issue happens of all the test worlds i make. I tryed many things, like removing separately hooper timers, bud switches, entities. Dead areas still happen, and sometimes move or kinda spread which make the test difficult, because you never know if you have tested all the possible dead areas. I still don't know why this is happening and how to fix it and i searched a lot on the internet. All worlds I make (in different versions, 1.7.4 to 1.7.9) are cursed by this problem, it looks like a big issue and it's surprising that Mojang has nothing to say about it.

Still an issue up to 1.7.9.
Tests done: Ran a utility that checks the world files for errors. None found. No large number of entities. No redstone circuits. Downloaded MCEdit and deleted chunks around where lag occured; did not fix issue (also ran that program's chunk verification utility to no avail; no errors found).
Created a fresh copy of the world using the same seed. No lag encountered in the lag locations.
Experimented with removing certain region files from around the lag areas from the world folder; in the end the issue was resolved. One of the region files must have been corrupted in some strange way, as the lag areas turned out to be right around the 4 corners of that region.
Maybe my issue isn't the same as everyone elses', but checking the areas in a fresh world and swapping out region files is worth a try.

I created a ton of new worlds (using seeds of confirmed cursed maps or totally new ones). At first everything looks allright. Then I try to import my buildings with MCedit (i even recreated them manually on some maps) on the spawn chunks and the nightmare begins. Dead areas start to appear quite randomly. My buildings are basically some blocks, 1 hooper timer with some redstone torches, about 15 pistons activated by a budswitch. I tried different versions, without any redstone, etc. and it didnt delete the lag areas. Moving some buildings seemed to make the dead areas move but I couldnt find any logical process. I just deleted a region with confirmed 0 fps drop on a "built" map. It didnt change anything and i still have 0fps there. FFFFFFFFFFFFFFFFFFFFFF

This game is about to make me terribly mad and i consider to never play it again. Sure u know what kind of madness im talkin about 😛

First i apologize for being so active (and not so useful) in the comment section. I know it can be annoying.

As i previously said I face this very specific issue (a non ending fps drop to 0 in a specific area, for every client on the same world) in EVERY map that I make, Maps are generated and tested from 1.7.2 to 1.7.9 ( but it seems that the problem is older than 1.7 ). I made a lot of versions switches on single maps, that did never solve the problem.

The specific area where the drop occurs ISNT ALWAYS THE SAME when you reload the map/ the client. It can stay a long time on the same place, then you load the map, change version, you delete some regions or buildings and you think the problem is gone. U ARE WRONG, because a (several?) new dead area(s) will appear APPARENTLY WITH PURE RANDOMNESS, BUT NOT SO FAR AWAY.

My tests were focused near the spawn chunks because obviously you want to build certain farms on this area. So all these issues happened near the spawn chunks, but not specifically within those chunks, on the always loaded/sometimes loaded borders, always entities loaded borders, etc.

Those observations make me think that ;
-Players make dead areas "spawn" on the map.
-Those dead areas can somehow "despawn" but the issue affects the world so players will still make dead areas spawn.
-Considering my tests were done building some structures on the spawn chunks there might be a link with those chunks but it's not sure.

I even consider that this could be a global minecraft issue shared by all clients/worlds, which would simply not always be noticed/activated.

Is there someone working on this pretty painful problem ? Just asking considering the issue is quite old and i didn't see any answer about it.

i started having this problem yesterday .. it seems to be only in spawn chunks when i tp far away from the area it returns back to normal .. it's only happening on a server side for me i took my world into single player and there's nothing wrong with it
it exactly started happening when i placed around few chests in one area .. if that helps by any means

I will repeat myself, but when it "seems" that the problem is gone, the dead area might have just moved. It's a painfull process, but fly all over your map and you will find a new fps drop area, almost for sure.

I created a map in 1.4.7 and the issue did'nt appear (i moved a lot on this map) ! updated it in 1.7.9. Issue came back quickly. That seems to confirm my thougts.

As a user i think I can't do more tests. Time to learn Java and do mojangs job maybe

New test done : I only used my server's hosts world generator to generate a completely new world in 1.7.9 (this has not been created nor hosted on my computer). After few minutes, the issue occured. Damn this is so cool...

The problem finally SEEMS to disappear (tested a map about 30 mn) in the latest snapshot (14w11b) !!!!!!!!

Have fun with the pathetics iron farms, the mob and redstone glitches, and enjoy granite and diorite !

This sounds plausible, there are no reports of and 1.8 snapshot on this ticket (yet).

Problem still persists on 14w19a when using world generated by 1.7.9. :<

Edit: Corrected version number I tested it on.

can confirm this, anoying when building an adventuremap

That thing persists on 14w21b on a "already cursed" map. If this isn't fixed in the final 1.8 release i will rage like mad lulz

I am having the same issue on my server that is running the latest snapshots. The problem arose in snapshot 14w21b. We are hoping for this to be fixed in the next snapshot (we are waiting for 14w22a).

Here is a link to the forum I was following before. They are experiencing what seems to be the same problem. http://www.minecraftforum.net/topic/2094750-172-fps-drops-to-0-in-already-explored-chunks/

I don't know what you guys did, but this issue has been resolved for me! All the lag in the lag areas is gone! THANK YOU!!! 😃

@@unknown: Hm, maybe you did change some settings ? Chunk render distance ?

No settings have been changed. As far as I knew, we still had the issue, and we had had it for about a month. I went over today to that area to do some testing, and when I entered the area, the lag was gone. I brought some of our players over, and they confirmed that all of the lag in all of the affected areas is gone.

Did your map get updated, MCedited or something ? Ive been playing (and testing) a map for several months on the same minecraft version, without any settings changes and the issue did never disappear like that...

As I said, nothing has been changed. As far as I know, the lag went away by itself.

Weird. On which minecraft version do you play ?

My post on the subject: MC-56688. I was directed here. The problem started during 1.7.5. Our server currently runs on 1.8 snapshot 14w21b.

So the map got actually updated (1.7.5 to snapshots). As I previously said certain snapshots kinda seem to fix the problem, but sometimes Ive seen the lag area just "move" after the process... All that I can say is that we dont know how this thing works.

Our moment of freedom was short-lived. The lag zone has returned. (No settings have been changed, it has mysteriously come back by itself.)

Confirmed for 14w25b.

The lag behaviour has changed. Before, as soon as you entered the lag area, FPS drop to 0. Now, if you keep moving around, walking or sprinting in the lag area, it's fine. When you stop moving, then FPS drops to 0.

can confirm what Yali said, I have this issue a long time now in the same chunks, however, certain chuns instant freeze you and some take time to freeze your game in my world
still in 14w26c

Solution???
I have had this problem before and now I had it again. Last time it was 160 block from a hopperclock and this time aswell.
I think that I have figured out what causes this. I will try to replecate it in a testworld soon. (I play on a server with 1.7.10) and run windows 7 on my laptop with an nvidia card. (Worth noting is that the render distance on the server is set to 10 chunks, and on my client its set to 16 chunks)

First. To get out of the trouble, you need to disconnect, reconnect and then run as fast as you can back to where you came from.
The problem occurs when you pass a specific chunk border.

When you have gotten out of trouble:
Check 160 block /10 chunks away behind you or in front of you when this is happening.
Is there any redstone contraption there that passes over that chunk border?
Specifically is there any piston or hopper clock passing over that chunk border?
If it is, rebuild it so that it is not.

What happend to me (this time) was tht I got the 0 fps, 0 chunk updates (client side, everyone else on the server was fine).
And since I had had it before, and it solved itself when I broke a hopperclock I had 160 blocks back, I checked if something was 160 blocks back. And yes.. I had a hopperclock there in this case aswell. One of the pistons in the hopperclock just had a hole in it (no pusher) and the piston on the other side moved back and forth like once every second due to this. When I broke and replaced the bugged piston the clock went back to normal. (And so did the problem with 0 FPS 0 chunk updates 160 blocks further away.)
I noticed that the piston that got broken was just on the chunk boarder EXACTLY 160 blocks / 10 chunks away.. So I dont think that it was a coincidence.

What needs more testing is if its a fast clock pulse or if it is a block 36 / broken piston in the unloading chunk that causes the lag.

If everyone that gets this problem could check if you got any "broken" pistons after this? (A piston that is both extended and retracted at the same time or pistons with just a hole in them)
Also check if you have a fast pulse clock.

Another thing worth noting is that this will happen exactly 10 chunks away in any direction you go from the problem. (Thats an easy way to find out where it is.)

Pierre Walden : I did test a LOT of worlds. Did remove some redstone clocks and checked every area in huge radius (more than 16 chunks for sure). As I said sometimes (not always) big changes on the map removed the lag area... but it came again, sometimes in an other area. And the dead lag zone occured (every time after some random movement on the map to check) on totally new maps with no fucking buildings. Im afraid this problem gets no rational solution in game 😞

Jean Dujardin:
Could you upload any map that this is happening on, and tell me the following:
1.) Coordinates where it happens.
2.) What direction did you come from before the lagg starts.
3.) Does it happen anywhere else on the same map?
4.) If so, coordinates of those places aswell.

If you have any map where you havnt built anything, and it still happens, upload that aswell. (Need both a map where you are building stuff and one that you have just walked around.)

I'm sorry but I did those tests some months ago and I kinda gave up, so lot of maps got deleted... If I find the time, I will retest some maps and upload it, but not now 😛

I just did some tests. I built a simple contraption with some pistons and a clock in singleplayer creative. (Render distance set to 16)
I moved away 16 chunks --> Result = Game not responding (Had to force end of process).

I will try again just to make sure that I can reproduce it AGAIN before I give more info.

I opened the world again after the "force quit", and discovered that all the sticky pistons in my contraption (except for the one that I use for the clock) had dissapeared together with the stone blocks I had put in front of them. Only thing that remained was Invissible blocks (thin like piston heads) in the place where the extended piston would be, and also where the stoneblock pushed by the extended piston would be. I would guess invissible block 36.

This sugests that it is related to: MC-8132

More testing to be done...

Replicated again.
I have now added screenshots and also a world to replicate the problem.

Screenshot information:

• "setup" shows the setup that I used.

• "invissible_piston" shows one of the invissible block created by a pistonhead after the first time I tried it. Not marked but still there are all the other piston heads, and also invissible blocks instead of the stoneblocks seen in the "setup" picture. Note that the invissible blocks left by the stones are in front of the marked invissible pistonhead of the one marked pistonhead. (to the down left in the picture) So it seems to end in an extended stage.

• "faulty_pistonheads" shows what happend after another try I did with the same setup. I think the picture talks for itself.

laggtest.rar is the world download to replicate this yourself.

When entering there should be a sign telling you to teleport to 1000 1000. Do that. and read all the signs to replicate.

Edit: Used 1.7.10 to do this test.

I have now also reproduced this in snapshot 14w28b using the same setup.

In 14w28b the java application does not seem to stop responding, so I did not have to force a quit by killing the process in windows (as I had to do in 1.7.10).

Another thing that changed when using the snapshot (instead of 1.7.10) was that the pistons didnt break. They just kept on going as they did before. (This could be a coincidence though, since they bugged out slightly differently between the different test I did in 1.7.10)

However the problem still exists and can be reproduced in 14w28b.
You can see this on my two screenshots that I have put up using this version.

• "beforeunload" is a screenshot of my fps/chunk updates before stepping over the white line to the next chunk.

• "afterunload" is a screenshot of my fps/chunk updates after stepping over the white line to the next chunk.

As you can see there is a massive difference.

However as I have said before, this should be totally client side and if it happens on a server noone else will notice.

I also tested to change the render distance from 16 to 2 chunks, and the same thing occured, but now 2 chunks away instead of 16 chunks away.

So Kumasasa..
I posted like 7-8 posts, spent a lot of time testing this, confermed the issue in 1.7.10 and 14w28b, I reproduce the issue and post screenshots of the reproduction and the setup, I conferm that it is related to draw distance, I conferm that it affects both singleplayer and multiplayer and that noone else is affected in multiplayer if they are not in the same area, I conferm that its the drawdistance of the server that affects how far away it appears in multiplayer, I upload a map with ways to totally reproduce this and I ask for people to test it...
And....... All you do is update the version number affected when you see the posts?
Have you even read the rest?
You couldnt atleast test it yourself with the setup I posted and confirm/deny that it works the same on your computer?
Or ask me to do anything else that is lacking for the issue to be fixed? I mean I want this thing fixed, since it totally breaks the gameplay and I have put a lot of time in to testing it out.