Todd.Powers

I have the same problem.

If I go to global resources and add the texture pack manually, then configure it for 128x, it will load. However if I connect to my realm, where the texture pack is configured, without configuring the TP in global resources, the game crashes (black screen)

It seems the game is not accurately detecting the maximum resolution possible.

Also... Configuring the TP in global resources, does not get saved. I have to set that up every time I start the game up.

I have been experiencing this myself lately. In my case, sometimes Minecraft locks up, but more often, my XBOX One X simply shuts down. Full power off.

This only happens when playing Minecraft and I typically play on a realm.

Checking back in on this today. I haven't been playing Minecraft in quite a while, due to the fact that so many of my structures use this feature, making them unusable. Often, this was used in buildings with multiple floors and the material above the half block is the floor of the upper level (or even water in some cases) so it's not practical to raise the roof of all those structures.

Is there any intention to fix this and make it behave the same way all previous versions did? 

I was just checking back on this issue today and was disappointed to find that it was marked invalid. I realize this may have been considered a bug in previous versions, but changing this behavior causes many many compact redstone contraptions to now be invalid as well. I would have thought with the move to bedrock version, you would want to duplicate any and all functionality that was present in previous versions. Whether those features or functionality were actually bugs in the system, many many players, YouTubers, and Redstone fanatics had developed complex redstone contraptions based around this functionality. Not supporting this in the bed rock version means all of those documentaries and websites are now junk. The Minecraft community and all of its associated websites videos and documentation, is what made this game so successful in the first place. It's sad to know that many of those things will now be defunct.

Whether it was a feature or a bug, it's still something in the Bedrock version that does not behave the same way as it did in previous versions. This breaks functionality in older Maps. "Fixing" this "bug" for the sake of making things "more correct" is something that will make players like me not adopt the newer platform and simply go back to playing on previous versions.

Yeah... I didn't even realize this was a Bedrock version. I was kind of hoping one of the admins can move this over there. But I suspect I'll have to just submit it again.

After searching everywhere for the version number, I restarted the game and found it on the start page.

v1.2.13
(no build number referenced)

I'm not sure what category (version) this should be catalogued under. Someone with admin rights can move this into the proper group.

I just recently upgraded my laptop and I'm seeing this happen on a regular basis now.

The new laptop has SSD, so perhaps it's a caching/file handle issue? Not sure. I just know it's getting irritating...

Usually happens after being disconnected from a server that goes offline in an abrupt manor...

I realize that this is similar to other issues that have been submitted, but why is it listed as "resolved", when this is still happening? It's not even "intermittent" like most of the others report. It's constant. I can not connect no matter what.

Are you able to duplicate the issue using the server configuration that I have provided?

@Kumasasa
Yes. I did read the comment. Please don't treat me like a child. I'm a 45 year old Software Architect with plenty of experience designing user interfaces. I'm providing my feedback here to let you know that the labeling of the button in the Controls page is confusing to users.

The label for the button still contains the words "Push-To-Talk", when the setting under Broadcast settings is set to Push To:Mute. Even though it is followed by "/Mute", It is confusing to the end user, because the first reaction they get is that this is a PTT button. If the button action is configurable through the Broadcast settings, then the label in the Controls page should change to indicate the currently configured action. If the Broadcast settings are set to "Push To: Mute", then the label in the Controls should read, "Push To Mute". If the Broadcast settings are set to "Push To: Talk", then the label in the Controls should read, "Push To Talk".

Furthermore, the default configuration should probably be Push To: Talk, in the Broadcast settings. I would guess that a majority of users broadcasting their stream would rather not have their local audio broadcast by default..

This is actually an incorrect labeling.

it is labeled as "push to talk", when actually it is "push to mute". The labeling would be correct if the microphone was muted by default and only unmuted when this key was pressed. I don't see a setting anywhere to have the microphone muted by default, so this is obviously mislabeled.

...and for what it's worth, i would rather have the microphone muted by default and only active when the PTT switch is pressed.

