Picochess V4.1.8 released - for the brave testers

[Johan Sjöblom]

New aestetic web server. Change colour of board and allow mobile phones and other web browsers to speak the moves (use the new mute button). Big thanks to Anthonio for all his work and to all contributors and testers.

Fixes for mame engine and script engine handling. Thanks to all the testers for that.

There is now a new "dummy" uci setting: Analysis = false used at least on Galjoe and Sayuri so that these engines work with V4.

There is a new interaction mode PGN Replay which allows you to automatically load the latest game for replay. Queen D5 should do it. If you upload a PGN game from the mobile phone or if you load a game from disc like last game, or game1, 2, 3 it also goes into this mode.

If the game is not ready and without result, it will go into Normal play mode so that you can finish the game. When in PGN Replay mode: Click the ||> Play-Pause button to autoplay through the game. For fast autoplay without comments: turn of tutor coach and watcher. If tutor is on, it will write comments in the last_replay.pgn file in the games folder.

AND: You can still use the PGN Replay engine as in V3.

Note: If you do take replace engines from the menu, expect the next boot to last 10-15 minutes as it now downloads all the lite mame engine set, and all the lc0 personalities. If you want to follow boot progress you can tail this log file in which you see boot progress of the updater:

tail - f /var/log/picochess-update.log

If you are confortable with a console you can update the engines manually. First you run the move-engines-to-backup script (or delete selected folders yourself) and then you run 

./install-engines lite

Note that neither move-engines-to-backup nor install-engines shall be run using sudo.

Detailed diff list for selected commit messages since 4.1.7:

• 562aa690 Adjust 1280x720 tft
• 29d8e847 fix grey area on the left side (the side with the board) goes to the bottom, the right side has a margin
• 9eb5917d fix the horizontal scroll issue in the games table
• 6e5beb0f Restore fontawesome font permissions
• 07fa9f13 Added client mute
• dad26a39 Add image to README for additional content reference
• 82f93908 resoluciones 1024x600 1280x800 1280x720 + mute
• 7a814c97 1280x720 && 1280x800
• de2c6453 Update board control div with height and border styles
• 9d13ee58 Change top position from 50% to 100% in custom.css
• 0b70af1a Fixed according to Gerhards comments
• 12b0cfe5 Fix issue PicoChess Starts Up Inside Engine Menu Fixes JohanSjoblom/picochess#155
• ca1df639 Start from Mode.NORMAL if we load a game that is not finished "*" or "?"
• 38ad58b2 Issue #149 Handle incomplete PGNs when switching sides
• c886588e Fix unit tests
• db3fba48 Issue #52 - Ensure stubborn UCI engines are terminated when quitting them
• 5fb7d641 Allow engines to opt out of PicoChess analysis via UCI Analysis flag
• fddb5136 Handle script engines like MAME in analysis scheduling
• d763fccb Handle python-chess library ping AssertionError
• ff7d7f2f Force move with play-pause ||> button will now start a 2-second timout on all engines, not only on mame.
• be2f7297 Hardening the UciEngine against crashes (tested Feeks engine)
• 7109db51 Fixed issue Wrong engine name displayed at startup Fixes JohanSjoblom/picochess#144
• 97ba56f7 Fix tutor comments in the new PGN Replay interaction mode
• 68a1cb02 Fix for PGN Replay engine end of game. It now completes correct at last move.
• 9d25bb6c Aesthetic-web-server - first version
• 8e13380d Added script_engines download to install-engines script
• a87621de Issue #14 After mame engine crash take back move and reopen engine. Send the uci options to the reopened engine.
• 66c1a8cf Improve issue #14 Make sure the user hears the engine-fail message when a game aborts due to the engine.
• b5acc25b Improve issue #14 - User can force hung MAME engines by clicking ||> play-pause button
• 1ae4af22 Hotfixe issue #14 - Dont crash when mame engine crashes
• 89c0a919 Issue #139 - use play() when asking for moves from mame engines
• 05115602 Analyse also engine moves when using playing PGN Replay engine so that we get move hints.
• f3b3cb2b Start next analysis as soon as the engine finishes, instead of waiting for the user to enter the move.
• a04ee2b2 Improve analysis for mame engines
• c3983f5c Less debug logging on info DEPTH, SCORE, PV
• 3030b6f4 fix PGN engine analysis fallbacks
• ec0b003f fix for potentially crashing UciEngine when using pgn_engine or other engines that dont have any analysis...

[Wee MacGregor]

Just updated, everything looking good on a 7" Official Raspberry Pi display.

When in analysis mode, how to I oncrease the number of displayed lines?

Many thanks,

Andrew

[Antonio]

Tiene que ser con un navegador "fuera" de la Raspberry. Pruebe con el tlf móvil por ejemplo. Con el navegador de la Raspberry solo se mostrará una línea de stockfish, se puso así para que no se vuelva lenta o bloqueada con tanto recurso, sobre todo con la versión 3 de la Raspberry.

