Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
On Thursday, 18 February 2021 10:10:47 GMT Hamish McIntyre-Bhatty wrote: > I'm just finishing off my assignment, but should be able to look at > several WMT things this afternoon with luck. Hamish, I've just cracked the freezing problem, so you only need to look at the sockets error that I flagged on the Forum. As mentioned there that error doesn't seem to cause a problem, it just flags up an erroneous message received. I'd just like to know why. With regard to this issue, I suddenly remembered that Patrick had suggested using a separate thread to launch the MP3 Player, eg: threading.Thread(target=mp3_player_start).start() I had not tried that because I was under the erroneous impression that apscheduler launched the functions in a separate thread already; clearly not. Everything seems to be working fine now, although I need to test a few more things before I declare it ready for deployment. -- 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 Thursday, 18 February 2021 10:10:47 GMT Hamish McIntyre-Bhatty wrote: > I'm just finishing off my assignment, but should be able to look at > several WMT things this afternoon with luck. That would be appreciated. -- 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
Yep, I saw it. I'm just finishing off my assignment, but should be able to look at several WMT things this afternoon with luck. Hamish On 18/02/2021 10:08, Terry Coles wrote: > On Thursday, 18 February 2021 09:48:20 GMT Hamish McIntyre-Bhatty wrote: >> Can't recall if you've tried this, but what if you replace the call to >> mpg123 with a call to echo or similar, just to narrow down whether it >> might be mpg123 that's causing the issue. >> >> If it only crashes with mpg123, perhaps there are some verbose or debug >> flags you can use for mpg123 to reveal more information? > I only just got this, despite the datestamp being 7 minutes earlier than my > post. > > Have you seen my latest? > 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 Thursday, 18 February 2021 09:48:20 GMT Hamish McIntyre-Bhatty wrote: > Can't recall if you've tried this, but what if you replace the call to > mpg123 with a call to echo or similar, just to narrow down whether it > might be mpg123 that's causing the issue. > > If it only crashes with mpg123, perhaps there are some verbose or debug > flags you can use for mpg123 to reveal more information? I only just got this, despite the datestamp being 7 minutes earlier than my post. Have you seen my latest? -- 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 Wednesday, 17 February 2021 13:32:19 GMT Terry Coles wrote: > In any case, the Bells Pi code uses the same approach, so how come that > works and the Music code doesn't? I think I've sussed this. :-) At least I think I know what is going wrong. In order to respond to commands coming in from the Webserver, I have a function called check_webserver_commands(). This periodically checks for data on the socket, parses it and calls the appropriate function; in this case restartmp3() (which calls mp3_player_start() ). To service this function, I added a line to apscheduler: sched.add_job(check_webserver_commands, 'interval', seconds=1, id='check_webserver_commands') The problem with this is that when the calling function takes a long time to return, I get an error (too many instances), so I added a line to the beginning of check_webserver_commands(): sched.pause_job(job_id='check_webserver_commands') # Suspend until current job is complete and one at the end: sched.resume_job(job_id='check_webserver_commands')# Restart checking for commands The problem is that the mp3_player_start() function doesn't return until the line: mp3_wait = mp3_player.wait() has completed (and never if the loop is active), so the sched.resume job never gets run. I used apscheduler to ensure that the check_webserver_commands() function would get called frequently, but without locking the program up during the intervals between each check, but it would seem that it doesn't successfully interrupt the mp3_player.wait() method. I need that method to tell me when the loop is completed, so can anyone suggest a better way to poll the check_webserver_commands() function or to make the mp3_player.wait() method more interruptible? Of course I may be wrong on my hypothesis, but when I put the sched.resume() method just before the call to restartmp3() the rest of the commands from the Webserver were recognised and serviced. -- 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
Hi Terry, Can't recall if you've tried this, but what if you replace the call to mpg123 with a call to echo or similar, just to narrow down whether it might be mpg123 that's causing the issue. If it only crashes with mpg123, perhaps there are some verbose or debug flags you can use for mpg123 to reveal more information? Hamish On 17/02/2021 13:32, Terry Coles wrote: > On Tuesday, 16 February 2021 15:25:28 GMT Terry Coles wrote: >> So I'm kind of back where I started. > This morning I tried a variety of things to solve this; still to no avail. > > I've attached two more code fragments to this message; these are copied from > the latest version of the software on the Pis. The file > Minster_Bells_Software_Fragment.txt shows what I have on the Bells Pi to play > Change Rings on demand. Minster_Music_Software_Fragment2.txt shows the music > player version of this; which exhibits this problem. > > In order to get to the bottom of this I have: > > 1. Reduced the number of MP3 files in the Playlist directory to 1. > > 2. Re-written the code so that the line that uses glob to parse the files in > the directory is replaced with the actual path and filename to the first file. > > 3. Re-written the code to remove the while loop, to simplify things. > > 4. Commented out the lines that invoked the mpg123 player and terminated it > in the mp3_player_stop() function. > > Items 1 to 3 made no difference whatsoever to the behaviour; I still got the > freezing when I tried to restart the player/ > > With Item 4 the messages from the Webserver were responded to reliably but of > course no music was played. > > It would appear therefore that once the mpg123 player has been invoked and > then terminated, invoking it a second time makes the overall program > unresponsive. This I cannot understand because the "Music Playing" message > is > being printed, so presumably the lock up occurs at the line containing: > > mp3_wait = mp3_player.wait() > > I realise that the program will halt at that point until the mpg123 player > terminates, but the commands coming in are in new threads so they should > still > be responded to. (They have once.) > > In any case, the Bells Pi code uses the same approach, so how come that works > and the Music code doesn't? > > 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 15:25:28 GMT Terry Coles wrote:
> So I'm kind of back where I started.
This morning I tried a variety of things to solve this; still to no avail.
I've attached two more code fragments to this message; these are copied from
the latest version of the software on the Pis. The file
Minster_Bells_Software_Fragment.txt shows what I have on the Bells Pi to play
Change Rings on demand. Minster_Music_Software_Fragment2.txt shows the music
player version of this; which exhibits this problem.
In order to get to the bottom of this I have:
1. Reduced the number of MP3 files in the Playlist directory to 1.
2. Re-written the code so that the line that uses glob to parse the files in
the directory is replaced with the actual path and filename to the first file.
3. Re-written the code to remove the while loop, to simplify things.
4. Commented out the lines that invoked the mpg123 player and terminated it
in the mp3_player_stop() function.
Items 1 to 3 made no difference whatsoever to the behaviour; I still got the
freezing when I tried to restart the player/
With Item 4 the messages from the Webserver were responded to reliably but of
course no music was played.
It would appear therefore that once the mpg123 player has been invoked and
then terminated, invoking it a second time makes the overall program
unresponsive. This I cannot understand because the "Music Playing" message is
being printed, so presumably the lock up occurs at the line containing:
mp3_wait = mp3_player.wait()
I realise that the program will halt at that point until the mpg123 player
terminates, but the commands coming in are in new threads so they should still
be responded to. (They have once.)
In any case, the Bells Pi code uses the same approach, so how come that works
and the Music code doesn't?
--
Terry Colesdef change_rings_start(): # Play a file of change rings
global c_player
stop_playback()
print ("Change rings stopped")
c_file = 'Wimborne_Minster_StedmanCinques_16-10-2016.mp3' # Change rings.
c_path = os.path.join(chr_subdir, c_file)
blackhole = open(os.devnull, 'w')
if c_player is None:
c_player = subprocess.Popen(['mpg123', c_path], stdin=subprocess.PIPE,
stdout=blackhole, stderr=blackhole)
print ("Playing Changes - ", c_file, "to the Tower")
def change_rings_stop(): # Play a file of change rings
global c_player
if c_player is None:
return
c_player.terminate()
c_wait = c_player.wait()
if not c_wait:
print ("Change Rings: mpg123 failed:%#x\n" % c_wait)
c_player = None
Status[12] = "Bells not Ringing"
def mp3_player_start(): # Setup and run the MP3 Player
global playlists, playlist_index, mp3_player, Status
stop_playback()
playlist_index = last_playlist_index # stop_playback sets it ti zero.
print("")
print("Entry into mp3_player_start()")
print("Playlist Number = " +str(playlist_index))
print("")
while playlist_index != 0:
print ("Playlist Number = " + str(playlist_index))
print ("Playlist Length = " + str(len(playlists)))
Status[9] = str(playlist_index) # Current Playlist
mp3_subdir = playlists[playlist_index] # directory containing
mp3 files for the current Playlist
playlist = sorted(glob.glob(mp3_subdir + '/*.[Mm][Pp]3')) # Create a
list of files to be played in the current directory
Status[10] = playlist
mpg_list = ['mpg123']
args = mpg_list + playlist
print (args)
if mp3_player == None:
mp3_player = subprocess.Popen(args)
print("Music Playing")
mp3_wait = mp3_player.wait()
if not mp3_wait:
print('MP3 Player: mpg123 failed:%#x\n' % mp3_wait)
if playlist_index == 0:
print("Break from Playlist Loop")
break
next_playlist()
def mp3_player_stop(): # Setup and run the MP3 Player
global mp3_player, playlist_index, last_playlist_index, Status
last_playlist_index = playlist_index
playlist_index = 0 # Not Playing Flag.
if mp3_player is None:
return
mp3_player.terminate()
mp3_wait = mp3_player.wait()
if not mp3_wait:
print ('MP3 Player: mpg123 failed:%#x\n' % mp3_wait)
mp3_player = None
print("Music Stopped")
Status[10] = "Not Playing"
--
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 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
Re: [Dorset] On Second Entry to MP3 Player Function Program Stops Responding to External Commands
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. I have a feeling you did explain this arrangement before, so I probably should have remembered. -- 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 17:06:07 GMT Patrick Wigmore wrote: > I'm left wondering: > "Where are you calling next_playlist()?" > "What do you mean by 'freezes'?" That is triggered by another button on the Webserver Control page. > If you are calling next_playlist from an interrupt handler and if, by > 'freezes', you mean 'seems to stop handling interrupts', then this > could just be another manifestation of the same issue. Indirectly yes. 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. So yes. It could still be related. -- 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 Mon, 15 Feb 2021 15:02:23 +, Terry Coles wrote: > I just realised that things aren't quite as I thought. If I start > the program with the Plylist Number set to zero, the Music Player > doesn't start, as is expected. If I then call next_playlist(): > > def next_playlist(): > global playlists, playlist_index > > playlist_index += 1 # Select > the next Playlist Number > if playlist_index > len(playlists): > playlist_index = 1 > > Status[9] = str(playlist_index) > > mp3_player_start() > > then the software behaves as if the player has already been run and > freezes. Sorry, I didn't see this before replying. My response did not take any of this into account. I'm left wondering: "Where are you calling next_playlist()?" "What do you mean by 'freezes'?" If you are calling next_playlist from an interrupt handler and if, by 'freezes', you mean 'seems to stop handling interrupts', then this could just be another manifestation of the same issue. Otherwise, I'm less sure. Patrick -- 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 16:51:06 GMT Patrick Wigmore wrote: > mp3_player_start() contains a while loop, and it looks like that is > not supposed to terminate until playlist_index == 0. > > If your interrupt handler calls restartmp3(), and restartmp3() calls > mp3_player_start(), then the interrupt handler will not terminate > until playlist_index == 0 and both functions return. So, I think that > might be the problem. > > I don't think you've posted enough code to know for sure, but if this > is what's going on, then I think I would try having the interrupt > handler run mp3_player_start() in a new thread. That way, the > interrupt handler should terminate as soon as it has set the thread > going, leaving mp3_player_start() to carry on on its own. > > e.g. > > threading.Thread(target=mp3_player_start).start() Patrick, Thanks. I was beginning to realise (dimly) that it was something like this and have been trying to ensure that all functions exited cleanly. Ideally, I think that rather than having my program start the MP3 Player during startup it needs to always be started from an interrupt and that's what I was looking at. That way the program will sit in the almost infinitely long delay that was always the intention, except when an interrupt is being serviced. However, I can see that this isn't the whole story and I need to look into your suggestion in a bit more detail. I won't have time to do that this evening, so I'll have another go first thing in the morning. Thanks again. -- 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 Mon, 15 Feb 2021 12:53:24 +, Terry Coles wrote: > To me it seems that the software suddenly starts ignoring interrupts This makes me think the code that handled the previous interrupt might still be running. Having the previous interrupt handler still running is likely to block further interrupts from being handled. Taking a look at the code: mp3_player_start() contains a while loop, and it looks like that is not supposed to terminate until playlist_index == 0. If your interrupt handler calls restartmp3(), and restartmp3() calls mp3_player_start(), then the interrupt handler will not terminate until playlist_index == 0 and both functions return. So, I think that might be the problem. I don't think you've posted enough code to know for sure, but if this is what's going on, then I think I would try having the interrupt handler run mp3_player_start() in a new thread. That way, the interrupt handler should terminate as soon as it has set the thread going, leaving mp3_player_start() to carry on on its own. e.g. threading.Thread(target=mp3_player_start).start() Patrick -- 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 12:53:24 GMT Terry Coles wrote: > To me it seems that the software suddenly starts ignoring interrupts because > the command should be detected after no more than 1 second when apscheduler > calls the command checking function which works fine up to that point. I just realised that things aren't quite as I thought. If I start the program with the Plylist Number set to zero, the Music Player doesn't start, as is expected. If I then call next_playlist(): def next_playlist(): global playlists, playlist_index playlist_index += 1 # Select the next Playlist Number if playlist_index > len(playlists): playlist_index = 1 Status[9] = str(playlist_index) mp3_player_start() then the software behaves as if the player has already been run and freezes. Presumably therefore, there is something in the underlying environment within the running code which isn't there when the program is launched, but is by the time the code is ready to process commands. -- 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
