Idle shutdown freezing - investigation thread

[Brett_val]

After Zaffo found that iago1460's event-test tool contradicts my findings, I have to reject my conclusion and change this thread into an investigation thread.

"Findings" section - contains information that is found to be working.
"Testings" section - contains current investigations and questions.

Findings at idle shutdown

1
Code without control.isButton() freezes.

screen.fillrect(0,0,400,240,color.new(0,0,0))
text.color(color.new(255,255,255))
ts=16
text.size(ts)

while true do 
	screen.fillrect(100,100,200,20,color.new(0,0,0))
	text.draw(100,100,tostring(os.date()))
	screen.update()
	if control.read()==1 then
		if control.isTouch()==1 then
			if touch.click()==1 then
				break
			end
		end
	else
	os.wait(50)
	end

end

2
Code with button.click()==1 then break closes properly on idle shutdown.

screen.fillrect(0,0,400,240,color.new(0,0,0))
text.color(color.new(255,255,255))
ts=16
text.size(ts)

while true do 
	screen.fillrect(100,100,200,20,color.new(0,0,0))
	text.draw(100,100,tostring(os.date()))
	screen.update()
	if control.read()==1 then
		if control.isButton()==1 then
			if button.click()==1 then
				break
			end
		end
	else
	os.wait(50)
	end

end

