goodboy

@k4ml did you answer the call or put it in another state **before** executing `playback`? Can you give an example dialplan that you're using.

@k4ml no I meant what is your ESL app doing after handling the `CHANNEL_PARK` event? Do you execute `session.playback('blah')` right away or do you `session.answer()` first? Also if you'd rather...

@k4ml hmm I wonder if it matter that you call `session.playback()` **after** the answer has completed. As in you **wait for** the `CHANNEL_ANSWER` to arrive first - because that's what...

@k4ml maybe I'm not sure. I know in `switchio` when we do `await sess.answer()` underneath the hood we wait for the "CHANNEL_ANSWER" event. Let me try what you're doing before...

@k4ml ok so I **was** able to replicate the situation you describe - where after `playback` the park timeout cause is used to hangup the call although I don't seem...

Further progress on this. I found that FS core is exhibiting unreliable `uuid_broadcast` behaviour and so I've deprecated its usage as part of #52. I now have `playback` after `park`...

@k4ml does the file `media.mp3` actually exist on your FS minion? I have seen that if you fail to `playback` a file the `park_timeout` will kick in. I will bet...

@k4ml yeah so looking at the core FS code more I think we'll need to propose a patch to core to make this work the way we want. I'm happy...

I have this same problem on kernel `5.11.9` ``` >>> sudo rdmsr 0x774 rdmsr: CPU 0 cannot read MSR 0x00000774 ``` I can also confirm that @kadru's hack worked. Commenting...

Lol i'm seeing this same thing. Guess i gotta downgrade again 😞 I honestly don't understand how this can break so frequently. I'm a few hair pulls from just checking...