I just spent some time today testing this. I had reduced the number of sheep in my sheep farm significantly to avoid this issue. Today, I went ahead and started breeding more sheep to see if I ran into the same issue again.

I went from 232 sheep, spread out over 8 chunks (29 Sheep per chunk), to 320 Sheep (40 Sheep per chunk), and the client did not crash.

I'm happy to report that you guys seem to have trapped the exception! YAY! Great job at finally tracking this down!

However... The client appears to "hang" now, instead of crash... This is obviously leaps and bounds above the prior behavior, but there might be more to examine here, to track down some performance issues, that may or may not permeate throughout other parts of the application as well...

I recorded a video that illustrates this and have posted it online here...

https://vimeo.com/70162147

password: SheepLag

You will notice 2 specific times when the sheep seem to lock up completely. During this time, other server related things, such as doors do not work either. However, as you will notice during one of the lockups, I was able to feed the sheep wheat, and hearts appeared, even though everything else was locked up.

Please let me know if there is anything I can do to help track this down and squash it once and for all...

The client doesn't crash. It simply quits. The only reason I have an exception to show is because I start java through a batch file, so I can specify a larger memory pool. Otherwise, it would just be the client exiting for no known reason.

...and I have all the latest updates for this laptop. There are no newer drivers available.

Additionally, I get this same error playing on other machines. The client machine does not seem to be the issue.

Here ya go...

---- Minecraft Crash Report ----
// I feel sad now :(

Time: 6/18/13 2:31 AM
Description: Manually triggered debug crash

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)


A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------