3
When button.click results in another loop, app is also closed properly.
(see post #5)

4
iago1460's Tool does shut down properly without having a break under if button.click()==1.
I played around with this information under Testings.

Testings

After putting an os.wait(500) in the loop, iago1460's tool allowed me to read the event on the screen when the player does idle shutdown:

button event:0:[home]:[click]

My interpretation of this is that the app received button.click, without button.up or button.down, because the count was still 0 (= first event)
After that the app closes properly. While a button.click does nothing to this app besides text.drawing the event that has happened, somehow the app did close.

Thoughts:
1 perhaps a control.isButton() is needed (long shot.. just to rule this out)
2 perhaps the player also breaks the active loop.
3 perhaps the player unloads the app as a whole, but somehow couldn't do this without freezing at the other scripts.

thought 1:
testscript Findings 1 now contains a useless button.click:

screen.fillrect(0,0,400,240,color.new(0,0,0))
text.color(color.new(255,255,255))
ts=16
text.size(ts)

while true do 
	screen.fillrect(100,100,200,20,color.new(0,0,0))
	text.draw(100,100,tostring(os.date()))
	screen.update()
	if control.read()==1 then
		if control.isTouch()==1 then
			if touch.click()==1 then
				break
			end
		elseif control.isButton()==1 then
			if button.click()==1 then
				text.draw(0,0,"buttonclick")
				screen.update()
			end
		end
	else
	os.wait(50)
	end

end

Result:
"buttonclick" shows on screen
doesn't go back to app menu
player freezes.

I think I can rule out thought 1.
New thoughts:
1 else os.wait() causes problems

To resemble the event-test tool, test script from findings 1 now contains control.read(1)==1, and therefore I can remove the else os.wait(50)

screen.fillrect(0,0,400,240,color.new(0,0,0))
text.color(color.new(255,255,255))
ts=16
text.size(ts)

while true do 
	screen.fillrect(100,100,200,20,color.new(0,0,0))
	text.draw(100,100,tostring(os.date()))
	screen.update()
	if control.read(1)==1 then
		if control.isTouch()==1 then
			if touch.click()==1 then
				break
			end
		end
	end
end

Result:
Doesn't go back to app menu.
Player shuts down properly.


Black Jack:
added: control.read(1)==1

while (1) do
	for i = 0, 10 do
		if (control.read(1)==1) then
			if (control.isTouch()==1) then
				x,y = touch.pos()
				if (touch.click() == 1) then
					checkClick(x,y)
				elseif(touch.move() == 1) then
					checkMove(x,y)
				end
			elseif (control.isButton()==1) then
				if button.click() == 1 then
					ask = true	--Activate settings screen
					prompt = "Quit?"	--Set prompt message
					if (sound == true) then	--If not muted
						press:play()	--Play button sound
					end
				elseif (button.hold() ==1) then
					volume = true	--activate volume menu
					if (sound == true) then	--If not muted
						press:play()	--Play button sound
					end
				end
			end
		end
	end
	if (quit == true) then
		os.wait(500)
		break
	end
	drawScreen()
	os.sleep(1)
end

Result:
(I cripped the game doing this, it now only responds after a few clicks, and then it has skipped a few steps. I'm not sure why actually.. it seems like control.read(1) forces the loop to wait until there is an input?)

"Quit?" prompt didn't appear
doesn't go back to app menu
player shuts down properly

Thoughts:

1 perhaps the absence of os.wait allowed the player to shut down properly?

Conclusions

-idle shutdown sends a buttonclick to the app
-


Solutions

1 (more of a workaround)
Code to shutdown the app after 4 minutes (to prevent the app from having to idle shutdown and cause problems)

starttime=os.time()
while true do 
	if control.read()==1 then
		starttime=os.time()
	else
		if os.time()-starttime>240 then --checks is it was more than 240 seconds ago since the last control.read input.
			break 
		end
	end
end

But if you're using the accelerometer, then control.read() will always be 1 so then you'd have to put these lines under if control.isTouch()==1 else

Notes

Hopefully this will get sorted out so I can post something that will work in any case.

[CrowdAds]

[Habhome]

I noticed this on my Black Jack app too when testing it, but I didn't connect the dots. Problem is that I'd still like to keep my confirmation screen.

One thing also, when playing sudoku it returns to the menu if you're in a game, so wouldn't that freeze too if you leave it in a game?
EDIT1: Could it be so that it sends a few button clicks, not just one? In that case I could solve it for my app at least. I would suspect this is the case if Sudoku doesn't freeze.

EDIT2: Another idea struck me. What if the thing which is causing the freezing is that it keeps sending button.click() commands until the application closes? And since it never does the player hangs in an eternal loop. Sounds plausible and could easily be tested too.

It'd be good if we could get some other kind of signal for it which is separate from any other so we can program an "In case of idle shut down" function.

[Brett_val]

Originally Posted by Habhome

I noticed this on my Black Jack app too when testing it, but I didn't connect the dots. Problem is that I'd still like to keep my confirmation screen.

I added a solution to the first post, because yeah I also want to keep using the homebutton to go back to the main menu in ZenDuck.

Originally Posted by Habhome

One thing also, when playing sudoku it returns to the menu if you're in a game, so wouldn't that freeze too if you leave it in a game?
EDIT1: Could it be so that it sends a few button clicks, not just one? In that case I could solve it for my app at least. I would suspect this is the case if Sudoku doesn't freeze.

If it sends a few buttonclicks, then the player would return to the home menu instead of just the apllication menu. I noticed this when I didn't do

if button.click()==1 then break end

but just:

if control.isButton()==1 then break end

then the button.click was still in the queue and after breaking the app, the player would receive the button.click and it went back to the home menu.

But sudoku doesn't go back to the main menu at my player..? I just tried it; started a game, typed some numbers, then homebutton - exits the app.
I'll update my firmware to 1.20.08, maybe the change is there..

Originally Posted by Habhome

EDIT2: Another idea struck me. What if the thing which is causing the freezing is that it keeps sending button.click() commands until the application closes? And since it never does the player hangs in an eternal loop. Sounds plausible and could easily be tested too.

Good thinking! I'll write a test script and post back. But I suspect that it isn't the case, because:

Originally Posted by Habhome

It'd be good if we could get some other kind of signal for it which is separate from any other so we can program an "In case of idle shut down" function.

Well you can't do too much when it wants to idle shutdown. I noticed that the saving of the highscore I do at the end of ZenDuck already is too much.. (even when I deleted the closing animation I have at the end).

[Habhome]

Maybe sudoku doesn't, I thought it did though. (didn't try before stating it) I blame my memory.

Making an auto shut-down for the application could work indeed. Though it'd be perfect if we could know what idle shut-down time the player is set to.

I'll look into this and see if I can come up with something for Black Jack with this.

[Brett_val]

So this script requires two buttonclicks to close

screen.fillrect(0,0,400,240,color.new(0,0,0))
text.color(color.new(255,255,255))
ts=16
text.size(ts)

while true do

	screen.fillrect(100,100,200,20,color.new(0,0,0))
	text.draw(100,100,tostring(os.date()))
	screen.update()
	if control.read()==1 then
		if control.isButton()==1 then
			if button.click()==1 then
			
				while true do
					if control.read()==1 then
						if control.isButton()==1 then
							if button.click()==1 then
								break
							end
						end
					else
						os.wait(50)
					end
				end
				
				break
			end
		end
	else
		os.wait(50)
	end

end

It's working on the player; after one buttonclick, the time stops ticking, and when you then click home button again the app closes.

I left this running, and after 5 minutes it said "idle shutdown". Then it didn't go back to the players application menu, but stayed in the app, and then said "shutting down". Player shut down and restarting it didn't require a disc scanning.
So yeah, the player will probably send another buttonclick if the app didn't close the first time.

Ofcourse I got curious and added the requirement for another click:

while true do

	screen.fillrect(100,100,200,20,color.new(0,0,0))
	text.draw(100,100,tostring(os.date()))
	screen.update()
	if control.read()==1 then
		if control.isButton()==1 then
			if button.click()==1 then
			
				while true do
					if control.read()==1 then
						if control.isButton()==1 then
							if button.click()==1 then
							
									while true do
										if control.read()==1 then
											if control.isButton()==1 then
												if button.click()==1 then
													break
												end
											end
										else
											os.wait(50)
										end
									end
									
									break
							end
						end
					else
						os.wait(50)
					end
				end
				
				break
			end
		end
	else
		os.wait(50)
	end

end

the code is getting a little confusing, but it's working on the simulator and on the player: app closes after three button clicks.

I left this running again, and after 5 minutes the same thing happens.

It's very plausible that the freezing is in fact due to the player sending buttonclicks to the app, but the app is not responding to it. Good thinking Habhome!

But then I'm still left with the ZenDuck problem.. Even one buttonclick is enough to close it, but still it freezes. And in the situation I described in the first post, it would have closed after two buttonclicks.

Maybe it's because the app was doing too much after it received the buttonclick?

[Brett_val]

Habhome, I tried to fix Black Jack, by adding this:

	if button.click() == 1 then
			if ask then
				quit = true
			end
		ask = true	--Activate settings screen
		prompt = "Quit?"	--Set prompt message

It's working in the simulator and also on the player: pressing home button two times now also closes the game.
But still, when it tries to idle shutdown it freezes.

So I guess it's not as simple as multiple buttonclicks.. or do you have another suggestion for Black Jack's code?

[Habhome]

I see, with this information I'll be able to make Black Jack not freeze, I think. Unless I run into the same problem as you since mine also performs some actions during shut down. I'll ell you if I find a solution to it.

[Habhome]

Originally Posted by Brett_val

Habhome, I tried to fix Black Jack, by adding this:

	if button.click() == 1 then
			if ask then
				quit = true
			end
		ask = true	--Activate settings screen
		prompt = "Quit?"	--Set prompt message

It's working in the simulator and also on the player: pressing home button two times now also closes the game.
But still, when it tries to idle shutdown it freezes.

So I guess it's not as simple as multiple buttonclicks.. or do you have another suggestion for Black Jack's code?

That's exactly what I was going to begin with doing. I guess there's some other thing we have to think about. I'll do some testing later.

[Zaffo]

Strange thing is - IMO - that when you hold the power button during the game the player shuts down without a problem. Why is the shut down procedure after idle time different?

If it was to save some scores or end the program in the way the programmer intended they would have given it some more time before it would give up and freeze.

I tested idle shutdown in my snake game. If you are in the game and use the home-button your score it shown on screen for ~0.3 seconds after which you are directed to the menu. When you are in a menu and use the home-button the game ends. So you need the home button 2 times to exit the game while playing, which will take just over 0.3 seconds. This seems to be too much and the player freezes. Idle shutdown from the menu works fine.

So Creative could solve this in 2 ways:
1. Use the same method for idle shutdown as is used for power button hold shutdown.
2. Give more time before freeze.
Best would be to combine these and first try the home button for about 2 seconds and then use point 1 above.

How can we solve this? If the multiple click = immediate close of program doesn't work I have no clew.
I'm running this tool (iago1460s Test tool v0.1) now to see what it gives me.

Edit: Strange, no freeze there while the program doesn't shut down with the home button (only when touching the upper left corner of the screen).

[Habhome]

Hm, the notion about exit time is interesting. Maybe someone could make a app similar to Brett's test apps with different delays and see when/if it freezes? I would myself but I'm busy programming my Sumo Robot and going to test it today before the Swedish Championships tomorrow.

[Brett_val]

Thanks Zaffo, you totally broke down my conclusion and I updated the first post to try to approach what is really happening.

From what I've found until now, I think the os.wait plays a major role in this..

I updated the first post with some testing I did.

[Habhome]

I did some experiments with Black Jack and I believe I'm close to a solution.
First of all I simply changed the os.sleep(1) I had in the main loop to os.wait(10). Now it displays the "Idle shut down" message, but it still freezes after that.
One thing that came to mind then was that it perhaps has something to do with me having the draw function in the main game loop. I think that a solution to this would be to prevent the player from drawing to the screen always, and only when something should be changed. I came to think of this when I tested with Tetrajak's Crystal Connect, which has a confirm screen but still didn't freeze.

I'll do some testing with this in my Black Jack game when I get some spare time, it'll require quite a bit of rewriting of my code and I have a bunch of tests coming up, most of them important national exams. But I wanted to throw it out there since it may provide a solution.

[Habhome]

Sorry about the double post, but I just wanted to inform you of my latest findings.
The drawing is probably not much of an issue, I didn't manage to solve it by manipulating that.

Something which did work to fix this for my Black Jack game though was to divide it into multiple game loops where I use a confirm dialog function which I got inspired to make when reading Tetrajak's code, which contains its own loop for checking for button presses.

So now my Black Jack app also shut down when idle shut down kicks in on the player. (The bugfix will be uploaded later when I've done some cleaning of the code in a similar fashion)

[Zaffo]

After deleting the os.sleep() after the home button press during the game, and putting the os.sleep() in the menu after an if statement that disables it on game exit, my snake game shuts down properly.

After 5 minutes in the game I see a message with "Idle shutdown". The game goes to the menu. Then I get a "Shutting Down" message after which the player is off. I quess this all takes approximately 1 to 2 seconds. But it works the way it should be. It looks like it takes the same route through the code as when you would use the home button the exit the game and the menu.

At least this means that before shutting down there can be code to write to a file, draw a menu, etc.

[Habhome]

I'm not sure if you can save to files. My code should be going through that on shut down, but it doesn't save.

[Zaffo]

In that case it looks like it walks through the code but it ignores some parts. I can think of any reason why that would be the case, but it looks like it. But in that case I find it strange that I go through the menu in my snake. As it is in an another loop than the game and the menu is drawn by a function. Al of which seem to be opened.

It's a shame idle shutdown isn't supported by the sim.

[Brett_val]

Originally Posted by Zaffo

In that case it looks like it walks through the code but it ignores some parts. I can think of any reason why that would be the case, but it looks like it. But in that case I find it strange that I go through the menu in my snake. As it is in an another loop than the game and the menu is drawn by a function. Al of which seem to be opened.

I think it can display the menu because you took out the sleeps.
Notepad doesn't crash and can even save the file, and it has an else os.sleep(2) in the main loop, but no function calling. Maybe that's just enough.

I think it's a time-running-out issue, so wait's are a waste of time then .

I guess it could perhaps ignore parts of the code when the app is not in a loop anymore...

Originally Posted by Zaffo

It's a shame idle shutdown isn't supported by the sim.

Haha yeah testing this is pretty time consuming