Open sooslaca opened 7 months ago
Thanks for your interest and effort.
You seem to have fixed #1 & #2 with your push request.
for #3, I believe the reason does get copied one time to timer.json
at the beginning of each day for that day of the week. So, for example, on Monday, the Monday reason should get copied over to timer.json
the first time a game is played that day. So I'm guessing maybe the bug you are seeing is that, if it is already Monday, and you set a reason, it won't show that day, because its already copied over the reason for the day, but it will show next Monday. Is that right? if show I'll make that change so it works as expected.
for #+1, its supposed to play a 1 minute warning voice-over during your game, then a 10 second count down voice-over and then quit the game for you. Is that not working for you? Are you asking if it could also show a visual overlay at 1 minute and at 10 seconds in addition?
Actually, I've been testing your fix to change to UTC date. it doesn't seem to work for me. I'm thinking it was correct before. It needs to be using your systems local time. Maybe I was too fast to accept those changes since I didn't test them first. Are you sure changing to UTC date fixed your problem? The parental control does start with 1 hour on the schedule by default, the first time you install it, maybe that is what you were noticing?
hi, sorry if the patch caused trouble. For me that was the solution. Before patch this was for me on the UI when started a game (10 seconds later)
duration: 01:00:10
remaining: 00:00:00
After patch (expected):
duration: 00:00:10
remaining: 00:59:50
Maybe you need to ctrl+F5 refresh the page to have the js code come from server and not from the cache?
Some more info: my PC is in local timezone (GMT+1) my retropie (on rpi4) is in GMT:
pi@retropie:~ $ date
Wed 20 Mar 08:02:35 GMT 2024
pi@retropie:~ $ python -V
Python 2.7.16
for #3: your understanding correct. I started a game then I changed schedule reason and started again. I got your point. Not a big deal if it's working like you explained.
for #+1: if it's possible: yes a banner would be nice, my kid is ignoring the sound :)
I think I understand now. Your server (RPi) and client (browser) are in different time zones. I just assumed they would be the same and didn't code for that.
Next, I'll look into how to add an overlay to the game and get back to you on that.
Thanks I'll test the timezone fix, I see the commits.
Maybe the overlay is not that important, I found different issues too.
1) We mainly play with N64 and there is no retroarch running for that but mupen64plus emulator, so kill_game
is not really killing the game, just does nothing. I'll check on this further what would be the best to support both.
2) I see start_monitor
is running, but interestingly for me the __refresh_timer
is not updating timer.json
every 1 minute as it should. I'll check on this too.
That makes sense. It was hard coded to kill only retroarch. I didn't realize RetroPie can be configured for other emulators.
I couldn't test it because I'm running an RPi2 and it doesn't seem to have the ability to run a n64 emulator. So you will need to test it and let me know if it works.
As for the __refresh_timer
I'm not sure what you are referring to that isn't working. There is a refreshTimer
in index.html that runs every 10 secs. It reads from the timer.json
file to monitor if a game has stopped or started while on the timer tab of the UI. Then there is start_monitor
in parental_control.py which reads the timer.json
file every minute to see if the timer has expired while running a game. If it has, it will simply kill the game. When the emulator ends, either by being killed or by exiting the game, RetroPie will then call runcommand-onend.sh
which will call end_game
in parental_control.py. This will then update the remaining time in the timer.json
file. So the timer.json
file is not intended to be written to every minute. Just at the start and stop of a game.
I get it, I thought in the 60 seconds loop (in start_monitor
) the timer.json
file should be updated to the current value.
I'll test the fix for killing any emulator. Thank you
Tested the timer fix, different issue now: due to skew between clocks (rpi and PC/browser), countdown started from 60 minutes and 10 seconds (the skew was 10 seconds). Not a big deal, otherwise works good !
I think I found and just fix a bug that matches what you were describing. There was a bug in parental_control.start_monitor
that was playing the 1 minute warning sound, but never playing the end of game sound, and quitting the game when the timer reach 0. Not sure how I missed this. I think my kids weren't interested in letting me know. I think it is was you were describing was happening to you when you were describing the timer not working right, or expecting the timer.json
file to be written to periodically. I think it was this bug. It should be fixed now.
As for the 10 seconds off? I'm not noticing that on my end. Do you know why that's happening on your end. Could it be one of your computers not syncing to a time server and is off by 10 seconds?
Thanks for the fix, that looks good.
For the time sync issue, yes indeed, it was not synced properly, hence I'm saying it's no a big problem, with synced clock it should work as designed. Thought the timer should always start downward ;)
Thanks for sharing it, some similar I was looking for and this is a perfect fit!
Some issues I found: 1) In the readme:
should be:
2) On the webgui when game starts it is counting from 01:00:00 instead of 00:00:00 (so starts from 1 hour vs from 0 hour). Maybe it's related to time zone? I'm, in CET in EU.
3) When I save
Reason
inSchedule
on the webgui, it is changed inschedule.json
but not intimer.json
+1) Not sure on capabilities, but when a ROM is running is it not possible to 'flash' the TOIlet timer time to time? and stop the ROM when it reaches zero?
Anyway thanks for sharing your work!