It has to be done with a browser "outside" the Raspberry Pi. Try using your mobile phone, for example. The Raspberry Pi's browser will only display one line of Stockfish; this is how it's set up to prevent the Raspberry Pi from becoming slow or crashing due to excessive resource usage, especially with Raspberry Pi version 3.

[Johan Sjöblom]

I should have commented that YES Antonios new Web client works on most Pico screens now... with a wide range of resolutions. Thats a big improvement.

We still have the restriction that if you are on "localhost", that is, if your browser is running on the same Pi as the picochess you can only have one analysis line.

I recommend opening the browser on your mobile phone....

We could for the future consider a mode where Picotutor coach/watcher are off, engine will not attempt to analyse anything extra (only play if you play an engine). In such a mode we could allow more than one analysis row also on localhost... For now I recommend using a mobile phone to check the analysis...

[Wee MacGregor]

 >For now I recommend using a mobile phone to check the analysis...

I am failing to see the logic in this. Why would using a mobile phones web browser put less load on the raspberry pi cpu? The pi is already running a web client and server.

Andrew

Virus-free.www.avast.com

--
You received this message because you are subscribed to a topic in the Google Groups "PicoChess" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/picochess/tlYKpiCQ23Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to picochess+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/picochess/981b989b-f8b9-454d-84fc-a622901d64b7n%40googlegroups.com.

[Antonio]

Si, reduce la carga de la cpu de la raspberry.    El stockfish del webserver se ejecuta solamente en el navegador, por lo tanto si el navegador está en la raspberry pi, pues más carga; si el navegador está en una tablet, pues la carga de analisis lo soporta el procesador de la tablet,    si se ejecuta en un teléfono móvil la carga de stockfish web lo soportará el procesador del smartphone.        Es sencillo de entender y fácil para el usuario de elegir a lo que le da más prioridad.    Traduzco con Google al Inglés, espero se entiendas bien.   Saludos

Yes, it reduces the CPU load on the Raspberry Pi. The web server's Stockfish runs only in the browser, so if the browser is on the Raspberry Pi, there will be more load; if the browser is on a tablet, the tablet's processor will handle the analysis load; and if it's running on a mobile phone, the smartphone's processor will handle the Stockfish web load. It's simple to understand and easy for the user to choose their priority. I'm translating this into English with Google Translate; I hope it's clear. Regards

[Wee MacGregor]

I did not realise Stockfish was running in the browser. 

Thanks.

Virus-free.www.avast.com

On Sun, Nov 23, 2025 at 10:51 AM Antonio <antonio.z...@gmail.com> wrote:

Si, reduce la carga de la cpu de la raspberry.    El stockfish del webserver se ejecuta solamente en el navegador, por lo tanto si el navegador está en la raspberry pi, pues más carga; si el navegador está en una tablet, pues la carga de analisis lo soporta el procesador de la tablet,    si se ejecuta en un teléfono móvil la carga de stockfish web lo soportará el procesador del smartphone.        Es sencillo de entender y fácil para el usuario de elegir a lo que le da más prioridad.    Traduzco con Google al Inglés, espero se entiendas bien.   Saludos

Yes, it reduces the CPU load on the Raspberry Pi. The web server's Stockfish runs only in the browser, so if the browser is on the Raspberry Pi, there will be more load; if the browser is on a tablet, the tablet's processor will handle the analysis load; and if it's running on a mobile phone, the smartphone's processor will handle the Stockfish web load. It's simple to understand and easy for the user to choose their priority. I'm translating this into English with Google Translate; I hope it's clear. Regards

--
You received this message because you are subscribed to a topic in the Google Groups "PicoChess" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/picochess/tlYKpiCQ23Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/e5c640d9-2b41-441b-9c8b-af58ad176a3fn%40googlegroups.com.

[Johan Sjöblom]

Its an interesting question. Running Stockfish in a browser is not the same Stockfish as compiled for Pi. But if we compare the power it gets on Raspberry Pi4, Pi5 web client in your mobile phone: My S24 android is about 3 times faster than in a Pi5 browser to run the web client Stockfish.

AND: This good question gave me an idea. The Picotutor is actually always running a multi-line analysis (as restricted by the ROOT_MOVES). At the moment Picotutor V4 is running 30 parallell multipv analysis lines (V3 is running 200 multipv I think). We could perhaps make it so that on localhost it shows these lines, and if you are not on your Pi localhost then it would show the web client stockfish? We should display a little bit more in picochess than the current one bestmove only. The information is already there. We can also have 2 engine tabs, one for web client like now, and one for the "Pi server" analysis. Displaying that information would not require more cpu.

[Henri]

Nice to see the new the beta 4.1.8 version. The desktop screen looks great. It's wonderful having Antonio working on the CSS and doing magic! 

Now we are in the stage of perfecting the desktop and its options, here two small thoughts:

- Don't like the mute option. Just have the sound as default, it's no problem to adjust the sound through a monitor or a phone, no need for a special button imho

- A 'refresh' option would be nice instead. When opening a position in a monitor or a phone the starting position is always shown until a move is made. Refreshing (F5) doesn't work.

