Is there a way to tell the daemon to stop triggering on corename changes?

[Paradox]

So we can load our own pics without killing the process, and then turn it back on, when the script exits. If not, can we discuss adding such a feature?

Also, instead of starting another issue, I'd like to request text scrolling be added (Scrolling back and forth, as I've done in SAM, and wrap around, as I'm working on implementing, and, any other type that can be done) I imagine it would be so much easier to do in the firmware (as transitions are) than running an update timer, and doing it in the script.

[venice1200]

Stopping and Starting the tty2oled Daemon Script should do the job.

But I know that SAM has the problem, and I don't know why, to (re-)start the daemon again.

An easy to implement solution, I think, can be that SAM creates a file in /tmp when tty2oled should sleep.

Means, the tty2oled Daemon works as normal but don't send data if this file exists.

Let's call the file /tmp/tty2oled_sleep.

Is this a possible solution for you? If yes, try https://raw.githubusercontent.com/venice1200/MiSTer_tty2oled/main/Testing/tty2oled.sh

Scrolling, I will take a look and collect infos but it's nothing I like to implement actually.

[Paradox]

When you start a process from another process, it becomes a child process, and can die when the parent dies, also, it can sometimes stop the calling script from exiting, cleanly. this is why we need some way to run the script without running the script, a simple named pipe or socket, or, as you suggest, even a simple file that will allow the daemon to start and stop itself, would be the best options.

This is one of the reasons I have done all this hard work to make SAM work with named pipes, I can send commands and information between the different parts of the script, without running the script several times, and getting lost in the mess of variables in the first process not being accessible to the child processes, or, subsequent copies of the same script. Also, named pipes don't need a constantly running loop to read the file over and over, until something changes, wasting CPU cycles, when a pipe reader is waiting for information to arrive, it is blocked, and will not run until it has data in the pipe to read, and will take less CPU cycles. It can also react faster, in some cases, because it doesn't have to wait its turn, it can react to data, immediately.

Like anything, they can have their own set of headaches, but, in the end, I feel SAM is a better script for all the work we have done.

[Paradox]

I've tried it, works pretty well, but, I would suggest watching for MENU, and remove the file, yourself, after an amount of time, in case something goes wrong, and the file doesn't get removed on exit. Also, I exited, cleanly, but, a race condition happened, and your script didn't seem to notice that the file was gone, until I started a different core, manually, but, the good news is, it did notice, and put up the corepic.

Of course, the nice thing is, when it does miss the core change to MENU, You get to look at the CMDBYE pic longer. :)

[venice1200]

The Daemon is waiting for a change of /tmp/CORENAME. If this change happens before you remove the sleep file nothing happens.

So please try to remove the file at first, wait a moment, and then do what you need to get the user back to the MENU.

[Paradox]

There is no good way to trigger the menu change, after removing the file, that would not mess up other things, if we force a change to the menu, it kills our feature of being able to continue playing the game when the user pushes a button. The best solution would be a named pipe, I will make a PR for it.

[venice1200]

It should be easy to delete the sleep file on "MENU" Corename.

No need for a Pipe.

[Paradox]

I figured out why it wasn't working right, and I will submit a PR for that, instead.

[venice1200]

Check the latest tty2oled.sh in testing https://raw.githubusercontent.com/venice1200/MiSTer_tty2oled/main/Testing/tty2oled.sh

It contains now the logic to delete the sleepfile if the corename = "MENU" and the sleepfile exists.

[venice1200]

I figured out why it wasn't working right, and I will submit a PR for that, instead.

If there is something wrong tell/show me.

[Paradox]

PR submitted The problem is, once the inotifywait command is given, it blocks until a corechange happens, if the race condition is met that the corename changes, but, the sleep file still exists, it won't send the new data to the device, you almost fixed it, before I submitted mine, but, yours still didn't quite do it.

[Paradox]

By the way, deleting the file, and uploading a new one, doesn't allow anyone else to know exactly what you changed...

[venice1200]

