REPL :stop command fails for overly long segments #404
Comments
|
Thanks for reporting this. I've also seen this happen from time to time and have been meaning to fix it. Will dig in when I can! |
|
Hello, I want to solve this issue but have stuck for a while. This bug doesn't always happen on my computer, but it happens more frequently as the fragment gets longer. I might be totally wrong but is it possible that this have something to do with race condition? Any thought would be appreciated. |
|
I have only a fuzzy understanding of how this might be happening. The first thing I would check is whether the "stop" message is making it to the player process. If you run Another thing to check is whether the player process is actually receiving the "stop" message and processing it right away. You can run a player process in the foreground in "very verbose" mode by running I was playing around with this just now, and here is some the of output of the player process while I ran I wasn't able to reproduce the issue this way, but maybe the issue has something to do with the Alda REPL. Maybe if there were some way that you could run a player process in the foreground and then force your REPL server to use it, and then see if you can reproduce the issue? (This might require some manual adjustments in the code to hard-code the REPL server to talk to your specific player process.) |
|
Oh yeah! I forgot that player logs are written to disk! If you run your REPL in verbose mode, you can see which player process it's sending messages to: In this case, the ID of the player process the REPL server chose is The only problem is, the logs that I really want to see are at the TRACE level, and those aren't showing up in the log file because when Alda launches player processes, they only log at the INFO level. So I think to investigate further, you would either need to:
|
|
It seems like the stop message was sent to the wrong player process when the error occurs. The score |
|
This is another try in which the error didn't occur Only one player process |
|
Although I don't why extra player process were spawned, maybe sending This seems to explain why the bug report said: "issuing an alda stop or alda shutdown command seems to be the only way to stop the playback." Because |
|
Thanks for posting these logs, they are helpful! I think you're definitely onto something here. I looked through the code for a while and I did find and fix one problem just now where we were relying on an outdated error message: 2ffdb23 But I think that's unrelated to this issue, based on the logs above. Here is my current understanding of the issue:
|
I think that would probably fix this issue, but it's not exactly the behavior that I think we want. When you run In a REPL session, we know which player is currently active, and we have the ability to stop that specific player process, so it would be better to do that. Otherwise, we would potentially stop other players that maybe the user might want to still be playing. To better illustrate my point: try starting 2 separate |
After reading the code I found three situations in which
We can disregard situation 3 because I didn't manually shut down the player. For condition 2, I think it's more likely caused by the system/hardware than by the program. I assume that's an exceptional error expected to happen rarely. Therefore, I think the most likely cause is condition 1, which means the ping signal the server sends to the player timed out. My initial thought is to make the |
|
That sounds reasonable, but the weird thing is that it should be logging "Player process unreachable" in situation 1, but I don't see that in the logs you posted above. 🤔 I have another theory that's kind of strange, but I guess it's possible. I searched for I'm thinking of these lines of code, in particular. Maybe a good next step would be to add some debug logging in all of the places where we are setting |
|
I changed the function |
|
Ooh, this is getting interesting! I think maybe the issue is in ReadPlayerStates, a function that we use to check the JSON "player state files" in the cache directory (e.g. I wrote that function in a bit of a hacky way in that it always returns a PlayerState struct for each of the state files, even if the file is in a weird state (e.g. the file was created, but not yet written to). I believe in a situation like that, we end up with an otherwise "zero value" struct, except that ID and ReadError are set. Port would be 0 in that case, which could explain the behavior that we're seeing. I suspect that this is an issue, because I've noticed that if I watch the output of There must be a better way that we could handle that. Maybe if there is a read error, we should just log it and then not add the PlayerState to the list, i.e. we ignore that player process. |
Changed function `hasPlayer` Add a new REPL command `stopall` that stops all player process
Adding check when the server.player is set, if the new player/updated state has port = 0, leave the current server.player unchanged. If there is a read error in ReadPlayerStates, return nil and the read error instead of including any player states
#404 REPL :stop command fails for overly long segments
|
I think this is fixed now in Alda 2.2.2. If anyone continues to see this behavior, please let us know! |
🐞 Bug report 🐞
Description
The REPL
:stopcommand simply fails to function when an overly long segment is played. More specifically, the:stopcommand simply fails after the first 2 seconds for certain sufficiently long segments (usually around 45 seconds or longer). Quitting the repl and issuing analda stoporalda shutdowncommand seems to be the only way to stop the playback.Steps to Reproduce
piano: c*100into the repl:stopcommand.Expected Behavior
The segment stops playing.
Actual Behavior
The segment fails to stop playing.
Environment
Windows 10, PowerShell, alda 2.0.6
The text was updated successfully, but these errors were encountered: