On 16/02/2021 12:15, Terry Coles wrote: > On Tuesday, 16 February 2021 12:03:28 GMT Hamish McIntyre-Bhatty wrote: >> Well I must say, I'm not that familiar with apscheduler, but it looks to >> me as if it's causing more issues and complexity than threading would, >> at least in some cases. >> >> I also don't think it exactly avoid threading, because apscheduler is >> probably using its own internal threading to achieve the results. > I didn't want to avoid threading as such; I was trying to ensure that all > instances of mp3_player_start() were running in a thread as per the > suggestion > by Patrick. As it happens that hasn't solved the original problem. > >> If I wrote this, I'd be more likely to use multiple threads and some >> global state to control them - much like how I've done in the river >> system with variables like config.EXITING to signal program shutdown. > I suspect you are right, but apscheduler has worked well for me for a long > time and is used extensively in this software to schedule events at certain > times of the day and at intervals down to 1 second (to trigger the check for > messages in the sockets code). > > It may be that my problem here is nothing to do with threading and something > else is blocking the minstermusic execution from continuing when I try to > start or restart the music. If that is the case I'll revert the code to the > way it was because that was working fine apart from this current problem.
That is very possible. I should add that just because I'd think to do it that way doesn't mean that that's necessarily the right way to do it - you could also consider it reinventing the wheel. If I find some time, I'll look into this for you, but I figure the issue you posted on the forum is higher priority? Hamish
signature.asc
Description: OpenPGP digital signature
-- Next meeting: Online, Jitsi, Tuesday, 2021-03-02 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