PR submitted The problem is, once the inotifywait command is given, it blocks until a corechange happens, if the race condition is met that the corename changes, but, the sleep file still exists, it won't send the new data to the device, you almost fixed it, before I submitted mine, but, yours still didn't quite do it.

Could you explain the "race condition" please.

And what is if [ "$newcore"]; then checking?

[Paradox]

I explained the race condition, in the message.

checking to see if MiSTer is at the menu, but the sleep file exists, so, delete the file and go on.

[venice1200]

I need ask again! What does the command if [ "$newcore"]; then as there is no test operator.

Race Condition... Do you mean this? race condition is met that the corename changes, but, the sleep file still exists, it won't send the new data to the device,

[Paradox]

PR updated I forget sometimes that bash isn't exactly like other languages that I'm used to where doing it the way I did would return true if there are contents and false if there aren't sometimes bash does that sometimes it doesn't depends on the situation. So it's better to be explicit.

[Paradox]

Sorry I did it in two commits but I'm editing on my phone and accidentally submitted when I didn't mean to

[venice1200]

I will look into at the weekend.

[venice1200]

Just a quick update, the MENU Logo after booting up is no longer shown.

[venice1200]

The two core variables (old/new) are initialized in the sourced system ini file.

[Paradox]

Just initialize oldcore with some random data like START although, I have never noticed this. Maybe I don't restart my system often enough. I'll have to test later, I'm working, now .

[venice1200]

Just initialize oldcore with some random data like START although, I h

That helps, thx.

Can I still use Super_Attract_Mode.sh start?

If I do I get the follwowing on ps ax

A lot MCP's.

[Paradox]

Looks normal, it produces background processes to handle triggering and CORENAME changes as well as communication between the processes.

[Paradox]

Although in the latest at least one of those processes is gone we got rid of the inotifywait that was doing nothing for us the Python scripts were created to replace it but it was never removed

[Paradox]

Don't worry most of those processes are named pipe readers and when they are not reading or writing information they are blocked in a way that they take up less resources than the while loops that we were using before

[venice1200]

Ok.

Please try https://raw.githubusercontent.com/venice1200/MiSTer_tty2oled/main/Testing/tty2oled.ven.sh Activate debug="true" in your user ini to get some output.

[venice1200]

Related to the latest PR 2022-08-13.

First, I have renamed your Script to tty2oled.sam.sh. Makes live easier.

Why not keeping the old strategy using "MENU"? It was working fine or not?

Is the actual "Main" SAM is using already the sleepfile functionality? Which branch should I use for tests?

[venice1200]

I need to ask again, was my last "Menu" Version not working correctly?

The last one you modified to "inotifywait".

[Paradox]

It worked fine but this one will periodically time out and check to see if the file is old enough to delete, the other one would just continue to sit there as long as the file doesn't get deleted so if somebody opens htop and kills all the processes that file will not get deleted and the old version will just continue to sit there, with this one after 5 minutes it'll wake up and see that the file is too old will delete it and continue

[Paradox]

There are some considerations with this, the time can be changed, so it wakes up every minute or two, instead of five, and you can change the age of the file, to a lower number, but, one issue that will need to be taken care of, is the user could change their gametimer, and, in fact, roulette mode does this, so, I think I need to add the gametimer value to the file, either, on it's own, or, a better idea might be to make the date value an expiration date (add gametimer to EPOCHSECONDS, and write that to the file), then, no matter what you set the timer to, as long as the date has passed, it is safe to assume the sleep file has been orphaned, and can be removed. I'll be right back with an updated PR.

Edit: this is completed, and works, beautifully.

[venice1200]

Is SAM Re-Triggering the Sleepfile each Round?

Don't make the script too complicate.

We end up with an a tty2oled script containing more code to delete the sleepfile than doing his normal job.

My Opinion is still to use "MENU" to delete the sleepfile

or build another script doing this "watchdog" functionality separately which can be started from SAM. This Script can check if SAM is running and if not wait a while and delete the sleepfile.

[Paradox]