-- Affected level --
Details:
	Level name: MpServer
	All players: 1 total; [bdv['Wh1rledPeas'/173, l='MpServer', x=-19.65, y=10.12, z=-20.88]]
	Chunk stats: MultiplayerChunkCache: 441
	Level seed: 0
	Level generator: ID 01 - flat, ver 0. Features enabled: false
	Level generator options: 
	Level spawn location: World: (3,4,-29), Chunk: (at 3,0,3 in 0,-2; contains blocks 0,0,-32 to 15,255,-17), Region: (0,-1; contains chunks 0,-32 to 31,-1, blocks 0,0,-512 to 511,255,-1)
	Level time: 1656248 game time, 2697932 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: creative (ID 1). Hardcore: false. Cheats: false
	Forced entities: 77 total; [qj['Cow'/0, l='MpServer', x=-89.78, y=4.00, z=36.69], nf['entity.ItemFrame.name'/137, l='MpServer', x=-28.94, y=5.50, z=-40.50], qj['Cow'/1, l='MpServer', x=-66.88, y=4.00, z=6.06], nf['entity.ItemFrame.name'/136, l='MpServer', x=-28.94, y=5.50, z=-43.50], nf['entity.ItemFrame.name'/139, l='MpServer', x=-28.94, y=5.50, z=-34.50], nf['entity.ItemFrame.name'/138, l='MpServer', x=-28.94, y=5.50, z=-37.50], nf['entity.ItemFrame.name'/4, l='MpServer', x=-49.94, y=5.50, z=-34.50], nf['entity.ItemFrame.name'/141, l='MpServer', x=-17.06, y=5.50, z=-43.50], nf['entity.ItemFrame.name'/5, l='MpServer', x=-49.94, y=5.50, z=-37.50], nf['entity.ItemFrame.name'/140, l='MpServer', x=-17.06, y=5.50, z=-46.50], nf['entity.ItemFrame.name'/6, l='MpServer', x=-49.94, y=5.50, z=-40.50], nf['entity.ItemFrame.name'/143, l='MpServer', x=-17.06, y=5.50, z=-37.50], nf['entity.ItemFrame.name'/7, l='MpServer', x=-49.94, y=5.50, z=-43.50], nf['entity.ItemFrame.name'/142, l='MpServer', x=-17.06, y=5.50, z=-40.50], nf['entity.ItemFrame.name'/8, l='MpServer', x=-49.94, y=5.50, z=-46.50], nf['entity.ItemFrame.name'/129, l='MpServer', x=-20.94, y=5.50, z=-40.50], nf['entity.ItemFrame.name'/128, l='MpServer', x=-20.94, y=5.50, z=-37.50], nf['entity.ItemFrame.name'/9, l='MpServer', x=-49.94, y=5.50, z=-25.50], nf['entity.ItemFrame.name'/131, l='MpServer', x=-25.06, y=5.50, z=-34.50], nf['entity.ItemFrame.name'/10, l='MpServer', x=-49.94, y=5.50, z=-28.50], nf['entity.ItemFrame.name'/130, l='MpServer', x=-20.94, y=5.50, z=-43.50], nf['entity.ItemFrame.name'/11, l='MpServer', x=-49.94, y=5.50, z=-31.50], nf['entity.ItemFrame.name'/12, l='MpServer', x=-47.06, y=5.50, z=-46.50], nf['entity.ItemFrame.name'/133, l='MpServer', x=-25.06, y=5.50, z=-40.50], nf['entity.ItemFrame.name'/13, l='MpServer', x=-47.06, y=5.50, z=-43.50], nf['entity.ItemFrame.name'/132, l='MpServer', x=-25.06, y=5.50, z=-37.50], nf['entity.ItemFrame.name'/14, l='MpServer', x=-47.06, y=5.50, z=-40.50], nf['entity.ItemFrame.name'/135, l='MpServer', x=-28.94, y=5.50, z=-46.50], nf['entity.ItemFrame.name'/15, l='MpServer', x=-47.06, y=5.50, z=-37.50], nf['entity.ItemFrame.name'/134, l='MpServer', x=-25.06, y=5.50, z=-43.50], nf['entity.ItemFrame.name'/17, l='MpServer', x=-47.06, y=5.50, z=-31.50], qo['Sheep'/152, l='MpServer', x=-15.06, y=4.00, z=-43.88], nf['entity.ItemFrame.name'/16, l='MpServer', x=-47.06, y=5.50, z=-34.50], qo['Sheep'/153, l='MpServer', x=-14.88, y=4.00, z=-31.84], nf['entity.ItemFrame.name'/19, l='MpServer', x=-47.06, y=5.50, z=-25.50], nf['entity.ItemFrame.name'/18, l='MpServer', x=-47.06, y=5.50, z=-28.50], qj['Cow'/21, l='MpServer', x=-34.16, y=4.00, z=32.81], qj['Cow'/20, l='MpServer', x=-36.94, y=4.00, z=28.06], nf['entity.ItemFrame.name'/144, l='MpServer', x=-17.06, y=5.50, z=-34.50], qo['Sheep'/145, l='MpServer', x=-31.19, y=4.00, z=-31.91], nf['entity.ItemFrame.name'/146, l='MpServer', x=-28.94, y=5.50, z=-31.50], nf['entity.ItemFrame.name'/147, l='MpServer', x=-17.06, y=5.50, z=-31.50], qo['Sheep'/148, l='MpServer', x=-14.97, y=4.00, z=-47.16], qo['Sheep'/149, l='MpServer', x=-14.84, y=4.00, z=-40.84], qo['Sheep'/150, l='MpServer', x=-15.09, y=4.00, z=-37.84], qo['Sheep'/151, l='MpServer', x=-14.84, y=4.00, z=-35.03], qg['Bat'/161, l='MpServer', x=42.65, y=16.00, z=-40.31], qg['Bat'/4469, l='MpServer', x=40.75, y=6.10, z=-39.75], qg['Bat'/4470, l='MpServer', x=38.47, y=5.10, z=-43.75], qo['Sheep'/94, l='MpServer', x=-26.50, y=4.00, z=-100.59], qo['Sheep'/98, l='MpServer', x=-31.25, y=4.00, z=-97.16], qo['Sheep'/99, l='MpServer', x=-23.88, y=4.00, z=-100.81], qo['Sheep'/96, l='MpServer', x=-20.81, y=4.00, z=-96.84], qo['Sheep'/97, l='MpServer', x=-31.53, y=4.00, z=-100.88], qo['Sheep'/110, l='MpServer', x=-28.78, y=4.00, z=-83.19], qo['Sheep'/111, l='MpServer', x=-21.22, y=4.00, z=-86.38], qo['Sheep'/108, l='MpServer', x=-16.56, y=4.00, z=-85.72], qo['Sheep'/109, l='MpServer', x=-26.34, y=4.00, z=-83.88], qo['Sheep'/106, l='MpServer', x=-29.09, y=4.00, z=-86.03], qo['Sheep'/107, l='MpServer', x=-20.16, y=4.00, z=-81.09], qo['Sheep'/119, l='MpServer', x=-31.13, y=4.00, z=-40.84], qo['Sheep'/118, l='MpServer', x=-31.16, y=4.00, z=-34.94], qo['Sheep'/117, l='MpServer', x=-26.78, y=4.00, z=-92.56], qo['Sheep'/116, l='MpServer', x=-31.16, y=4.00, z=-88.94], qo['Sheep'/115, l='MpServer', x=-17.25, y=4.00, z=-90.38], qo['Sheep'/114, l='MpServer', x=-30.19, y=4.00, z=-92.16], qo['Sheep'/113, l='MpServer', x=-26.94, y=4.00, z=-91.06], qo['Sheep'/112, l='MpServer', x=-16.50, y=4.00, z=-93.72], nf['entity.ItemFrame.name'/127, l='MpServer', x=-20.94, y=5.50, z=-34.50], qo['Sheep'/126, l='MpServer', x=-23.03, y=4.00, z=-35.06], bdv['Wh1rledPeas'/173, l='MpServer', x=-19.65, y=10.12, z=-20.88], qo['Sheep'/125, l='MpServer', x=-23.16, y=4.00, z=-38.06], qo['Sheep'/124, l='MpServer', x=-22.97, y=4.00, z=-41.03], qo['Sheep'/123, l='MpServer', x=-23.09, y=4.00, z=-44.16], qo['Sheep'/122, l='MpServer', x=-30.81, y=4.00, z=-37.91], qo['Sheep'/121, l='MpServer', x=-31.13, y=4.00, z=-47.03], qo['Sheep'/120, l='MpServer', x=-31.09, y=4.00, z=-44.16]]
	Retry entities: 0 total; []
