Focus lost after changing segment length
I'm still have no idea of the checkboxes that you have checked for JACK transport in preferences for your testing, as per the questions at the end of the opening of this bug. I have not carried out any further jack testing since then, but I should have added the following which I had at the time, which hints that the xruns may not be harmless, but is not conclusive: There are two more scenarios in which the state=Running error occurs, the first of which I knew when I opened the bug, but deleted that...
xruns using new JACK Transport Logic
I can also see the xrun message. I believe this message is totally harmless. The jack transport client uses its own jack client which does not process audio data (and runs in a different thread to the audio process). One question - do you really need the jack ports for each instrument ? This means Rosegarden must create a huge number of jack ports which means a performance hit in the audio subsystem. I recommend either deselecting "jack outputs for individual audio instruments" or just ignoring the...
The main purpose of this bug has been fixed. The jack transport now responds when changed in ardour, and presumably other jack clients. So, this bug, as reported, can be closed.
This issue should probably have been opened as a separate bug or at least something unexpected. Although the main bug can be closed, I should mention that I ran with all of the JACK related boxes on Preferences/Audio unchecked and the repeatable state=Running error on RG launch is no longer repeatable. But it is random now and appears infrequent in my case. In addition, somewhere in the middle of around 20 different sessions the following one-off set of errors occurred again i.e. the ones involving...
As a passing comment, I think that ardour automatically prunes non-existent sessions from its recent list, as does the GTK filemanager for its files and directories...but RG does not. I'm not sure if that implies standard behavior. But the advantage of RG's leaving them there is that the user is aware that they used to be there, and can clear them now with the new functionality. Unfortunately, if the non-existent is mixed with those that do exist, it requires a pick and error window to find each...
Works fine for tempo 74, but from the nature of the bug, I can't comment on all other tempos...except the default of 70. But from the report title itself about tempo=74, it can be closed.