This works better than MENU, sorry if you can't grep it, and, it also doesn't require SAM to work, if the sleep file is not there, it will just go on working like normal. Also, another thing that makes it better than looking for MENU is, if our tty2oled script exits, for some reason, but, SAM continues running, your script can still take over and display the core pic for the current core, with MENU detection, it wouldn't.

[Paradox]

and, yes, it is remaking the sleep file, each time it starts a new core, but, your script doesn't need to worry about it, as long as the time contained in the sleep file is either in the future, or, in the past, your script only has the two options, no big deal. You seem to be making it out to be more complicated than it actually is.

Edit: In fact, this has actually simplified things, not complicated them.

[Paradox]

As a side note, I have changed the way we display custom core pics, and, if you want to add them to the repo, just let me know, if you do, and I can remove them from our repo, and update script. Also, if you want to give the SAM_splash a different name, that fits in with your standards, just let me know, and i can make the change, necessary on our end. We haven't, yet made a banner for tgfx16cd, but, if you add one before we do, and name it tgfx16cd, our script will handle it just like any other.

[venice1200]

As a side note, I have changed the way we display custom core pics, and, if you want to add them to the repo, just let me know, if you do, and I can remove them from our repo, and update script. Also, if you want to give the SAM_splash a different name, that fits in with your standards, just let me know, and i can make the change, necessary on our end. We haven't, yet made a banner for tgfx16cd, but, if you add one before we do, and name it tgfx16cd, our script will handle it just like any other.

This note is related to Named-Pipes?

~Please send your script PR and I will test.~

I'am happy with the SAM Splash Pictures name, no problem.

//Edit You are correct, it simplifies the sleepfile handling. I have adapted your Script changes to my "ven" Version, please try. I have reduced the inotifywait timeout to 60. We/I only need to document the handling of the "Sleepfile" before we go live. And I am happy to add your Corepictures to the Repo. Just send an PR.

One thing, how can we handle a Sleepfile which doesn't contain the time in the file. Maybe we can use the modify date/time an set the modify date into the future? I tried successful and added it already to my "ven" file:

Filecreation: 
touch -d "120 seconds" /tmp/tty2oled_sleep
Script if
if [ $(( `stat -c "%Y" ${SLEEPFILE}` )) -gt ${EPOCHSECONDS} ]; then

Just a note, the "Named-Pipe" Version from today is not working for me.

/root# Super_Attract_Mode.sh start
 Please wait while settings are loaded.../media/fat/Scripts/.SuperAttract/SuperAttractSystem: line 516: /tmp/.SAM_tmp/ini_settings: No such file or directory
 Done!
/media/fat/Scripts/.SuperAttract/SuperAttractSystem: line 335: /tmp/.SAM_tmp/default_paths: No such file or directory
/media/fat/Scripts/.SuperAttract/SuperAttractSystem: line 341: /tmp/.SAM_tmp/default_paths: No such file or directory
/media/fat/Scripts/.SuperAttract/SuperAttractSystem: line 426: /tmp/.SAM_tmp/amigashared_path: No such file or directory
 Checking Gamelists
 Looking for games in  /media/fat/games/Amiga...cat: /media/fat/Scripts/.SuperAttract/SAM_Gamelists/amiga_gamelist.txt: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/_Arcade''...find: ‘/media/fat/_Arcade''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/ATARI7800''...find: ‘/media/fat/games/ATARI7800''’: No such file or directory