Stacktrace:
	at bds.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.2
	Operating System: Windows 7 (amd64) version 6.1
	Java Version: 1.7.0_21, Oracle Corporation
	Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
	Memory: 1635956256 bytes (1560 MB) / 2034302976 bytes (1940 MB) up to 2034302976 bytes (1940 MB)
	JVM Flags: 2 total; -Xmx2048M -Xms2048M
	AABB Pool Size: 19331 (1082536 bytes; 1 MB) allocated, 2 (112 bytes; 0 MB) used
	Suspicious classes: No suspicious classes found.
	IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
	LWJGL: 2.4.2
	OpenGL: Intel(R) HD Graphics Family GL version 3.1.0 - Build 8.15.10.2430, Intel
	Is Modded: Probably not. Jar signature remains and client brand is untouched.
	Type: Client (map_client.txt)
	Texture Pack: Default
	Profiler Position: N/A (disabled)
	Vec3 Pool Size: 732 (40992 bytes; 0 MB) allocated, 14 (784 bytes; 0 MB) used

Again... I do not run K9, so this recent comment, has absolutely nothing to do with this issue that I have documented here.

I think you will see, as I noted in MY issue that I opened here...

https://mojang.atlassian.net/browse/MC-15730

...that the problem seems to be agrivated by excessive levels of mobs in loaded chunks. In my case, I almost always see this problem, when I am in areas that contain a lot of mobs. Now... Does that mean that my router is dropping packets because it's saturated? Does my internet provider have an issue with the excessive amount of "mob tracking" going on? Is my network card in my PC having issues?