Henri

Op zondag 23 november 2025 om 12:14:56 UTC+1 schreef messi...@gmail.com:

[Antonio]

Debajo del tablero, el segundo botón desde la izquierda actualiza lo que dices.

El botón que está a la izquierda del "color".

To view this discussion visit https://groups.google.com/d/msgid/picochess/d105589f-7565-4f54-b8ed-5a0613dcb901n%40googlegroups.com.

[Henri]

Thank you Antonio for pointing that out. Had not noticed it!

Op zondag 23 november 2025 om 16:51:20 UTC+1 schreef Antonio:

[Johan Sjöblom]

Henri: The mute is there to avoid getting double speech on Debian installations. In most Raspberry Pi the synthetic speech is never heard on the browser but on Debian you will get double sound as you hear both the web browser synthetic and the picochess server picotalker sound. Up until now the synthetic speech has been commented out on all V4 versions. The mute button is there to control the synthetic speech in the web browser client only, not to control the pico server sound. The pico server side voice control is done as before by settings in menu / picochess.ini file.

-- Johan

PS. fixed 2 small display bugs for analysis result delivery today already... So already 2 PR hotfixes on this version... Analysis has changed and been optimised, but so has also the handling of crashing engines.

[Aldo Bleeker]

The display as coded by Antonio in the new version 4.1.8 is looking pretty good! On the Raspberry Touch Display 2 1280x720 7" screen the Mute button is placed a bit low in the window, but that's really it.

But seeing the new Mute button made me realise that on Debian there are two other buttons, GET PGN and UPLOAD, that not only aren't visible on my RPi 5, but aren't even available. Should they be, or is this intended on aarch64, like the 1 line analysis?

Aldo

[Johan Sjöblom]

The get PGN button was hidden in V3 on localhost so I guess we just continued on that tradition... But there is really no reason to hide them that I know of. CPU cannot be the reason, maybe the reason has been practical, why would you like to download PGN on the same machine as you can already find them in the games folder?

A small note on the PGN buttons: The upload sends the file to the games/uploads directory and asks Picochess server to load it into PGN Replay mode. The PGN download button is still the old one and it returns the content of the web client PGN, not the picochess server PGN. That means that you cannot see the end-of-game result and not the comments made by picotutor... Until we fix the download PGN so that it would fetch the PGN info from picochess server instead of the web client.

[Johan Sjöblom]

It would be really easy to make the PGN buttons visible on localhost... Just let me and Antonio know if you think that would be ok.

[Randy Reade]

As you stated, Johan, there is no need for the Get PGN button on the browser running on the machine that is running PicoChess. It is only meant for browsers running on other machines allowing you to easily import it into other software, for example. There is also the email function which can be set up in picochess.ini.

An Upload function on the Pi (localhost) seems of little benefit but perhaps it could be of use on a PC running PicoChess.

Randy

[Aldo Bleeker]

That IS a good question... Thinking about it, there probably isn't a great need for those buttons on localhost. I believe I'll be fine without them.

Aldo

[Dirk]

What an incredible work you all did on v4 - chapeau!

Regarding the web display on my 1024x600: 

Now it looks really fine - and yes the button for muting is not necessary on the local host (and I see it the same way like Henri) we probably donate need it at all as the user can mute either in the web browser tab (most browsers offer a mute option for different tabs) or via system volume level....) and beside of that the button was way too big at least on my 1024x600 screen.

Speaking of ergonomics and way too big/small  elements:

For me on the 1024x600 web display all the important buttons (all the clock buttons and the buttons under the board dispaly9 are too small because I use (like most users I assume) the touch interface and NOT the mouse (probably what you used during development ).

The clock buttons could be at least a little bit bigger (these are the main touch interface) so that they are like a square instead of rectangle (so just a few additional pixel in the height).

The buttons directly under the board display could also be stretched a little bit (in both directions I think),

And because I am getting older the main display output for me (the DGT clock output) could also be a little bit bigger so I can keep my old glasses ;-)

On the contrary: the "color/turn" display and the mute buttons are a littler too big I think).

Here you can see the main differences:

version 4 

and version 3

But that just me experience from a pur touch interface user...

Thanks for all your work!

Dirk

[Antonio]

Gracias, es difícil contentar a todos. Lo que algo está bien para uno, está regular o mal para otro.

Miraré lo de los botones más grandes, aunque para ello habrá que quitar espacio a otra cosa.  Gracias por probar.

To view this discussion visit https://groups.google.com/d/msgid/picochess/78035c1e-73ed-40c5-8bcb-435fb3119cfan%40googlegroups.com.

[Francois Vannier]

I was used to play with Bookworm V3 & just switched to V4. First, thanks for all efforts to improve Picochess. The online updates & the web server visual improvements are alone worth the migration. I have also the impression that the stability of the retro-engines has been improved.

My HW is a Pi4 with a 13.3 inch 2560x1440 screen (using local browser) + a RevII DGT e-board.

Main remarks about issues with BT connexion to the the RevII:

