![[Mojang] Tomas Alaeus](../../../data/avatars/users/10122.svg)
[Mojang] Tomas Alaeus
- talaeus
- talaeus
- Europe/Stockholm
- Yes
- No
When i was working on my note block song (slowest setting, 3 minecraft ticks.), i pressed the button to chevk my progress. And then, at one point in the song, the redstone repeaters bugged out on me and went on the fastest speed. (1 minecraft tick) and when i checked on the setting of the redstone repeaters at the point where it went bugged out, it was on the slowest (3 ticks), setting. When i pressed the button again, it still went fast. Do you know why it's doing this? (The system is Amazon's newest kindle, Fire 5th generation)
Update by [Mojang] Adrian Östergård
This bug has been reported to our internal bug tracker for further testing and a fix. It is scheduled to be fixed in one of the future updates (no specific date can be provided).
Please avoid duplicate comments. Post only NEW information regarding this bug.Update by [Mojang] Tomas Alaeus
Repeaters don't apply the delay properly in all cases. If the repeater was activated by another pure redstone component being ticked, then the delay will be correct. However, if it was activated by a world change (lever, piston modifying a circuit, pressure plates, buttons, etc) then the repeater will output a signal 1 tick too fast. A 1-delay repeater will act as a 0-delay repeater (that is, completely ignored). A 3-delay repeater will act as a 2-delay repeater.
duplicates
REALMS-622is duplicated by
duplicates
duplicates
duplicates
duplicates
is duplicated by
duplicates
duplicates
duplicates
duplicates
is duplicated by
duplicates
duplicates
is duplicated by
[Mojang] Tomas Alaeus
BDS-59 → 
MCPE-37615When enabling AirPlay on OSX, any open instance of MC:EE will crash and attempt to reopen.
When enabling AirPlay on OSX, any open instance of MC:EE will crash and attempt to reopen.
duplicates
is duplicated by
[Mojang] Tomas AlaeusWhat I expected to happen was...
On flicking the power switch in each example, the blue example shown would fire like the red example shown (end repeater lights up).
What actually happened was...
In the blue example, the output repeater doesn't fire. If you rapidly flick the switch back and forth, the blue repeater fires intermittently.
Steps to reproduce:
- Drive redstone current into a block on top of a piston to generate a 1-tick pulse (red example). Position a repeater to pick up the current from the piston block, but the redstone should flow directly from power source to the block.
- Turn on the power source; the piston will fire and the output repeater will light up for its pulse duration.
- Insert a repeater anywhere along the input line and toggle the power source. the output repeater will not fire.
- Rapidly toggle the power source (switch works best). The repeater will occasionally fire.
- replacing the relay with redstone torch inverters shows the same issue (the mechanism will fire when the torch is placed, but not when the mechanism is toggled).
- Using an observer block as the power source showed the same issue.
Minecraft pocket edition 0.15.0 (iOS - replicated on iPhone 6 and iPad air 2)
Update by [Mojang] Adrian Östergård
This bug has been reported to our internal bug tracker for further testing and a fix. It is scheduled to be fixed in one of the future updates (no specific date can be provided).
Please avoid duplicate comments. Post only NEW information regarding this bug.
Update by [Mojang] Tomas Alaeus, explaining the cause of the bug
Repeaters don't apply the delay properly in all cases. If the repeater was activated by another pure redstone component being ticked, then the delay will be correct. However, if it was activated by a world change (lever, piston modifying a circuit, pressure plates, buttons, etc) then the repeater will output a signal 1 tick too fast. A 1-delay repeater will act as a 0-delay repeater (that is, completely ignored). A 3-delay repeater will act as a 2-delay repeater.
Re-opening, as this was incorrectly closed as a dupe of MCPE-13983, which was a separate bug which has now been fixed. I have copied over the information provided by [Mojang] Tomas Alaeus relating to this bug and added it to the description. Also revised the report title and attached the relevant screenshots from MCPE-17208 & MCPE-17274.
Resolving as fixed, as this was accidentally confused with MCPE-15793, which was a separate bug. I have copied over the information provided by [Mojang] Tomas Alaeus relating to MCPE-15793 and added it to the description of that bug. I have reverted the changes to this report, to bring it back to its state prior the change, and as I am unable to reproduce this bug after extensive testing, I am closing it as fixed as of 1.0.2. (I think it was probably fixed back in 0.16, though I don't know for sure.)
PSA: This bug fix will most likely not make it into 1.0.5, unfortunately. [Mojang] Tomas Alaeus has run into some shader problems that he needs to refix, so this bug will probably not be fixed until either the next minor update (1.0.6, if another minor update comes before 1.1) or the next major update (1.1). Sorry for any disappointment. 
At least the bugfix is actively being worked on, and is getting very close to being done now! 
Nick, does it feel like the device is sluggish/slow when this happens? Try switching to/from the game with the home/multitask buttons and see if it reacts fast or not.
That could mean that the game is stuck in an infinite loop. Thanks.
Confirmed a bug.
Azelef: There you go.
Bah, non-believer! I pushed a fix for it ~4 hours after the comment.
Previously we had some code in place that tried to optimize this so it didn't have to recheck all the time, but that was apparently a bit broken (it's hard to do without cluttering down everything). The fix was just to remove that optimization. Now if a piston got power, it will check the push conditions every tick (redstone tick) regardless if it could do it before or not. It will require more performance on the host/server, but that's something we have to live with until we can provide an optimization that's bug free.
Randomness: This fix had nothing to do with randomess. However, pistons (and all other ticking block entities like hoppers) do depend on their ticking order (if two pistons push the same block from different angles in the exact same tick, only the first ticked will activate). In 0.15.2 this order was undefined*, while now it's randomized every tick. We've had many discussions here around how to make the order stable and dependable, but we haven't got to any conclusion yet. In the meantime, it's random so no one can depend on any order.
*) Undefined order
In technical terms all block entities are stored in a non-ordered hashmap per chunk. When playing and no block entities are placed, the order would be stable (meaning it's the same order every tick). However, when placing new block entities in the same chunk the hashmap sometimes needs to grow when it's getting full (this depends on the platform, in the development platform it grows when it reaches 64 block entities). When it grows all entries in it will be shuffled, and thus the order will change.
They were generally ticked in the same order that they were placed (up until the hashmap had to grow). This meant that users could start to depend on it, and then get frustrated when the order suddenly changed if they placed too many in the same chunk. With the added randomness in the ticking order, users have to make machines that work with any ticking order (delay one of the pistons with 1 tick). Those machines will not break regardless of the amount of block entities added, and they will not break if we later figure out a way to order them properly.
The randomness isn't a bug in itself. If two pistons are activated during the same tick, then it is completely random which one will actually be activated first. You need to make sure one of them are activated a whole tick before the others for it to be non-random.
On the other hand, the repeaters seem to be buggy.
To explain what's going on:
If you activate a repeater with an in-world change (pulling a lever, pushing a button, placing a redstone block, a piston pushed/pulls something which causes the redstone system to change) then the repeater will activate with 1 tick less delay than it should. A 1 tick delay repeater would activate immediately just as if it was redstone dust.
We do read the comments here and all the logs. Sadly we have trouble reproducing the issue, and in this case the crash logs doesn't reveal what the real cause is. At this point there are probably even multiple causes for this issue. Every now and then we push a fix for a blackscreen issue, but it's incredibly hard to know if it's the one that causes this or not...
We're believing that this issue is sometimes caused by a very long startup time. For those that experience this (blackscreen when starting, no crash), try to let the device run for at least an hour and see what happens.
Just to answer your reports. We have found the major cause for this increase in startup time, and it's fixed in the next release/beta release. But I don't think it will fix the issue for everyone unfortunately...
We don't know what exactly is incorrect and in what way it is incorrect. PHO, in the last image you posted, you will get another result if you put a repeater between the lever and the rest of the machine.
(yes, that is another bug which I think is already reported) However, it looks to me that it's the dispenser that's too slow...
I looked into this, and you're partially right and wrong.
Just as SuperGeniusZeb said it is correct, intended and designed for you to come back to the same portal you walked into. This is because when you changed dimension the chunk stopped ticking. When you go back the machine will continue ticking and thus disable the portal.
However, the bug that you mentioned in the previous comment did interest me so I tested this (thanks for the attached map!). Some redstone components (in this case it seems to be affecting the pressure plates) isn't serialized correctly. When you get back to the chunk the pressure plates might be locked in a "pressed" state. You have to rebuild them to get it working again. I'm working on a fix for this right now.
Even though the pressure plates and various other things are broken, the bug that you describe in the bug description is actually working as intended.
The blocks that should get fixed by my fix are: Pressure plate, tripwire, redstone lamp, detector rail and buttons.
While it looks like the same bug, this is actually at least two bugs squashed into a single ticket.
I have just made a fix that fixes: Pressure plate, tripwire, redstone lamp, detector rail, buttons and probably dispensers and droppers as well. What separates these from some others in this ticket is that these would not get fixed by reloading the world. In fact, what was causing this issue was the actual saving of the world. Reloading wouldn't fix it since the saved state is broken.
Pistons however is a completely different chapter.
Yes, I noticed that. My fix could also fix that issue with dispensers and droppers. I didn't do extensive testing on those to see that this was the actual problem in your machine, but they did have the same problems as pressure plates.
That is indeed a problem depending on what you want to do, but it's not a bug. We have for a very long time discussed how we want redstone to work in regards of unloaded chunks, but so far we haven't come to a conclusion. Having all redstone machines keep chunks loaded could result in performance degradation. In your scenario there are many things one needs to choose: How many chunks should be kept loaded? For how long? Should only redstone tick or should everything else as well (fire spreading, water flowing, mobs running around attacking, etc)? Some might use a portal as a "safe room" from when shit hits the fan, if we keep ticking their chunks it might ruin their worlds... Maybe that's a bit far fetched, but it could happen.
I finally found and fixed the issue. It will be available soon (tm).
Yes, we know this.
You could make the off-switch in the nether instead of in the overworld.
Added a more detailed description of the actual bug.
It should be fixed in the next release, sorry for the delay.
Hilarious bug.
Should be fixed in the next version.
Should be fixed in the "next" version.
I didn't fully understand the issue. Are you sending a FullChunk packet (id 58), but the client doesn't rebuild previously empty subchunks?
(for what it matters, I consider this a real bug in the client, because we do want to support third-party servers doing stuff like that)
No, but probably later.
edit: If there is a bug that is. I still haven't tried to reproduce it. I haven't heard that this is an actual problem from other server developers.
Ah, now I understand the issue better.
Right now it could be considered a third party bug. But we do want third party servers to exist, and the packet is supposed to (at the moment) replace an entire chunk. This bug causes a chunk to not be replaced completely in some cases.
If you want to clear all chunks you could just teleport the player somewhere else and send new chunks as usual.
I've seen that page. Unfortunately it doesn't really help. I'm currently battling our build system/compilers to get them to build the game without NEON instructions. Depending on how the game performs after that there will be some different routes that we can take.
Yay, it starts now. There were some other issues with shaders (which might fix the startup issue for others that have NEON devices) that I had to fix as well. I need to tweak it, clean it up and measure the performance hit as well.
Details: It's actually not just NEON instructions that make the Xoom (Tegra 2) different from others. It's also that it doesn't support VFPv3 which is another optional instruction set available on ARMv7 processors. For the Android target which Google calls "armeabi-v7a" they only require Thumb2 and VFPv3-D16 (not VFPv3). Disabling NEON was therefore not enough, we also need to turn it down to VFPv3-D16.
In short: I think I have successfully built the game with only VFPv3-D16 (instead of VFPv3 and NEON) and it does seem to work on the Xoom that we have here. It also doesn't seem to affect performance negatively in any measurable way. Yay \o/.
Ok, I think I managed to solve the issue now. I don't know why the device had problems compiling the shader code, what caused it or which part of the shader compilation that failed (Motorola building the device, Nvidia building the chipset, X for making the compiler, Khronos group for defining GLSL). But I do know that if I have to continue investigate this issue then I will lose brain cells.
Soren Hannibal: Well, if Android force closes the app because it doesn't respond within 10 seconds, then it is our fault for not making it respond fast enough. There is no reason why the app shouldn't respond in time, thus it's a valid bug that we definitely can fix.
Sorry for not updating this ticket more, we've reached out here and there about what's going on with this issue but forgot this place.
Unfortunately the fix that was implemented for 1.1 didn't fix the issue, and the fix that got added in 1.2 made it even worse (which is why 1.2 was never released for Apple TV). There is no date on when there is a fix coming, but we have people working on rewriting the entire iCloud implementation to get it right.
We did screw up and we're really sorry for the inconvenience this has caused you. I will be watching this ticket and keep it updated with our progress and answering any questions you have.
I'm really sorry that no one have responded here. Just to let you know I have found the issue and a fix for it should come in the next release. The issue was with the throttling of sending chunks, so it just filled the sending queue with all visible chunks (even the ones very far away). That sadly ruined the packet prioritization...
There's a fix coming in the next release that hopefully will solve the issue you're seeing.
What type of internet do you have and how fast is it? Do you notice the latency issues at all times or is it only in specific Realms or areas when it happens?
Could you tell us the name of the Realm? That would help us investigate what the problem could be.
Could you tell us the name of the Realm? That would help us investigate what the problem could be.
Do you have a blueprint (or description) of the blaze farm that crashes the server, if it's a special kind of farm.
Does this still happen in 1.2? We will look into it more in detail either way.
Do you mind telling me the Realm name for the affected Realms? That can help us investigating the issue.
Do the chest minecarts disappear (as in you have to recreate them) or do they just get stuck somewhere?
This has been fixed for a while now.
I just noticed that this bug have been fixed for a while. Thanks anyway.
Do you still have problem with this? If so: Was the map initially created with split screen play?
Do you still have problems with this? Hopefully a fix for the issue have already been released since you reported it.
This is what happens when the server crashes. Due to this bug ticket being very old it's most likely to be very many different bugs, and having such a generic ticket doesn't help much.
So, I'll close this. Anyone objecting to it then we can reopen it.
I'm closing it as fixed because you said the issue disappeared. If you still have problems with it we can reopen it.
We have now successfully reproduced the issue.
Thanks a lot for the report, and sorry for the very late replies.
It's virtual servers. It probably doesn't have anything to do with the disks. But yes, something in our code is probably stopping the game from saving.
We're investigating it at the moment.
Sebastian We have uploaded a fixed version of your Realm. Hopefully it works for you now.
ConnorSImp We're going to upload a fixed version of your Realm soon.
We're working on adding compensation days to your Realms, hang on.
While your Realm experienced similar issues as the other (
REALMS-945) it wasn't as easy to repair it. We're still working on it though.Adrian Birch: Repair means just that. We don't know what causes the corruption, but we have some ideas on how to make it try to autorepair if a corruption occurs.
ConnorSImp: We've had a long weekend which is why nothing have happened the last few days.
We haven't found a solution for this yet. We're partly working on it at the same time as we're fixing some bigger issues with how players are saved.
ConnorSImp: The fixed world should have been uploaded now, and some days should have been added to it. I hope it works for you now.
Good news: We have a potential fix for this issue. The world have been slightly corrupted but we've found a way that might work.
Sad news: The fix is risky and will probably not have enough time to be tested for the upcoming release. That means that it won't be release until later (probably June).
We see no need to implement such a feature. The server automatically saves all data to disk when needed. If you explicitly want to force a save you could use the backup commands "/save hold" and "/save resume".
We don't support this scenario. Lifeboat and other third party servers handles this in other ways.
Ross Edgin: Having two different ports works without problem. The bug here is only about what is printed to the console. When reading the console you should ignore the second printout.
Acknowledged.
The gamemode setting in server.properties is currently only used for the default gamemode when the world is created the first time. We'll change this in some way.
The old files will get cleaned up eventually when leveldb figures out that it can remove them. Are you saying that the extra size isn't reduced automatically after a while?
That sounds like the `save resume` command wasn't executed properly. Does the server respond with an error to the resume command? Does the second hold command succeed?
If that's the case then I don't understand what's going on... When the world has grown really large, try to restart the server. That usually makes leveldb do a garbage collection and clean up it's files (more or less what your Universal Minecraft Editor does).
Could it be your script that's holding on to some file locks even after the backup is finished?
What does the db folder contain? Is it lots of log-files along with the ldb files? That's how it should look if the backup command is permanent on, because leveldb is told not to delete any files. Maybe the log files are only kept from the time where the backup is active?
We found the cause of this and a fix will be available for the next update.
The bug isn't on the radar anymore because the bug was fixed (the one we successfully reproduced at least). The cause is very messy though and I'm not surprised there are still issues left with it, or new issues that appear afterwards.
I'll reopen the bug on the internal tracker.
Thanks for reporting this to us and we're really sorry about it happening. We are working on a fix for it right now.
Trevor Martin: It is closely related to that other ticket in regards of the impact (lost progress), but the root cause is vastly different. We are working hard on solving both of these issues, but as far as I understand we do know what's causing this bug but not what's causing
MCD-1205yet (keep bug reports coming, they are very useful!).Thanks for reporting the issue to us (we do listen and read these tickets!). All the different stories you provide helps us nailing down the root cause of it, so please keep the reports coming.
Unfortunately I can't give any more information about when a solution will be published, sorry.
edit: To clarify, we are working hard on solving this.
A patch is released on PS4 and Switch today that solves a big majority of the crashes. PC and Xbox will get their patch soon as well.
Save data loss due to crashing has also been fixed on PC and Xbox. Switch isn't affected by the data loss as far as I'm aware, but PS4 players will likely still experience it (although a lot less often because many crashes have been fixed).
We may have prioritized the PS4 issue too low, and thus focused our efforts elsewhere. We are currently both reevaluating the priority and looking into solving the issue.
Trevor Martin Catia Canelas Cassandra Hawkins
It feels like this isn't happening at all for most people, but often for some. Maybe all who experiences it have something in common. Could you answer some questions about your setups?
Thanks for the info!
It's possible that the data loss happens when the game crashes during a save. The crash itself could be completely unrelated to the data loss. If this is the case then us fixing any of the crash bugs will lower the chance of data loss, even though it doesn't fix the data loss bug directly. However, if this would be the case then the data loss would happen more evenly throughout the player base, and it would be a very low chance of it happening multiple times (just by skimming how many players are affected by it).
But it seems this affects players very unevenly and we don't know why. That's why I asked the previous question to see if you have anything in common which makes you more prone to this.
Using "Report Problem" helps us a lot. Mostly for the exact problem causing the crash though. Data loss is tricker.