Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Tuesday, 16 February 2021 13:54:55 GMT Terry Coles wrote: > I've just spotted a difference between the code used by the Change Rings > Player on the Bells Pi and the code used by Music Player on the Music Pi. > I'm hopeful that this will be the problem. Well it looked useful, but made no difference. In the function change_rings_start() on the Bells Pi, there are the following lines: blackhole = open(os.devnull, 'w') if c_player is None: c_player = subprocess.Popen(['mpg123', c_path], stdin=subprocess.PIPE, stdout=blackhole, stderr=blackhole) whereas the function in the Music Player doesn't use this approach. Clearly the whole purpose of the blackhole is to stop the Player writing it's output to the screen, but I'm not convinced there is any advantage in this. Anyway it made no difference to the freezing. So I'm kind of back where I started. -- Terry Coles -- 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Tuesday, 16 February 2021 12:33:45 GMT Terry Coles wrote: > I'm going to do a bit more testing after lunch. I've just spotted a difference between the code used by the Change Rings Player on the Bells Pi and the code used by Music Player on the Music Pi. I'm hopeful that this will be the problem. I'll let you know later today. I'm going to be busy for an hour or so on something else. -- Terry Coles -- 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Tuesday, 16 February 2021 12:25:10 GMT Hamish McIntyre-Bhatty wrote: > 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? Probably not in fact. I only posted that there because it related to the sockets code and you wrote our custom implementation of that. As mentioned on the Forum, it triggers an error but doesn't seem to stop the message passing working (at least for everything except this particular problem). Of course the fact that minstermusic.py seems to be sending a string that it should never send could be the cause of the current problem, but I don't see why considering that the 'freezing' only occurs when I try to restart the music and this messaging error occurs all the time and doesn't seem to affect other things. I'm going to do a bit more testing after lunch. -- Terry Coles -- 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
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. -- Terry Coles -- 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On 16/02/2021 11:59, Terry Coles wrote: > On Tuesday, 16 February 2021 10:50:59 GMT Terry Coles wrote: >> If anyone wants to look at the full package the code is on our GitLab >> Repository at: >> >> https://gitlab.com/wmtprojectsteam/minster_bells_re-engineering > BTW. I've now realised that I introduced (yet another) bug when I did the > last update. At the end of the file I wrote: > > if opening_hours: # Program has begun after 10 am, > sched.add_job(mp3_player_start, 'interval', seconds=10, > max_instances=1, id='First Start on Power Up') > > what I was trying to do was to get apscheduler to fire off the function > mp3_player_start ten seconds after the initial startup code had completed, > but > what I've actually done is triggered it every 10 secs with an instance max of > 1, which barfs. ;-( > > Is there a way to do this or should I simply forget about trying to do it > with > apscheduler? 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. 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. 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Tuesday, 16 February 2021 10:50:59 GMT Terry Coles wrote: > If anyone wants to look at the full package the code is on our GitLab > Repository at: > > https://gitlab.com/wmtprojectsteam/minster_bells_re-engineering BTW. I've now realised that I introduced (yet another) bug when I did the last update. At the end of the file I wrote: if opening_hours: # Program has begun after 10 am, sched.add_job(mp3_player_start, 'interval', seconds=10, max_instances=1, id='First Start on Power Up') what I was trying to do was to get apscheduler to fire off the function mp3_player_start ten seconds after the initial startup code had completed, but what I've actually done is triggered it every 10 secs with an instance max of 1, which barfs. ;-( Is there a way to do this or should I simply forget about trying to do it with apscheduler? -- Terry Coles -- 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Monday, 15 February 2021 19:55:25 GMT Patrick Wigmore wrote: > On Mon, 15 Feb 2021 17:13:12 +, Terry Coles wrote: > > When the button is pressed, the Webserver generates a message > > > > which it sends to the Music program. There is a cron job, triggerd > > by apscheduler which parses the message and in this case calls the > > next_playlist() function. > > Ah, I think that changes things. Triggering a cron job is going to > have an effect similar to starting a new thread. (Indeed, that might > be precisely why you are using a cron job.) In which case, my > hypothesis could well be completely wrong. Well. This morning I rewrote the startup code so that mp3_player_start() would always be started the same way, ie via apscheduler. First, I modified the startup code to ensure that whether the program was started inside Opening Hours or outside apscheduler would always be the calling function. This worked perfectly but the problem still exists. I have posted a screenshot of the three consoles that show whats going on at: http://hadrian-way.co.uk/Misc/Screenshot_20210216_100939.png The large pane on the left hand side shows the program minstermusic.py executing and top right shows the Webserver output. Bottom right is the minsterbells.py execution which isn't really relevant to this, but it does show several messages being exchanged successfully. The point is that everything proceeds fine until I press the 'Start Music Button'. This message is sent using sockets code and is successfully received by the Music program (this is flagged about half-way down) and the commend is enacted. The Webserver then asks the Music Player for a Status update (the last message in its pane), but the player does nothing. The only way out is to Ctrl-C. Has anyone got any other thoughts? If anyone wants to look at the full package the code is on our GitLab Repository at: https://gitlab.com/wmtprojectsteam/minster_bells_re-engineering -- Terry Coles -- 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