I am having several issues with the BT connexion with the board: that's the only point I see as a regression comparing to earlier V3
> No repeatable behaviours : could connect in a few seconds, several minutes or never
> Sometimes the engine seems happy and ready to play whereas there is no connexion to the board - Going to the System/eboard/DGT menu & reselect DGT triggers a reboot
> If the connexion is lost (reset DGT board), most of the time, Picochess can't reconnect when the board is back in BT mode. It may happen though that Picochess succeeds in reconnecting & a game can be played, but the display of the DGT board is no longer refreshed
> I tried many sequences when powering on the board & Picochess to improve the odds to get connected : I did not find any that can always reproduce the same behaviour. Currently, I am using a cold boot for both with a couple of attempts to get the system working.

Other points:

> As in V3, the box with the book lines is cutting vertically the last line - Only with 1280x720 it's nicely formatted. The other boxes have no issue
> I agree with previous comments, the mute button is too big & slightly misplaced vertically - Not sure it's useful either  when connected locally
> Sometimes, using the web buttons to navigate in the menus is unexpectedly "slow", like a couple of seconds to see something happening
> In the SYSTEM / POWER menu, is this possible to add "Picochess restart" (w/o rebooting entirely) ?
> The picochess update thru the SYSTEM menu worked just fine to go to 4.1.8 from the initial image, but using it later to update engines deleted previously added engines & made the roms folder no longer accessible (visible, but triggers an error when clicking on it & undetected by Picochess-> "error" vocal message)
> For the retro-engines, the fullscreen display option for artwork is ignored whether set from the menu or changed in picochess.ini. The workart window can still be maximized manually.

I can provide some test support, if this can help.

Thanks !

Kind regards,

Francois

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/picochess/CAHiOUFWRELyLXYDanTy1fWYjo5Y1ZXBhaxtaw_qP41KxBxijvQ%40mail.gmail.com.

[Randy Reade]

Hi Francois, 

Can you test the BT connectivity using the latest v3.4 Trixie Desktop image? It would be good to see if it's a Trixie issue or a v4 issue.

Also, a debug log might be helpful of when it fails. Just stop PicoChess, delete the log files in picochess/logs, edit picochess.ini and switch to debug log level then reboot.

Randy

[Francois Vannier]

Hi Randy,

Thanks for the quick reply.

Here are attached 2 logs:

1) V4 when not working (cold boot for both equipments) - Note that I eventually succeeded to connect a few times, but there was no log in the logs folder.
2) V3.4 Trixie is working like a charm for that matter: instantaneous successful connexion repeated several times. Here the logs are present, 2nd file.

I did update the OS in both cases from the desktop prior to any test.

Note: Everytime the connexion failed in v4, picochess was claiming to be ready, without any display of the "no DGT e-board" message with rotating segment. I had to navigate in the picochess menus to eventually having this message displayed.

Francois

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5WdutKO5j8hu0po-PiGaGFB82%3Dhx4Tok4qNHC%2BBR0YaOUb4w%40mail.gmail.com.

[RandyR]