find: ‘/media/fat/games/ATARI7800''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/ATARI5200''...find: ‘/media/fat/games/ATARI5200''’: No such file or directory
find: ‘/media/fat/games/ATARI5200''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/ATARI7800''...find: ‘/media/fat/games/ATARI7800''’: No such file or directory
find: ‘/media/fat/games/ATARI7800''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/AtariLynx''...find: ‘/media/fat/games/AtariLynx''’: No such file or directory
find: ‘/media/fat/games/AtariLynx''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/C64''...find: ‘/media/fat/games/C64''’: No such file or directory
find: ‘/media/fat/games/C64''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/NES''...find: ‘/media/fat/games/NES''’: No such file or directory
find: ‘/media/fat/games/NES''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/GAMEBOY''...find: ‘/media/fat/games/GAMEBOY''’: No such file or directory
find: ‘/media/fat/games/GAMEBOY''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/GAMEBOY''...find: ‘/media/fat/games/GAMEBOY''’: No such file or directory
find: ‘/media/fat/games/GAMEBOY''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/GBA''...find: ‘/media/fat/games/GBA''’: No such file or directory
find: ‘/media/fat/games/GBA''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/Genesis''...find: ‘/media/fat/games/Genesis''’: No such file or directory
find: ‘/media/fat/games/Genesis''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/SMS''...find: ‘/media/fat/games/SMS''’: No such file or directory
find: ‘/media/fat/games/SMS''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/MegaCD''...find: ‘/media/fat/games/MegaCD''’: No such file or directory
 0 Games found.
 Looking for games in  /media/usb0/games/NeoGeo''...find: ‘/media/usb0/games/NeoGeo''’: No such file or directory
find: ‘/media/usb0/games/NeoGeo''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/NES''...find: ‘/media/fat/games/NES''’: No such file or directory
find: ‘/media/fat/games/NES''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/S32X''...find: ‘/media/fat/games/S32X''’: No such file or directory
find: ‘/media/fat/games/S32X''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/SMS''...find: ‘/media/fat/games/SMS''’: No such file or directory
find: ‘/media/fat/games/SMS''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/SNES''...find: ‘/media/fat/games/SNES''’: No such file or directory
find: ‘/media/fat/games/SNES''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/TGFX16''...find: ‘/media/fat/games/TGFX16''’: No such file or directory
find: ‘/media/fat/games/TGFX16''’: No such file or directory
 0 Games found.
 Looking for games in  /media/fat/games/TGFX16-CD''...find: ‘/media/fat/games/TGFX16-CD''’: No such file or directory
 0 Games found.
 Looking for games in  /media/usb0/games/PSX''...find: ‘/media/usb0/games/PSX''’: No such file or directory
 0 Games found.
/media/fat/Scripts/Super_Attract_Mode.sh: line 1948: sam_start_restart: command not found

[Paradox]

Yeah, the start command is broken, you should always use the proper way /media/fat/Scripts/.SuperAttract_init start (or, quickstart to skip the extra 60 second wait) I'm still working on those commands. Strange, though, where are your roms?

Edit: where do I put the pics? do I have to add them to the zips and rebuild? also, I add another 10 seconds (currently) to the sleep file date, and, the current core is already, possibly, a few seconds old when the sleep file is created, so, to be safe, I would add more time to the sleep file with no date inside of it, although, I'm unsure how you would run across that, unless you think someone else will try using it, and, not bother to do it correctly...

In addition, the time will not always be predictable, if the sleep file doesn't contain a date, because, for instance, roulette mode allows the user to run each game for an arbitrary amount of time, and could even be 5 minutes. This is why this is the best approach.

If you think others will be using this, feel free to include the snippet of code where I create the sleep file as an example of how to use it.

[Paradox]

Start command is fixed, now.

[Paradox]

I finally looked at the changes in your repo, and you completely obliterated it. like I said, before, just checking the creation date doesn't work.

[Paradox]

Yeah, I'm totally lost on the pics, do I create a new rar? Am I looking in the wrong repo?

Edit: Never mind, I was looking in the wrong repo, found it.

[venice1200]

Is there a plan from your end to use the tty2oled sleepmode in the main branch?

If yes, I would start adding just the sleepfile detection with the corresponding inotifywait command to our daemon script.

I would not add the semi-automatic sleepfile deletion functionality. If we see that we really need such a functionality we know what we need to add.

[Paradox]

I don't know what he plans on doing with main except that eventually named pipes will be Main but none of that matters for you if the sleep file exists you'll react to it if it doesn't you won't it won't make any difference whatsoever

[venice1200]

I will close this issue for now as the Stable got "Sleepmode Support" already.