Is there a known issue with Python's Threading and waiting a long time?
Question:
Sorry if this is a strange or not completely detailed question, but I have a music app, and when you pause music, then resume a long time later the app will occasionally crash. It is not consistent, around 15% of the time it’ll crash, and I have not found a common cause for this. The app will crash with a:
Exception in thread Thread-46 (resume):
Traceback (most recent call last):
File "C:Usersmy_nameAppDataLocalProgramsPythonPython310libthreading.py", line 1009, in _bootstrap_inner
Process finished with exit code -1073741819 (0xC0000005)
The initial call calls a fuction:
def resume_thread(self):
self.is_playing = True
self.thr = KThread(target=self.resume)
self.thr.start()
self.song_begin = time.time()
It basically calls ‘resume’ on a thread, the other two variables are just for keeping track of internal stuff, not important. self.resume looks like:
def resume(self):
self.exited.clear()
self.resume_list.append(self.pause_time)
self.song_count -= 1
new_time = 0
self.controller.music_obj = self.current_playlist[self.song_count]
self.song = AudioSegment.from_file(self.controller.music_obj.Savelocation)
for true_time in self.resume_list:
new_time += true_time
self.song = self.song[new_time:]
self.coming_from_loop = False
self.testsong("sent")
So this function (top to bottom): clears a class variable that holds a threading.Event(). Calculates how much time is left in the song. Corrects the song index. Sends the current song to the ‘controller’ (MVC model). Adds up all of the time that has been paused, removes that time from the current song (so amount of song that has been played already). sets classs var (coming_from_loop (not important)), and finally, calls ‘testsong’, which plays the music. I have also noticed that there are two main things affecting the odds of a crash:
1). A module I use to use ‘global keybinds’. Called ‘system_hotkey’. I noticed that the app will have a much higher crash chance if this keybind is used to call ‘pause’ versus manually clicking a button (in tkinter). The app has crashed before without using it, but it produced a slightly different error that I have forgotten to document. I’ll add it if I manage to reproduce it.
2). Change in how the ‘time elapsed’ is calculated. Before, it was a system based on the time between playing & pausing. So if you pause, then resumed 10 minutes later, it would’ve used that to calculate how much of the song is left. Now, it is a timer that counts down while playing music, and pauses when the song is paused. This significantly reduced how often the crash occured
3). Only ever occurs when it has been a long time elapsed since pause. Has never occurred within a smaller timeframe like 30 seconds.
I can’t say for sure what causes it, as it is fairly hard to reproduce, but it seems to occur because the thread is trying to do a calculation after waiting a while (like creating a Pydub.Audiosegment), during which, it fails to do so and crashes. If you want to view all of the source code, all of it is in: https://github.com/nednoodlehead/punge/blob/master/punge_main.py Line 433-896.
Any help or thoughts are greatly appreciated.
Answers:
Solution ended up being something off screen. Where the collective pause-time of one track was longer than the next track, that data would ‘leak’ over and try to begin the music at after it’s total length. Guess it didnt audibly become apparent because it would overwrite that audiosegment with a new one, but if it failed to write the first one, the crash would occur.
Sorry if this is a strange or not completely detailed question, but I have a music app, and when you pause music, then resume a long time later the app will occasionally crash. It is not consistent, around 15% of the time it’ll crash, and I have not found a common cause for this. The app will crash with a:
Exception in thread Thread-46 (resume):
Traceback (most recent call last):
File "C:Usersmy_nameAppDataLocalProgramsPythonPython310libthreading.py", line 1009, in _bootstrap_inner
Process finished with exit code -1073741819 (0xC0000005)
The initial call calls a fuction:
def resume_thread(self):
self.is_playing = True
self.thr = KThread(target=self.resume)
self.thr.start()
self.song_begin = time.time()
It basically calls ‘resume’ on a thread, the other two variables are just for keeping track of internal stuff, not important. self.resume looks like:
def resume(self):
self.exited.clear()
self.resume_list.append(self.pause_time)
self.song_count -= 1
new_time = 0
self.controller.music_obj = self.current_playlist[self.song_count]
self.song = AudioSegment.from_file(self.controller.music_obj.Savelocation)
for true_time in self.resume_list:
new_time += true_time
self.song = self.song[new_time:]
self.coming_from_loop = False
self.testsong("sent")
So this function (top to bottom): clears a class variable that holds a threading.Event(). Calculates how much time is left in the song. Corrects the song index. Sends the current song to the ‘controller’ (MVC model). Adds up all of the time that has been paused, removes that time from the current song (so amount of song that has been played already). sets classs var (coming_from_loop (not important)), and finally, calls ‘testsong’, which plays the music. I have also noticed that there are two main things affecting the odds of a crash:
1). A module I use to use ‘global keybinds’. Called ‘system_hotkey’. I noticed that the app will have a much higher crash chance if this keybind is used to call ‘pause’ versus manually clicking a button (in tkinter). The app has crashed before without using it, but it produced a slightly different error that I have forgotten to document. I’ll add it if I manage to reproduce it.
2). Change in how the ‘time elapsed’ is calculated. Before, it was a system based on the time between playing & pausing. So if you pause, then resumed 10 minutes later, it would’ve used that to calculate how much of the song is left. Now, it is a timer that counts down while playing music, and pauses when the song is paused. This significantly reduced how often the crash occured
3). Only ever occurs when it has been a long time elapsed since pause. Has never occurred within a smaller timeframe like 30 seconds.
I can’t say for sure what causes it, as it is fairly hard to reproduce, but it seems to occur because the thread is trying to do a calculation after waiting a while (like creating a Pydub.Audiosegment), during which, it fails to do so and crashes. If you want to view all of the source code, all of it is in: https://github.com/nednoodlehead/punge/blob/master/punge_main.py Line 433-896.
Any help or thoughts are greatly appreciated.
Solution ended up being something off screen. Where the collective pause-time of one track was longer than the next track, that data would ‘leak’ over and try to begin the music at after it’s total length. Guess it didnt audibly become apparent because it would overwrite that audiosegment with a new one, but if it failed to write the first one, the crash would occur.