One thing to check that I forgot to mention is to make sure Bluetooth isn't soft blocked. In a terminal or via SSH just type 'rfkill list'. If it is, just run 'sudo rfkill unblock all'. I'll have a look at the logs. (It's very strange that there would be no logs in the folder when PicoChess is running with debug logging enabled. You can always check the status of PicoChess using 'systemctl status picochess.service'.)

[RandyR]

Well, in v4 it sees the board but isn't able to pair ('pairing failed'). If bluetooth is not blocked in v4 as mentioned in the previous message, I would suggest the following:

• Turn OFF your board
• Enter the following commands in a terminal or via SSH:
  • sudo systemctl stop picochess
  • sudo rm -rf /var/lib/bluetooth
  • sudo reboot

Wait until the Pi has booted before turning ON the Rev II. Once you hear the "PicoChess" announcement, turn ON the board. Give it some time to connect. Hopefully it will. If so, the next time you boot up PicoChess, make sure the board is ON already (I don't own a Rev II so not sure how long it tries to connect via BT so perhaps turn the board ON just after powering ON the Pi so that it's ON when PicoChess starts).

Randy

[Francois Vannier]

Randy,

Logs are missing ONLY in v4 when the connexion is successful. Attached v4 log is coming from the failure case where the command output is :
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

About your last mail, I applied your procedure to no avail, waiting several minutes w/o any successful connexion. Typically the board is up well before picochess & it's working like that without a glitch in V3.4 Bookworm & Trixie.

Do you think it's impossible to port what is working for DGT BT communication from V3.4 Trixie to V4 ?

If nobody else is complaining, I suspect other DGT e-boards are not facing the issue in V4...

I'll retry later to capture logs when the connexion happens in V4.

Francois

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/6ee34591-581c-4c24-b24e-c24bde65c8c7n%40googlegroups.com.

[Randy Reade]

But the logs don't depend on a BT connection unless you didn't switch to debug (but you obviously did since the v4 log has lots of DEBUG entries). Did you try a new v4 image download? I can't check the BT connection for DGT boards at the moment but from the OS perspective there shouldn't be any differences. It's the same Trixie OS.

You can also try connecting and pairing, etc. manually via the terminal. That might provide more clues as to why it is failing.

Turn the Rev II OFF, then in a terminal:

sudo systemctl stop picochess.service

bluetoothctl

power on

agent on

default-agent

remove 60:8A:10:62:0A:E3

Turn the Rev II ON. It should be in pairing mode. At the [bluetoothctl]> prompt type the following commands:

scan on

Watch the scan until you see the Rev-II detected (the line that shows PCS-REVII-010099)

pair 60:8A:10:62:0A:E3

trust 60:8A:10:62:0A:E3

scan off

quit

Since DGT uses TTY you need to connect using rfcomm:

sudo rfcomm connect 123 60:8A:10:62:0A:E3

At this point the board should show connected (maybe there's an indicator led?)

Try a reboot and see if it connects next time. Again, turn the board ON before PicoChess starts.

sudo reboot

It would be nice to see the output of your commands. Note that I'm going a bit by memory and am not entirely sure what you will see as responses to the commands.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CADa9EqVme0-1cevh2ezWYt8Cx5Gyt7RmPZkirTzLb%2BXw6%3Df-nA%40mail.gmail.com.

[RandyR]

And one other thing to try - reset Bluetooth on your Rev II. It can happen that the security keys exchanged when pairing can be refused when you've paired the Pi and the Rev II using a v3 image and then a v4 image. The key for the Pi no longer matches what the board is expecting even though the Pi is the same. At least that's my understanding. I've had success doing this myself (I have many Pi's and SD cards and 4 different

 boards). I will usually reset the board when I delete the /var/lib/bluetooth folder so it's like starting from scratch. And I check for BT being soft blocked at the same time.

Randy

[Francois Vannier]

Randy,

About the logs, l have no clue, sometimes present, sometimes not. I was not able this time to collect any. I agree that should 

not be related to BT, something shall be wrong elsewhere. Yesterday, I saw once at picochess exit 5 instances created from picochess.log.1 to picochess.log.5 with different dates & they were not there before (!)

Following your procedure.

> I succeeded in pairing manually. When done, a pop-up of successful connexion is shown on the desktop

> The command "sudo rfcomm connect 123 60:8A:10:62:0A:E3" returns "Can't connect RFCOMM socket: Host is down" & this is killing the pairing
> Doing it again w/o the last command, 2 successes in a row to connect after cold reboot
> 3rd attempt : seemed to fail as picochess instantly became ready whereas the connexion was not established. Moving to system menu the search was reactivated (the connexion attempt message was displayed, w/o doing anything else than navigating in the system menu) & get connected

> All other attempts failed, even after having resurrected the search message 

> Sometimes the message "no DGT eboard" is flashing a fraction of a second in picochess before it stated to be ready though it's not - Maybe picochess in V4 is giving up on the connexion too rapidly, but other times it is attempting forever w/o success

> The succesful pairing was visible once in the BT desktop drop down menu, but was absent the rest of the time

The DGT board is always ready/waiting before picochess comes up.

I'll keep v4 on a SD card for further tests, but I'll switch back to V3.4 Trixie to verify that the connexions are really flawless as it appeared to be with my first attempt.

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5WduscwrYbwrpJtCJA61yDWN_h2A2QTraOv2gSx4iXnnppug%40mail.gmail.com.

[Francois Vannier]

Randy,

Updates on RevII BT:

> Finally V3.4 Trixie behaves like v4, no magic. I was just lucky at first try, so sticking to V4

> RevII is a bit picky when it comes to BT pairing, likely making it more difficult to get connected

> When the connexion has been successful once, it can be reproduced provided the respect of a particular sequence to cold start & shutdown

Besides,

> V4 has some defaults compared to V3 wrt how handle the DGT BT connexion, like stating the engine is ready despite the lack of connexion + the timer to get connected is maybe also too short + one case where the board was connected, but no more message displayed on the board screen (RevII specific)

> For the other V4 specific remarks, I'd keep on top : retro artwork full window is not working, engine updates shall change only what is needed & not delete added engines, the mute button to remove

> The slowness of reaction when pressing a key (physical or web, not systematic) is common to both Trixie versions. Is a Pi4 a bit too slow to run Trixie ?

Francois

[Johan Sjöblom]

Thank you for the testing effort Francois Highly appreciated!.I need to plan the improvements to V4 so I will return to these topic with questions. Some quick comments now:

- I will hide the mute button on localhost

- I have not changed any board bluetooth communication but V4 picochee main program is asynchronous which means I would need to add some waiting for the board connection. I need to analyse and research first. I will have a look if some timer has changed.The board communication itself is still thread based and synchronous. I have not yet had the courage to change the board communication.

- the engine replacement is very simple at the moment yes. I think we need to plan a folder structure to make it modular so that it does not update all, For example, maybe user roms and added engines would be in a folder that we do never touch? That might also require a user specific ini file.

- the artwork should not have changed at all, but maybe I have done some mistake? Or its a Trixie issue?

- A Pi4 with only 2G should be enough to run Trixie… I have to research what could cause menu button slowness.
— Johan

[Francois Vannier]

Hi Johan,

Big thanks for what you're doing for picochess and your answer !

> About the BT connexion, V4 & V3 Trixie are behaving more or less the same, so no hurry. About the message to the board no longer displayed, it might be an old bug unearthed. I'll communicate back if it is reproducible.

> The slowness on some responses can be experienced in different places at different moments : button actions or piece moves. I did not test enough to point to either Trixie or v4

> The fullwindow option for artwork is ignored / not working only in V4  : when you select the option in the menu & press enter, it does not propose "on" & "off" to choose from, but returns immediately with a vocal "ok" & no actual change

Francois

To view this discussion visit https://groups.google.com/d/msgid/picochess/8250b0ce-e3ce-4c79-b136-745cb5080f00n%40googlegroups.com.

[RandyR]

Hi Francios,

How are you checking for the logs? PicoChess doesn't delete them. You will always see them in /opt/picochess/logs/ and yes, in debug log level the log will fill up relatively quickly. PicoChess keeps the last 5 logs so you will see picochess.log.1 to picochess.log.5 as the log reaches 1MB in size and gets backed up. picochess.log is always the latest.

Did you reset Bluetooth on the Rev II? You didn't say.

There was a mistake in my list of commands which probably caused the Host is down response. Try this instead:

Turn the Rev II OFF, then in a terminal:

sudo systemctl stop picochess.service

bluetoothctl

At the [bluetoothctl]> prompt type the following commands:

power on

agent on

default-agent

devices Paired   <---- Note the capital P. 

Let me know if the Rev II is listed (it may not be as it will be removed if PicoChess can't connect to it.) Continue:

remove 60:8A:10:62:0A:E3

Turn the Rev II ON. It should be in pairing mode. 

scan on

Watch the scan until you see the Rev-II detected (the line that shows PCS-REVII-010099)

pair 60:8A:10:62:0A:E3   <--- Use the PIN 1234 if asked, and YES to Confirm.

trust 60:8A:10:62:0A:E3

scan off

Since DGT uses TTY you need to connect using rfcomm. Open a separate terminal window and enter:

sudo rfcomm connect 123 60:8A:10:62:0A:E3

At this point the board should show connected (maybe there's an indicator led?)

Try a reboot and see if it connects next time. Again, turn the board ON before PicoChess starts.

sudo reboot

As Johan said, the engine startup is separate from the board connection. But, you should see the "no DGT e-Board /" message on the display until the board connects. Unfortunately it looks like in v4, once you see the Engine Setup and Engine Name in the display you will no longer see the "no DGT e-Board" with the rotating line. This can be seen in your v4_KO.log in the previous post. I don't believe that's causing the connection issue, though.

If you can, test with an older v3 Bookworm image (to rule out Trixie).

For your full-screen artwork:

'sudo apt install xdotool'

Randy

[RandyR]

Sorry, Francois, for misspelling your name. 🤦

On Tuesday, November 25, 2025 at 9:51:25 AM UTC-8 RandyR wrote:

Hi Francios,

[Francois Vannier]

Randy,

No worries 🙂

Got it for the logs. Here are 2 logs of the following sequence in v4:

> Cold boot

> Connexion succeeded after a couple of minutes

> Setup a game

> Shutdown by placing the white queen in e1

> Do it one more time : same result

2 things:

> I suspect the connexion delay is coming purely from the BT scan, as I saw, when doing it manually, that the time needed to detect the RevII is highly variable. Picochess may not be involved in this (V3 & V4 the same). The only point to mention is the ask to V4 picochess to have the "connexion attempt" message displayed when picochess comes up & try to connect to the board, instead of having the last engine name used right away displayed : basically doing what V3 is doing.

> Eventually the random "freeze/delays" is becoming the main issue whatever you're doing. A move can take up to 3 seconds to be reflected on the screen board, same for a button action or even with voice announcement that could have a blank of several seconds in the middle. Typically for the buttons in the menus, you press a series of keys, nothing happens & a few seconds later all "stacked" commands are executed at once. I played in "noeboard" mode from an external browser : it was perfectly fast & smooth !

Francois

--
You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/5353af4b-debd-402d-b371-97c138bfb270n%40googlegroups.com.

[Randy Reade]

I've noticed some lagging with v4 myself but I suspect it is due to other processes taking CPU time and the board connection routine, I suspect, is taking much of PicoChess's resources (which makes sense to me as you want the board to be connected before playing). That's why no-eboard mode works fine.

I'm sure Johan will be able to sort out the blocking of the connection attempt message in the display.

From your logs: initially PicoChess sees that there is a device that is already paired (saved in the /var/lib/bluetooth folder) probably from the previously successful connection. The first attempt at connecting to the board using rfcomm fails. bluetoothctl gets restarted but it takes another 2 minutes before it sees the board again (via scanning). This is not unheard of. It tries to pair but is unsuccessful (don't know why). It tries to pair again but the board is not available. PicoChess then removes the board from the /var/lib/bluetooth folder. Half a minute later PicoChess again finds the board via scanning but pairing fails again. It tries to pair 2 more times, fails, and again removes the board. A half minute later, PicoChess detects the board and this time pairs and connects successfully.

I'll attach the relevant entries. Not sure why it has so much difficulty connecting to your Rev II. Is there a firmware update available? Anyway, my current advice is to just wait until it connects. Sometimes it can help to cycle power on the board if PicoChess doesn't connect after a minute or so.

Randy

[Francois Vannier]

Randy,

Lagging : Hum... I unfortunately left a permanent vnc session open between my PC & the Pi4. Closing it improved the lag to a point where it is now acceptable...

Connexion : Your analysis reflects what I have been seeing also doing the scan manually. I suspect that the scanner might be a bit "blinded" by the number of BT devices hanging around these days + the BT device from the RevII not being as reliable as others. I have the RevII 3.36c firmware from 2022 that is even nowhere listed on the web. So, I'll bear with it & be patient. This is the lottery : sometimes 2s, sometimes 3 mn. 

Thanks again for your help.

Francois

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5Wdus_uRHWmKRcXfd6cDSjDymTn7WB%3DHFWL1cm2gnm63a_fg%40mail.gmail.com.

[Randy Reade]

Well, the firmware is definitely more recent than what DGT is offering on its website so perhaps not that. It's possible to hard-code the board MAC address into a modified board.py which would take some effort and probably not a good idea without knowing exactly what the connectivity issue is exactly. And would make updating a pain.

Another option is to use btmon to monitor the Bluetooth communication and get more feedback on why it fails.

The board.py for DGT is a bit of a hack as it is. Maybe the future will present a purely python solution for connecting to classic Bluetooth. 😉

Randy

On Tue, Nov 25, 2025, 1:23 p.m. Francois Vannier <francois...@gmail.com> wrote:

Randy,

[Francois Vannier]

I installed on my recent android phone an old chess application that was able to use a DGT board via BT : Acid Ape Chess (GM edition) to check if these connexion issues could be confirmed as related to the RevII BT 2.0 HW/SW.

Result = instant connexion all the time ! Not to mention the BT scan & pairing were extremely fast as opposed to the sluggish scan & unreliable pairing of the Pi4.

I also put back in service my retired DGT Pi running Picochess V3 : instant connexions as well

 Looks like it was pointing to the Pi4 BT HW/SW being the problem.

Now the cherry on the cake : see the photo. My Pi4b casing is made of aluminium alloy acting as a passive cooler. I took out the lid & now the connexions are ultrafast & reproducible. 🙄

Sorry for all the spam. I hope this could help if someone has some signal issues with a raspberry pi...

Francois

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5WduvRhy4GnePUDPoieeQcYyQdg-9MmY59cOeoQ_4_oK0x4A%40mail.gmail.com.

[Dirk]

Hi Francois,

glad you found the cause/a solution.

Nevertheless the Rev2 is very "picky" regarding bluetooth (I think because of old protocol or non optimal implementation).

I NEVER could pair my Rev2 without the manual steps Randy described above (deleting the bt folder, resetting bt on rev2, eventually pairing manually via bluetoothctl etc.) for a new image.

But after that the connection succeeds EVERY time is is very quick (but the rev2 must always started first otherwise connection won't be established (this is different than with my DGT eBoards where connection also is working finde regardless of them sequence)).

Regarding the display of the missing §"no-eboard message": yes this happened to me also several time so there is definitely a timing/sequence problem)

Dirk

[Randy Reade]

Glad you solved it, Francois. Thanks for sharing your solution.

[Johan Sjöblom]

Nice... You have removed your Pi4 from radio blackout !  To let the 2.4G bluetooth signal in you need a hole the size of a 10th of the wavelength, so if you drill a hole larger than 12mm the Bluetooth communication should not be trapped inside the box. This is why the microwave ovens have max 1mm holes to keep the radio waves inside the owen and not heat up us :-) I did work at Ericsson 1997 (ish) when Bluetooth standardisation started :-) At least I remember we had working Bluetooth connections around 1999 for sure.

I have now made a branch that improves Picochess startup so that the OK sound does not come until an eboard has connected. And on DGT boards you can now see the spinner while waiting for the connection. I tested my own DGT board so anyone with other boards could test this branch. But the real question is what kind of timeout I should have before giving up and saying "ERROR"... Currently I have 5 minutes, but that seems long? Maybe 2 minutes?

Branch: 163-eboard-connection-at-startup

Pull Request: https://github.com/JohanSjoblom/picochess/pull/164

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5WduvEoSTwObu0BHDi%2BbAnQDQ7mFbMK1uFv7aFZJ%3DR_Xs7%3DQ%40mail.gmail.com.

[Randy Reade]

This brings up a couple of thoughts for me. If the board doesn't connect it would be nice to have an option to restart the detection/connection process (I currently either reboot or log in via SSH and restart the picochess.service). Or, maybe better, have the process restart itself (if there IS currently a timeout - I didn't think there was). And, perhaps an option to restart PicoChess without rebooting.

Randy

[Johan Sjöblom]

The 5min timeout is new to this branch! I tested the DGT board by starting pico with the board turned off. If I turn it on before the timeout it will connect and say OK, at least on my Debian. Maybe some other eboard needs a restart of bluetooth? 

A small idea, I would never stop looking for the board, but say ”ERROR” every 30 seconds or every 1 minute,..? Or just be silent? But never give up the search?

So pico would then not start without the board. Now the timeout ”gives up” after 5 mins and talks ”ERROR”. You never hear OK if the board did not connect.

Or reboot after the 5 minute timer? Not sure what is best?

[Randy Reade]

I think just seeing the "no xx board /" with rotating segment is enough to know that the board connection hasn't been made. No timeout is necessary. Just leave it up to the user to decide to reboot or just restart PicoChess.

Not sure we need a separate (or delayed) "ok" for when the board connects. The absence of the "no xx board /" indicates that, as long as you have heard/seen the "ok engine" announcement, you are ready to go.

Just my opinions.

[Francois Vannier]

Quick test of Johan's branch on the RevII (DGT):

1) eboard on with "lid off" / good signal : the connexion is so fast that the "rotating wait" message had not got a chance to be displayed