I have no idea.

I know that, back in the day, we had issues with Windows servers when they attempted to initiate more than 15 simultaneous outbound connections. We spent 6+ months with Microsoft, tracking this problem down on an enterprise class (Fortune 100) company's web site server cluster. Turned out to be a limitation in the Kernal code for Windows. (0-15 slots max)

Could we be running into something similar in someone's network stack, or a hardware limitation somewhere?

I think, if you can find a way to duplicate it (check my issue referenced above), the key would be able to reliably cause the issue to happen, on demand, then come up with a way to handle the situation gracefully from within the Minecraft client, so as to prevent sporadic disconnects.

The only security related software I was running was AVAST Anti-Virus, and I disabled that in order to rule it out as a culprit. I still received the same error.

This issue may be caused by an interruption in network traffic, through some software, and/or hardware, but the fact remains... The exception needs to be trapped and handled gracefully, so the Minecraft client can resume communications with the server, rather than exiting abruptly, requiring the user to reconnect to the server.

Funny... I am experiencing a similar issue, and I do not run K9, or any such application. This other user's experience may include K9 doing something that is causing the error, but the plain and simple fact is, that the Minecraft client crashes because it does not handle this exception properly.

Things other than K9, evidently cause this problem. You simply need to trap the exception and handle it gracefully.

This is NOT a duplicate. The other issue that is posted regarding this, references K9 as a conflicting application. I do not run K9, nor anything of the sort.

This is an issue with the Minecraft Client crashing due to an improperly handled exception.

This is a 1.5.2 World Save from Single Player, with a sheep farm, that, when built on a server in SMP, causes these exceptions to occur fairly regularly.

Further notes: This problem appears to be related to mobs. I notice it most when attempting to breed sheep.

I created a grid of 16 pens to hold sheep. I laid the pens out so that every other pen began on a new chunk line (block 0), and ran the full length of a chunk in the other direction. (7x15 to account for walls) Spanning 8 chunks. (to ensure that the sheep/chunk was consistent)

I put 2 sheep in each pen and bred them consecutively with the following numbers of resulting sheep (3, 4, 6, 9) and the resulting numbers of baby sheep occurring during the breeding process (1, 1, 2, 3)

Given the fact that this process was occurring on the factor of 16 (each color), the total numbers for the 8 chunks is as follows:

Breeding phase 1: 16 Sheep, 8 Babies
Breeding phase 2: 24 Sheep, 8 Babies
Breeding phase 3: 32 Sheep, 16 Babies
Breeding phase 4: 48 Sheep, 24 Babies

At phase 4, the error starts occurring, and upon reconnecting, some of the new baby sheep were lost.

Given the fact that the sheep mobs have nothing to do with the http get to the version update flag, I can only assume that it has to do with memory and/or thread issues relating to mobs, or the sheer amount of network traffic generated to the server to track the mobs. Either the "mature to adult" event, the "eating" event, the baby mob sound, collision detection, something...

It seems to me that something is leaving a socket, thread, or memory in a bad state, which adversely affects the http get version check process.

I assume this because if I only breed 2 sheep of each color on each phase (instead of all available), and never get above 16 Babies at a time, I can continue to breed sheep on up to about 11 sheep per pen. After all sheep mature, I am safe to breed another sheep of each color. I have not moved past 11 sheep of each color (176 Sheep in 8 chunks)

However, whenever I am within range of those chunks so that they are loaded, I do run a risk of getting the socket error. It happens from time to time. Babies or no babies...

I hope this information is useful in tracking down this very annoying issue. From what I have heard in the community, this problem affects a large base of users, and many people are getting rather frustrated with the situation. If you need anything specific from me, please don't hesitate to ask.

NOTE: I tried this in a single-player world, and the problem did not occur. I will attach a Zip of that world, so you can have an example of the sheep farm I am experiencing this issue with.