2) eboard left off : picochess came up and froze : buttons inactive, just the name of the last engine was displayed 

3) eboard on with "lid on" / weak signal : picochess displayed the "rotating wait" message for about one second, then the engine name for also one second or so, then back to the rotating msg until connexion is OK (about one minute in this case) - Here I saw again the lags which happened to be more related to the poor BT communication than the vnc session, as I stated in a previous message

I also switched off the board in the first test after the successful connexion : the localhost web page froze, put back on the eboard, was able to navigate in the menus with the eboard buttons, but the web I/F remains frozen.

I agree with Randy : no need of a timer

Conclusion : looks ok except when the eboard is switched off before or after picochess is up

Francois

--

You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5Wduu4uEFAcJ3rXuWFNo-e1cN%3Di0kc92od3gvQvnEwGVYtLA%40mail.gmail.com.

[Johan Sjöblom]

A few quick fixes in the branch 163-eboard-connection-at-startup:

Timer removed. Startup simply waits until the eboard is connected without ever timing out.

Small improvement to detecting the connection state.

I can turn my DGT eboard off and on in the middle of the game. Web menu is frozen during that time, as it is also if I start picochess with DGT board turned off. It starts working again as soon as there is a connection.

So what I still have to analyse is why the loss of DGT eboard connection stops all messages from the menu (they are blocked, and sent immediately after the DGT board connection comes back). Maybe this can also explain the slowness?

Anyway, I will be back with more analysis on this. Above listed small improvements are now in the branch.

[Johan Sjöblom]

the branch now tries to avoid blocking the menu while the DGT eboard connection is lost, had to slow down the spinner a little bit, wrap it in a temporary async wrapper (until the board.py has been made fully async) and to move the waiting-for-board into an own async task so that the program actually starts fully even though one async task is still waiting for the board to connect... Definitely needs more testing and code review, but its a start...

[Dirk]

I think (can’t check at the moment) in v3 the menu is not blocked as well when connection is lost or after startup when connection has not been established.

[Randy Reade]

Correct, Dirk. 

To view this discussion visit https://groups.google.com/d/msgid/picochess/4c6ea0e1-d0c2-4a18-a331-2feeed65968cn%40googlegroups.com.

[Johan Sjöblom]

Yes definitely correct, and the reason is the Thread system in V3. I merged the 163 branch now as it fixes the startup issues. Its now in the normal master branch.

I opened a new issue branch, but I have not done any changes yet,  The new branch name is:

167-eboard-connection-mid-game

In this branch I will try to fix the situation if you lose the DGT connection mid-game. It might be that short breaks are not a problem but I am testing by taking the power of my DGT board, wait a while, and then turn it on. This one I have a feeling is also a problem on V3.

[Johan Sjöblom]

The DGT board does reconnect during mid-game... BUT: Not always. So it actually works, but its not 100% reliable in all cases.

I think the core issue is: sometimes the post-reconnect DGT_MSG_VERSION/init doesn’t arrive; when it does, recovery works, when it doesn’t, the board stays offline. So this is a little bit of a random situation

I will keep analyzing and see if I can increase the reliability that it actually reconnects during loss of connection during mid-game.

You can post comments or findings here in the issue: 

https://github.com/JohanSjoblom/picochess/issues/167

[Johan Sjöblom]

DGT re-connect improved during mid-game (the issue link in previous message).

PR: https://github.com/JohanSjoblom/picochess/pull/168

Branch name: 167-eboard-connection-mid-game

I can now turn off my DGT board during the game, and turn it back on 10 seconds later and continue the game.