A2dp source disconnects bluetooth connection after some seconds

I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.

I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.

Hi
Here is what it looks like when I wait for the ESP32 to wake up first and the do the connection. Here the print “Initial sync was found” comes from my code saying that audio is now available for playing.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[I][BluetoothA2DPSource.cpp:636] bt_app_av_media_proc(): a2dp media ready checking ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:642] bt_app_av_media_proc(): a2dp media ready, starting ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:654] bt_app_av_media_proc(): a2dp media start successfully.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 1, [ec:81:93:5f:74:76]
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x5, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x5
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 5
[I][BluetoothA2DPSource.cpp:832] bt_av_hdl_avrc_ct_evt(): AVRC remote features
Initial sync was found
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.

As far as I can see the following is happening:
The method
void BluetoothA2DPSource::bt_app_av_state_connected(uint16_t event, void *param)
{
esp_a2d_cb_param_t *a2d = NULL;
switch (event) {
case ESP_A2D_CONNECTION_STATE_EVT: {
a2d = (esp_a2d_cb_param_t *)(param);
if (a2d->conn_stat.state == ESP_A2D_CONNECTION_STATE_DISCONNECTED) {
ESP_LOGI(BT_AV_TAG, "a2dp disconnected");
s_a2d_state = APP_AV_STATE_UNCONNECTED;
//esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE);
esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE);
    }
    break;
}

Is receiving a connected event with the state Disconnected.
You could try to overwrite this method and comment out this logic.
But it is likely that this will not help because I think the WONDERBOOM already stopped the connection.
Kind regards
Phil

On 28 Oct 2020, at 14:00, HVaArd<EMAIL_ADDRESS>wrote:
Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717916211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRC5N732GM7VLSDZUSTSNAIXBANCNFSM4TCHGEKA.

Hi
Infact I did try that with your older version of a2dp. And yes that did not help.
My project is only for fun, so not that serious. But I sure would have wanted the music to start playing by only turning on the speaker at any given time. And everything else would be automatic. And the ESP32 would be sleeping most of the time and power would be saved.
Br. Hannu
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 15.28
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
As far as I can see the following is happening:
The method
void BluetoothA2DPSource::bt_app_av_state_connected(uint16_t event, void *param)
{
esp_a2d_cb_param_t *a2d = NULL;
switch (event) {
case ESP_A2D_CONNECTION_STATE_EVT: {
a2d = (esp_a2d_cb_param_t *)(param);
if (a2d->conn_stat.state == ESP_A2D_CONNECTION_STATE_DISCONNECTED) {
ESP_LOGI(BT_AV_TAG, "a2dp disconnected");
s_a2d_state = APP_AV_STATE_UNCONNECTED;
//esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE);
esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE);
}
break;
}
Is receiving a connected event with the state Disconnected.
You could try to overwrite this method and comment out this logic.
But it is likely that this will not help because I think the WONDERBOOM already stopped the connection.
Kind regards
Phil

On 28 Oct 2020, at 14:00, HVaArd<EMAIL_ADDRESS>wrote:
Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717916211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRC5N732GM7VLSDZUSTSNAIXBANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717932320, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKPHOEZYEJFWGJ45MI3SNAL7PANCNFSM4TCHGEKA.

Hi Phil
Sorry to bother you but I did notice that if the red action below happens before media is started the connection drops. If the red action happens after the media the connection works.
Maybe you can give a quick advice.
I’m using the library as is, I have not modified it at all.
Br. HVa
[D][BluetoothA2DPSource.cpp:152] startRaw(): x3f402348,
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:490] bt_av_hdl_stack_evt(): bt_av_hdl_stack_evt evt 0
[I][BluetoothA2DPSource.cpp:518] bt_av_hdl_stack_evt(): Starting device discovery...
ed
[I][BluetoothA2DPSource.cpp:433] bt_app_gap_cb(): Discovery started.
[I][BluetoothA2DPSource.cpp:361] filter_inquiry_scan_result(): Scanned device: ec:81:93:5f:74:76
[I][BluetoothA2DPSource.cpp:367] filter_inquiry_scan_result(): --Class of Device: 0x240404
[I][BluetoothA2DPSource.cpp:371] filter_inquiry_scan_result(): --RSSI: -54
[I][BluetoothA2DPSource.cpp:391] filter_inquiry_scan_result(): Device discovery found: WONDERBOOM
[I][BluetoothA2DPSource.cpp:395] filter_inquiry_scan_result(): Checking name: WONDERBOOM
[I][BluetoothA2DPSource.cpp:403] filter_inquiry_scan_result(): Found a target device, address ec:81:93:5f:74:76, name WONDERBOOM
[I][BluetoothA2DPSource.cpp:406] filter_inquiry_scan_result(): Cancel device discovery ...
[I][BluetoothA2DPSource.cpp:424] bt_app_gap_cb(): Device discovery stopped.
[I][BluetoothA2DPSource.cpp:425] bt_app_gap_cb(): a2dp connecting to peer: WONDERBOOM
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[I][BluetoothA2DPSource.cpp:603] bt_app_av_state_connecting(): a2dp connected
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 1, [ec:81:93:5f:74:76]
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x5, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x5
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 5
[I][BluetoothA2DPSource.cpp:832] bt_av_hdl_avrc_ct_evt(): AVRC remote features
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[I][BluetoothA2DPSource.cpp:636] bt_app_av_media_proc(): a2dp media ready checking ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:642] bt_app_av_media_proc(): a2dp media ready, starting ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:654] bt_app_av_media_proc(): a2dp media start successfully.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
From: Phil Schatzmann<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 15.28
To: pschatzmann/ESP32-A2DP<EMAIL_ADDRESS>Cc: HVaArd<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
As far as I can see the following is happening:
The method
void BluetoothA2DPSource::bt_app_av_state_connected(uint16_t event, void *param)
{
esp_a2d_cb_param_t *a2d = NULL;
switch (event) {
case ESP_A2D_CONNECTION_STATE_EVT: {
a2d = (esp_a2d_cb_param_t *)(param);
if (a2d->conn_stat.state == ESP_A2D_CONNECTION_STATE_DISCONNECTED) {
ESP_LOGI(BT_AV_TAG, "a2dp disconnected");
s_a2d_state = APP_AV_STATE_UNCONNECTED;
//esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE);
esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE);
}
break;
}
Is receiving a connected event with the state Disconnected.
You could try to overwrite this method and comment out this logic.
But it is likely that this will not help because I think the WONDERBOOM already stopped the connection.
Kind regards
Phil

On 28 Oct 2020, at 14:00, HVaArd<EMAIL_ADDRESS>wrote:
Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717916211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRC5N732GM7VLSDZUSTSNAIXBANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717932320, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKPHOEZYEJFWGJ45MI3SNAL7PANCNFSM4TCHGEKA.

Maybe it might help if you add some delays() in your overall logic ?
You could also check if the start() was successful by checking with isConnected() and if not retry again ?

On 29 Oct 2020, at 16:15, HVaArd<EMAIL_ADDRESS>wrote:
Hi Phil
Sorry to bother you but I did notice that if the red action below happens before media is started the connection drops. If the red action happens after the media the connection works.
Maybe you can give a quick advice.
I’m using the library as is, I have not modified it at all.
Br. HVa
[D][BluetoothA2DPSource.cpp:152] startRaw(): x3f402348,
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:490] bt_av_hdl_stack_evt(): bt_av_hdl_stack_evt evt 0
[I][BluetoothA2DPSource.cpp:518] bt_av_hdl_stack_evt(): Starting device discovery...
ed
[I][BluetoothA2DPSource.cpp:433] bt_app_gap_cb(): Discovery started.
[I][BluetoothA2DPSource.cpp:361] filter_inquiry_scan_result(): Scanned device: ec:81:93:5f:74:76
[I][BluetoothA2DPSource.cpp:367] filter_inquiry_scan_result(): --Class of Device: 0x240404
[I][BluetoothA2DPSource.cpp:371] filter_inquiry_scan_result(): --RSSI: -54
[I][BluetoothA2DPSource.cpp:391] filter_inquiry_scan_result(): Device discovery found: WONDERBOOM
[I][BluetoothA2DPSource.cpp:395] filter_inquiry_scan_result(): Checking name: WONDERBOOM
[I][BluetoothA2DPSource.cpp:403] filter_inquiry_scan_result(): Found a target device, address ec:81:93:5f:74:76, name WONDERBOOM
[I][BluetoothA2DPSource.cpp:406] filter_inquiry_scan_result(): Cancel device discovery ...
[I][BluetoothA2DPSource.cpp:424] bt_app_gap_cb(): Device discovery stopped.
[I][BluetoothA2DPSource.cpp:425] bt_app_gap_cb(): a2dp connecting to peer: WONDERBOOM
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[I][BluetoothA2DPSource.cpp:603] bt_app_av_state_connecting(): a2dp connected
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 1, [ec:81:93:5f:74:76]
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x5, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x5
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 5
[I][BluetoothA2DPSource.cpp:832] bt_av_hdl_avrc_ct_evt(): AVRC remote features
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[I][BluetoothA2DPSource.cpp:636] bt_app_av_media_proc(): a2dp media ready checking ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:642] bt_app_av_media_proc(): a2dp media ready, starting ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:654] bt_app_av_media_proc(): a2dp media start successfully.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
From: Phil Schatzmann<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 15.28
To: pschatzmann/ESP32-A2DP<EMAIL_ADDRESS>Cc: HVaArd<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
As far as I can see the following is happening:
The method
void BluetoothA2DPSource::bt_app_av_state_connected(uint16_t event, void *param)
{
esp_a2d_cb_param_t *a2d = NULL;
switch (event) {
case ESP_A2D_CONNECTION_STATE_EVT: {
a2d = (esp_a2d_cb_param_t *)(param);
if (a2d->conn_stat.state == ESP_A2D_CONNECTION_STATE_DISCONNECTED) {
ESP_LOGI(BT_AV_TAG, "a2dp disconnected");
s_a2d_state = APP_AV_STATE_UNCONNECTED;
//esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE);
esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE);
}
break;
}
Is receiving a connected event with the state Disconnected.
You could try to overwrite this method and comment out this logic.
But it is likely that this will not help because I think the WONDERBOOM already stopped the connection.
Kind regards
Phil

On 28 Oct 2020, at 14:00, HVaArd<EMAIL_ADDRESS>wrote:
Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717916211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRC5N732GM7VLSDZUSTSNAIXBANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717932320, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKPHOEZYEJFWGJ45MI3SNAL7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi
Thanks. I will try for sure.
Br. HVa
From: Phil Schatzmann<EMAIL_ADDRESS>Sent: Thursday, 29 October 2020 18.05
To: pschatzmann/ESP32-A2DP<EMAIL_ADDRESS>Cc: HVaArd<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
Maybe it might help if you add some delays() in your overall logic ?
You could also check if the start() was successful by checking with isConnected() and if not retry again ?

On 29 Oct 2020, at 16:15, HVaArd<EMAIL_ADDRESS>wrote:
Hi Phil
Sorry to bother you but I did notice that if the red action below happens before media is started the connection drops. If the red action happens after the media the connection works.
Maybe you can give a quick advice.
I’m using the library as is, I have not modified it at all.
Br. HVa
[D][BluetoothA2DPSource.cpp:152] startRaw(): x3f402348,
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:490] bt_av_hdl_stack_evt(): bt_av_hdl_stack_evt evt 0
[I][BluetoothA2DPSource.cpp:518] bt_av_hdl_stack_evt(): Starting device discovery...
ed
[I][BluetoothA2DPSource.cpp:433] bt_app_gap_cb(): Discovery started.
[I][BluetoothA2DPSource.cpp:361] filter_inquiry_scan_result(): Scanned device: ec:81:93:5f:74:76
[I][BluetoothA2DPSource.cpp:367] filter_inquiry_scan_result(): --Class of Device: 0x240404
[I][BluetoothA2DPSource.cpp:371] filter_inquiry_scan_result(): --RSSI: -54
[I][BluetoothA2DPSource.cpp:391] filter_inquiry_scan_result(): Device discovery found: WONDERBOOM
[I][BluetoothA2DPSource.cpp:395] filter_inquiry_scan_result(): Checking name: WONDERBOOM
[I][BluetoothA2DPSource.cpp:403] filter_inquiry_scan_result(): Found a target device, address ec:81:93:5f:74:76, name WONDERBOOM
[I][BluetoothA2DPSource.cpp:406] filter_inquiry_scan_result(): Cancel device discovery ...
[I][BluetoothA2DPSource.cpp:424] bt_app_gap_cb(): Device discovery stopped.
[I][BluetoothA2DPSource.cpp:425] bt_app_gap_cb(): a2dp connecting to peer: WONDERBOOM
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[I][BluetoothA2DPSource.cpp:603] bt_app_av_state_connecting(): a2dp connected
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 1, [ec:81:93:5f:74:76]
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x5, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x5
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 5
[I][BluetoothA2DPSource.cpp:832] bt_av_hdl_avrc_ct_evt(): AVRC remote features
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[I][BluetoothA2DPSource.cpp:636] bt_app_av_media_proc(): a2dp media ready checking ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:642] bt_app_av_media_proc(): a2dp media ready, starting ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:654] bt_app_av_media_proc(): a2dp media start successfully.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
From: Phil Schatzmann<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 15.28
To: pschatzmann/ESP32-A2DP<EMAIL_ADDRESS>Cc: HVaArd<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
As far as I can see the following is happening:
The method
void BluetoothA2DPSource::bt_app_av_state_connected(uint16_t event, void *param)
{
esp_a2d_cb_param_t *a2d = NULL;
switch (event) {
case ESP_A2D_CONNECTION_STATE_EVT: {
a2d = (esp_a2d_cb_param_t *)(param);
if (a2d->conn_stat.state == ESP_A2D_CONNECTION_STATE_DISCONNECTED) {
ESP_LOGI(BT_AV_TAG, "a2dp disconnected");
s_a2d_state = APP_AV_STATE_UNCONNECTED;
//esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE);
esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE);
}
break;
}
Is receiving a connected event with the state Disconnected.
You could try to overwrite this method and comment out this logic.
But it is likely that this will not help because I think the WONDERBOOM already stopped the connection.
Kind regards
Phil

On 28 Oct 2020, at 14:00, HVaArd<EMAIL_ADDRESS>wrote:
Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717916211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRC5N732GM7VLSDZUSTSNAIXBANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717932320, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKPHOEZYEJFWGJ45MI3SNAL7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-718854089, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKOCINIHRYRXQ7W2MKTSNGHEHANCNFSM4TCHGEKA.

Hi Phil
I got it working, but have not been testing it yet thoroughly.
I did not add delay, I made things faster.
I changed the heart beat event timer from 10 seconds to 2 and now procedures happen in right order. I suppose I need to check what would be the best value for my application. Maybe something between 2 and ...
Thanks for your help.
Br. HVa
From: Phil Schatzmann<EMAIL_ADDRESS>Sent: Thursday, 29 October 2020 18.05
To: pschatzmann/ESP32-A2DP<EMAIL_ADDRESS>Cc: HVaArd<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
Maybe it might help if you add some delays() in your overall logic ?
You could also check if the start() was successful by checking with isConnected() and if not retry again ?

On 29 Oct 2020, at 16:15, HVaArd<EMAIL_ADDRESS>wrote:
Hi Phil
Sorry to bother you but I did notice that if the red action below happens before media is started the connection drops. If the red action happens after the media the connection works.
Maybe you can give a quick advice.
I’m using the library as is, I have not modified it at all.
Br. HVa
[D][BluetoothA2DPSource.cpp:152] startRaw(): x3f402348,
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:490] bt_av_hdl_stack_evt(): bt_av_hdl_stack_evt evt 0
[I][BluetoothA2DPSource.cpp:518] bt_av_hdl_stack_evt(): Starting device discovery...
ed
[I][BluetoothA2DPSource.cpp:433] bt_app_gap_cb(): Discovery started.
[I][BluetoothA2DPSource.cpp:361] filter_inquiry_scan_result(): Scanned device: ec:81:93:5f:74:76
[I][BluetoothA2DPSource.cpp:367] filter_inquiry_scan_result(): --Class of Device: 0x240404
[I][BluetoothA2DPSource.cpp:371] filter_inquiry_scan_result(): --RSSI: -54
[I][BluetoothA2DPSource.cpp:391] filter_inquiry_scan_result(): Device discovery found: WONDERBOOM
[I][BluetoothA2DPSource.cpp:395] filter_inquiry_scan_result(): Checking name: WONDERBOOM
[I][BluetoothA2DPSource.cpp:403] filter_inquiry_scan_result(): Found a target device, address ec:81:93:5f:74:76, name WONDERBOOM
[I][BluetoothA2DPSource.cpp:406] filter_inquiry_scan_result(): Cancel device discovery ...
[I][BluetoothA2DPSource.cpp:424] bt_app_gap_cb(): Device discovery stopped.
[I][BluetoothA2DPSource.cpp:425] bt_app_gap_cb(): a2dp connecting to peer: WONDERBOOM
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 4, evt 0x0
[I][BluetoothA2DPSource.cpp:603] bt_app_av_state_connecting(): a2dp connected
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 1, [ec:81:93:5f:74:76]
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x5, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x5
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 5
[I][BluetoothA2DPSource.cpp:832] bt_av_hdl_avrc_ct_evt(): AVRC remote features
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[I][BluetoothA2DPSource.cpp:636] bt_app_av_media_proc(): a2dp media ready checking ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:642] bt_app_av_media_proc(): a2dp media ready, starting ...
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x3, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x3
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x3
[I][BluetoothA2DPSource.cpp:654] bt_app_av_media_proc(): a2dp media start successfully.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
From: Phil Schatzmann<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 15.28
To: pschatzmann/ESP32-A2DP<EMAIL_ADDRESS>Cc: HVaArd<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
As far as I can see the following is happening:
The method
void BluetoothA2DPSource::bt_app_av_state_connected(uint16_t event, void *param)
{
esp_a2d_cb_param_t *a2d = NULL;
switch (event) {
case ESP_A2D_CONNECTION_STATE_EVT: {
a2d = (esp_a2d_cb_param_t *)(param);
if (a2d->conn_stat.state == ESP_A2D_CONNECTION_STATE_DISCONNECTED) {
ESP_LOGI(BT_AV_TAG, "a2dp disconnected");
s_a2d_state = APP_AV_STATE_UNCONNECTED;
//esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE);
esp_bt_gap_set_scan_mode(ESP_BT_SCAN_MODE_CONNECTABLE_DISCOVERABLE);
}
break;
}
Is receiving a connected event with the state Disconnected.
You could try to overwrite this method and comment out this logic.
But it is likely that this will not help because I think the WONDERBOOM already stopped the connection.
Kind regards
Phil

On 28 Oct 2020, at 14:00, HVaArd<EMAIL_ADDRESS>wrote:
Hi
Thanks for quick reply.
Here is what was printed before the disconnect. The time stamp print (Connection to BT lost at: 38921
) comes from my code and that is the time when the disconnection happened.
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0xff00, param len 0
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0xff00
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0xff00
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x1, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x1
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x1
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 16
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[I][BluetoothA2DPSource.cpp:550] bt_app_av_sm_hdlr(): bt_app_av_sm_hdlr state 5, evt 0x0
[I][BluetoothA2DPSource.cpp:703] bt_app_av_state_connected(): a2dp disconnected
Connection to BT lost at: 38921
[D][BluetoothA2DPSource.cpp:221] bt_app_work_dispatch(): bt_app_work_dispatch event 0x0, param len 12
[D][BluetoothA2DPSource.cpp:271] bt_app_task_handler(): bt_app_task_handler, sig 0x1, 0x0
[D][BluetoothA2DPSource.cpp:799] bt_av_hdl_avrc_ct_evt(): bt_av_hdl_avrc_ct_evt evt 0
[I][BluetoothA2DPSource.cpp:805] bt_av_hdl_avrc_ct_evt(): AVRC conn_state evt: state 0, [ec:81:93:5f:74:76]
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Phil<EMAIL_ADDRESS>Sent: Wednesday, 28 October 2020 14.45
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [pschatzmann/ESP32-A2DP] A2dp source disconnects bluetooth connection after some seconds (#9)
I propose to set the Debug level to ‘Verbose' and check the console.
That might give you a hint why it is disconnecting...

On 28 Oct 2020, at 13:01, HVaArd<EMAIL_ADDRESS>wrote:
I'm using Ultimate Ears WONDERBOOM with a2dp source. My plan is to prepare the WonderBoom (turn power on and press the button on top of it to pair) then wait for ESP32 to wake-up from deep sleep. The ESP32 wakes up when a timer expires and a2dp source finds the WonderBoom fine, connects and the music starts playing. But after some seconds well closer to 30 the bluetooth connection drops. I suppose it is somehow related to pairing or a2dp source finding the WonderBoom "too early".
If I wait for the ESP32 to wake up and then turn on the WonderBoom and press the pairing button the connection stays on without problems.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRA3NJAEKFF5O6P3J6DSNABZFANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717908751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKNEYBUZFTSYHXS3NRDSNAG7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717916211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP3RRC5N732GM7VLSDZUSTSNAIXBANCNFSM4TCHGEKA.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-717932320, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKPHOEZYEJFWGJ45MI3SNAL7PANCNFSM4TCHGEKA.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pschatzmann/ESP32-A2DP/issues/9#issuecomment-718854089, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARROHKOCINIHRYRXQ7W2MKTSNGHEHANCNFSM4TCHGEKA.


Change default verticalOrigin from glyph height to hhea.ascender?

When verticalOrigin is not set, OutlineCompiler currently uses the glyph height as a fallback value:
https://github.com/googlei18n/ufo2ft/blob/ed1c03804bfedb2cba621c61652dee6dece43ac8/Lib/ufo2ft/outlineCompiler.py#L38-L45
However, it seems more reasonable to use hhea.ascender than the glyph height. This is a very common setting especially in CJK fonts.

Ascender sounds wrong. I would have expected either ascender+descender. No?

The height would be ascender+abs(descender), but for the vertical origin taking the ascender as a fallback makes sense.

Right. My bad. Was thinking about vertical advance.


Incorrect array(1) display

fb::log(array(
    '1' => array(1)
));

prints just array('1' => '1') if you click on it in firebug console.

Seems to work with latest extension.


Off by one rendering of the current text in the prompt

Environment
Windows build number: Version 10.0.19042.685
Windows Terminal version (if applicable): 1.4.3243.0

Steps to reproduce
I wasn't able to reproduce at will but I've seen this a few times
Expected behavior
Things work as expected
Actual behavior
Current prompt text is rendered one line below where it's supposed to be

I have no idea how to investigate or reproduce this, but I'm filing this to raise awareness that the issue exists, and will probably be very difficult to hunt down.
If you have any tips on the steps I could do to debug this next time I see this, I'd be happy to try them out.

Shockingly, I think we've seen this before. #6546 is tracking just about the same bug, and some other related ones are in #5800. I get something like this every so often, but it's terribly hard to track down.
If you had consistent repro steps, that would probably be the most useful thing. Unfortunately, this kind of bug is really hard to debug once it's already happened - it's usually best to get a trace of it starting to happen. However, without consistent repro steps, it's incredibly hard to get such a trace 😕
I'm gonna close this as a /dupe of #6546, but please hop on that thread if you do find a consistent repro!

Shockingly, I think we've seen this before. #6546 is tracking just about the same bug, and some other related ones are in #5800. I get something like this every so often, but it's terribly hard to track down.
If you had consistent repro steps, that would probably be the most useful thing. Unfortunately, this kind of bug is really hard to debug once it's already happened - it's usually best to get a trace of it starting to happen. However, without consistent repro steps, it's incredibly hard to get such a trace 😕
I'm gonna close this as a /dupe of #6546, but please hop on that thread if you do find a consistent repro!


[Popover] Blinks on open in latest Safari (macOS and iOS)

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Popover and components which use it (such as Select) flash when opened or closed. They seem to briefly appear to be fully open, and then begin their transition in (or out).
Expected behavior 🤔
Popovers and selects should open/close normally as they do in Chrome and Firefox.
Steps to reproduce 🕹
Steps:

Visit https://mui.com/components/popover/ or https://mui.com/components/selects/ or any website using the latest version of MUI components that has selects or popovers.
Open any select or popover and observe the behavior.

Context 🔦
This only seems to have become an issue with the very latest iOS update and Safari update.
Your environment 🌎

Safari v15.4 on macOS Monterey (v12.3)
Safari on iOS v15.4

I am having exactly the same issue on iOS safari and on Mac Safari. I'm also on  macOS 12.3 and iOS 15.4. Doesn't occur in Chrome on macOS. Happens on tooltips and Menu component as well.
Here's a quick recording from the Material UI docs popover page: https://imgur.com/a/zR5Eeyl

Duplicate of #31380


Generics: Function's template param inferred in unexpected way

TypeScript Version:  2.6.2
Code
// visitor interface for visiting possible values of a string literal type
type StringVisitor<S extends string> = {
    [P in S]: (value: P) => void;
}

function visitString<S extends string>(value: S, visitor: StringVisitor<S>): void {
    visitor[value](value);
}

// visitor interface for visiting possible values of a string literal type, or null/undefined
type NullableStringVisitor<S extends string> = {
    handleNullOrUndefined: (value: null | undefined) => void;
} & StringVisitor<S>

function visitNullableString<S extends string>(
    value: S | null | undefined,
    visitor: NullableStringVisitor<S>
): void {
    if (value == null) {
        visitor.handleNullOrUndefined(value);
    } else {
        visitString(value, visitor);
    }
}

// example string literal type
type RGB = "red" | "green" | "blue";

function getRGBValue(): RGB | null {
    return "green";
}

// example shared handler used for multiple values in the RGB visitor implementation
function handleUnsupportedValue(value: RGB | null | undefined): void {
    alert('Unsupported value: ${value}');
}

visitNullableString(getRGBValue(), {
    // Compiler error caused here:
    // Types of property 'handleNullOrUndefined' are incompatible.
    // Type '(value: "red" | "green" | "blue" | null | undefined) => void' is not assignable
    // to type '(value: "handleNullOrUndefined") => void'
    handleNullOrUndefined: handleUnsupportedValue,

    "red": handleUnsupportedValue,

    "green": () => {
        alert("green!");
    },

    "blue": () => {
        alert("blue!");
    }
});

Expected behavior:
In the call to visitNullableString, type S should be directly inferred from param value as "red" | "green" | "blue", and the expected type of handleNullOrUndefined on visitor should be (value: null | undefined) => void, because visitor should be of type NullableStringVisitor<"red" | "green" | "blue">.
Actual behavior:
Type S is indirectly inferred from param visitor as "red" | "green" | "blue" | "handleNullOrUndefined", based on the names of all properties in the visitor implementation. The compiler then complains about incompatible types on handleNullOrUndefined, because the implementation does not accept the string literal type "handleNullOrUndefined".
Workaround
If I explicitly provide the template param, then it works as desired:
visitNullableString<RGB>(getRGBValue(), {
    // No compiler error
    handleNullOrUndefined: handleUnsupportedValue,

    "red": handleUnsupportedValue,

    "green": () => {
        alert("green!");
    },

    "blue": () => {
        alert("blue!");
    }
});

Not sure what you're trying to accomplish, but does this help?

This could be solved by either subtraction types (#4183), or noninferential type parameters (#14829). As is, this is the intended behavior because the intersection type is a lower-priority inference site than the object literal's.

@RyanCavanaugh Could you provide an example of how I would use type subtraction to get the behavior I want? This is my initial guess:
function visitNullableString<S extends (string - "handleNullOrUndefined")>(
    value: S | null | undefined,
    visitor: NullableStringVisitor<S>
): void

The non-inferred type parameter solution is more obvious:
function visitNullableString<S extends string>(
    value: S | null | undefined,
    visitor: NullableStringVisitor<NoInfer<S>>
): void

SOLUTION!!! (hack???)
type NoInfer<T> = T & {[K in keyof T]: T[K]};

function visitNullableString<S extends string>(
    value: S | null | undefined,
    visitor: NullableStringVisitor<NoInfer<S>>
): void

Thanks to this comment for the NoInfer<T> implementation: https://github.com/Microsoft/TypeScript/issues/14829#issuecomment-322267089

Follow up on the previous hack: it's good enough to give me something functional for now, but it would be much more useful if I could prevent inferring the type of visitor altogether, and instead force the type of visitor to be determined entirely based on the inferred type S from the value param:
function visitNullableString<S extends string>(
    value: S | null | undefined,
    visitor: NoInfer<NullableStringVisitor<S>>
): void

However, the hack NoInfer<T> implementation from my previous comment is very limited in that it can only prevent inference on a particular usage of a template param that is used more than once in inferrable ways (in this case, type S).
This limitation is preventing me from overloading a single visitString method that handles different combinations of value types (S, S | null, S | undefined, S | null | undefined), and appropriately corresponding variations of StringVisitor types that include handler methods for null and/or undefined, based on whether the type of the value param includes null and/or undefined.
Technically, I can overload the method as desired, and it works when correct params are passed in. But when incorrect params are passed in (visitor missing a handler for one of the string values, or for null/undefined), then the compiler error messages are very misleading because it ends up inferring the type of the visitor incorrectly, completely independent of the type of value, telling the developer that their visitor is missing a property that is unnecessary based on the type of value.
function visitString<S extends string>(
    value: S,
    visitor: StringVisitor<NoInfer<S>>
): void;
function visitString<S extends string>(
    value: S | null | undefined,
    // When a call to visitString is made with incompatible types for 'value' and visitor',
    // the compiler seems to always default to assuming this last overloaded signature
    // which can cause an error to complain about missing"handleNullOrUndefined"
    // property even when the value of `value` passed in can never be null/undefined
    visitor: NullableStringVisitor<NoInfer<S>>
): void;

For now, the best I can reasonably do is a separate method for each combination of null/undefined. The result is helpful error messages when a visitor is not fully implemented with all necessary handlers, but the developer must explicitly choose the correct variation of visitString (e.g., visitStringWithNull vs visitStringWithNullOrUndefined, etc.) to match the type of the value they pass in.
Here's a full example in the Playground with separate visit methods (enable ALL compiler options). Let me know if you'd also like me to setup an example with my attempt to overload the visitString method, showing how the compiler errors are misleading compared to my intentions.

Or maybe my new issue is more about function overloading rather than type param inference?

Nevermind on my previous long comment. I've figured out that it's an issue with compile error reporting on overloaded functions. Creating a new issue...

My final solution is to split things up so the compiler only has to deal with inferring/enforcing the type of one parameter at a time.
My original goal was to have a single overloaded method. Example:
function visitString<S extends string, R>(value: S, visitor: StringVisitor<S, R>): R;
function visitString<S extends string, R>(value: S | null, visitor: StringVisitorWithNull<S, R>): R;

The goal being that if a potentially null value is passed in, then a corresponding appropriate visitor that can handle null must be supplied.
This approach had 3 distinct issues:

The undesired type inference described in this issue.
The confusing compiler error when none of the overloaded signatures were applicable (#20697)
The inability to allow the compiler to infer type S while explicitly providing type R to clearly specify intent for the return type (https://github.com/Microsoft/TypeScript/issues/10571#issuecomment-348675440)

In my final solution, the signature(s) of my method looks more like this:
declare function visitString<S extends string>(value: S, visitor): StringVisitee<S> ;
declare function visitString<S extends string>(value: S | null): StringVisiteeWithNull<S>;

And the StringVisitee classes are simple wrappers around the value to be visited, and provides a generic method that actually accepts the visitor:
declare class StringVisitee<S extends string> {
    public with<R>(visitor: StringVisitor<S, R>): R;
}
declare class StringVisiteeWithNull<S extends string> {
    public with<R>(visitor: StringVisitorWithNull<S, R>): R;
}

And the complete usage now looks like:
declare x: RGB;

visitString(x).with({
    "red": () => { alert("RED!"); },
    "green": () => { alert("GREEN!"); },
    "blue": () => { alert("BLUE!"); },
});

This solves all 3 problems I had:

The visitString method now only has to infer the type of the value being visited (specifically, whether it can be null or not), which dictates the kind of StringVisitee returned, which in turn accepts only the correct kind of visitor to its with method - no inference on the visitor any more (except for the return type portion of it).
If you pass a mismatch of params to visitString and with, it is now very clear that the type of value passed to visitString drives the type of visitor expected by the with method, so you get very clear error messages about what's wrong with your visitor. The visitor is now strictly enforced to have the handleNull method if, and only if, the type of value may be null.
The with method has only one type param: the return type. So you can now explicitly provide the desired return type to help enforce correct implementations.

Example of explicit return type:
declare x: RGB;

const result = visitString(x).with<number>({
    "red": () => {
        return 1;
    },
    "green": () => {
        return 2;
    },
    "blue": () => {
        // very clear compiler error that this method returns the wrong type
        return "WRONG!";
    },
});

I implemented a full example in the playground (must enable strictNullChecks!)

In case anyone comes across this and is interested in this string visitor pattern I've been trying to create, I have now fully documented and tested it and put it on github: https://github.com/UselessPickles/ts-string-visitor
And published it as an npm package: https://www.npmjs.com/package/ts-string-visitor


CORS issue

Hey,
trying this service out and getting the following:
Access to fetch at 'https://xxxxxxxx.pockethost.io/api/collections/import' from origin 'chrome-extension://jdaenokienchhpjfcipjjekeeeebpnge' has been blocked by CORS policy: Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.

any idea how to resolve this?

@VinceG Thank you for the report. It should be resolved now, so I'm closing this issue. But if you continue to have trouble, please feel encouraged to re-open this again.

Having CORS issues with realtime events.
Access to fetch at 'https://***.pockethost.io/api/realtime' from origin 'https://***.com' has been blocked by CORS policy: Request header field cache-control is not allowed by Access-Control-Allow-Headers in preflight response.

I have added the Application URL set in the settings, but doesn't seem to make a difference.

It's finally locally. But in production I'm getting cross domain CORS errors.

Why is it fetching pockethost.io when you're at ***.com? Do we have a hard-coded pockethost.io in the code somewhere?

I am kind having the same issue. I am connecting to pockethost from my Vue
application. Running locally works fine when pointing to pockethost.
However, when I deploy the application on Render.com, I am having CORS
issues.
What setting should I configure to take care of this?
KR
Moses
On Tue 7. Mar 2023 at 01:11, keith @.***> wrote:

Having CORS issues with realtime events.
Access to fetch at 'https://.pockethost.io/api/realtime' from origin 'https://.com' has been blocked by CORS policy: Request header field cache-control is not allowed by Access-Control-Allow-Headers in preflight response.
I have added the Application URL set in the settings, but doesn't seem to
make a difference.
—
Reply to this email directly, view it on GitHub
https://github.com/benallfree/pockethost/issues/149#issuecomment-1457250857,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZXPX32LB4HCDIFZ2OW2N3W2Z4MNANCNFSM6AAAAAATKEW7CY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Sent from Gmail Mobile

@kilokeith I see, there is a cache-control header being requested in preflight. I've made an adjustment, can you please try again?

@algone I need more info on exactly what CORS error is being produced. Can you send more details?

@kilokeith I see, there is a cache-control header being requested in preflight. I've made an adjustment, can you please try again?

That did it! Thanks so much for getting on that so quick. 🍻


Bug: Cannot use view filter on array values

When trying to use a custom view Filter for array values nothing happens.
Affected module(s)
View\Parser
Expected behavior, and steps to reproduce if appropriate
{foo|bar} should always lead to the call of the filter bar no matter what type foo is. Right now nothing happens since $replace will not contain {foo|bar}.

Sorry, but Parser class is designed to work only with associative arrays. And filters work only for a single variable not array.
We are always open to a PRs though.


OSS-add-community-tested-versions

Request from Reza to add a community-tested page

OSS only
Casey approved trial, Reza will manage community PRs

@bmckercher123 thank you!


Fix small Bpm parser issue

fix: When calculate data Length in BmpParser returns 0 it then thinks it is also a  TLV container. Fixed by adding else to if.

i think we need only remove byte[] bmpData; and add the var -> var bmpData = data.Slice(currentPosition, dataLength).ToArray();

I do not exactly understand how that would solve the issue maby I dont understand where you want to add it. I had the problem that in my message there is a section "22F0F0" and this leads to the result of CalculateDatatLength 0 which is correct. But the it assigns the 0 to dataLenth which the leads to accessing the block where the TLV container is read altough it is not a TLV container.

Can they perhaps provide more information about this problem? What kind of command was called?

I tried to parse a Status Information response with the StatusInformationParser backtracked the problem to this section of the code.
The message is:
040F44276C040000000012004909780C1133390D081722F0F00B000000196029525002958BF0F100 with then a tlv container but the problem happens with the bold section

I will be looking at the Issue in the next few days. Can you give me some information about the terminal and the payment provider so that we know where these problems occur?

The terminal Feig Electronics cvend box+ and the payment provider is lavego.

@nikolaikarner The new version is now available, thanks


Use Jep and JPype together

Heya! Is it possible to use Jep and JPype together with a single JVM process? Jep makes embedding Python in Java trivial, but it would be nice to be able to use JPype within a Jep-spawned Python interpreter as it would simplify things such as accessing Java classes

It is possible with some modifications.    In android we use an existing JVM to run JPype.   It is just a matter to some patching the startJVM and the C++ to match the android path to use an existing JVM rather than spawn a fresh copy.

Oh neat, how hard do you think it'd be for someone with minimal knowledge of C++ to do?

It is possible though you would need to make a few changes.
In line 69 for jpype/__init__.py you can see that it will run embedded if it finds bootstrap in the module.
So to activate it you will need change 2 ifdefs in native/python/pyjp_module.cpp lines 664 and 648.  Those need to changes such rather than triggering on ANDROID it would need to trigger on #define EMBEDDED which would need to be added to native/common/include/jpype.h.   Last there is one line in native/common/jp_context.cpp  where it sets embedded variable (which prevents JPype from terminating a running JVM), line 222.
So just a few minor changes, recompile and it would be possible to test how well they interact.
However, that is half the battle.  That lets you start JEP, import JPype and have it running.  But JPype and JEP resources are very different.   To make them interact you would need to come up with a patch in JEP and JPype which would give you a convert function.   Otherwise, JPype resources would be treated as Python objects by JEP.   Certainly doable, but definitely more advanced as you need to know how to write enough C++ to get the jobject instance from one kit, turn it into a capsule and then pass it to JEP which would have to recognize it and unpacking it.   (They don't need to share a common structure as the capsules are defined by name).     With those two patches you would be able to use both kits at the same time.
The advanced stuff for an expert like me I would guess 3 days of effort.  Much more if you don't know C++, Python API, and JNI.


Update CI to test Python 3.12 for dbt-semantic-interfaces

In order to support Python 3.12 we need to ensure it is fully
tested on the local package, and that we can build and run all
of our tests as expected.
This updates the matrix test accordingly. Note no dependency
adjustment is required, as this package is already open-ended
with respect to maximum supported Python version. For now, we
leave it that way.

Lgtm - should we add a line here calling out 3.12?


Ticker Documentation

Hello,
At https://github.com/CreateJS/EaselJS/blob/master/src/createjs/utils/Ticker.js#L181
Minor doc change to do
When the ticker is paused, all listeners will still receive a tick event, but the paused property of the event will be false true.

This is working as intended. Cheers.

if the ticker is paused then
Ticker.paused = true
If an event is dispatched when the ticker is paused, it must have the property paused with the same value : true and not false as the documentation says.
Have I misunderstood something ?

Ah, I see. We can check it out. Sorry!

Thanks! I pushed an updated Ticker class to GitHub (EaselJS and TweenJS) with this fix, and a few other minor doc updates.


Docker only starting 1 projection

Hi,
When installing the proophessor-do docker failed to launch more than 1 projection. Whichever projection is started first goes up fine, but any subsequent gives the error:
standard_init_linux.go:190: exec user process caused "no such file or directory"

I can stop the running one and start a different one which works, but then still I can't start any of the remaining two.
There seems to be some issue with the entrypoint being inaccessible. If I copy the entrypoint script (wait_for_mysql.sh) three times and update docker-compose.yml so all three projections use their own wait_for_mysql.sh they all launch fine.
Running on Windows 10 with Docker 18.03.1-ce-win65.

@SunMar Thx, for reporting!
@sandrokeil What do you think? Looks like a windows issue?

Maybe it's a windows issue. Wanny try Linux? :D Depending on this comment try to clone the repo with git@github.com:prooph/proophessor-do.git --config core.autocrlf=input. Maybe it's the windows line ending.
If not, I'm not sure how to fix it. If you search for this error, there are different problems/solutions.

No activity, closing.

Ok, I seem to have found the issue here. When adding files inside Windows Subsystem for Linux (WSL), the case sensitive flag is set for Linux compatibility. When that case sensitive flag is enabled, for some reason two processes can't access the same file anymore. So the issue isn't just Windows, it's the combination of using WSL with Docker in Windows.
Since this is a Windows/Docker issue it can remain closed though, just adding this update here so if someone happens to come across this ticket they know the exact cause.


ToggleButton icon is not matched with its text

The icon for the sample of toggle button in demo page doesn't match with the text; if it is muted and we aim to unmute then the icon should display muted state.
By the way these two buttons have the same reaction when I click on them (i.e., when I click on one the other changes a well), is this OK?

this behavior is intended in this sample. but I agree that this is a little confusing. we need to improve this example at least by adding a description to explain the situation.


fix(useClient): track all clients and update clients on runSandpack

What kind of change does this pull request introduce?
A proposed solution for https://github.com/codesandbox/sandpack/issues/918. That bug is about how the runSandpack function doesn't work for the static template. While working through determining the root cause for that problem, I ran into a few other problems around how we register bundlers.
Preregistered iFrame Object
When we register a bundler it's only put into the preregisteredIframes object if the useClient status isn't running. The problem is that runSandpack only reruns clients that are in the preregisteredIframes object, which means if you register a client after things have started up, they won't get picked up by the runSandpack function.
Static Template runSandpack function
When creating a runtime client, there's a global listener that calls updateSandbox after the client has initialized. This call to updateSandbox is how a newly created client displays its view when runSandpack is invoked. The reason the static template isn't working is that we don't have a step to call updateSandbox. I've added this step to the static template constructor and things seem to work.
One thing to note is that this means in a situation where you have autorun set to true, the updateSandbox function will initially be called twice (once from the static template constructor and once from the useClient's watchFileChanges effect). While this isn't ideal, this is currently how the runtime client works as well, so there's consistency.
Leaking Listeners
This one is harder to prove, but if the useClient hook is in a running state and you register a new bundler, the code immediately calls createClient without cleaning up any existing clients for a given client ID. This means any stale listeners will still be present and won't be cleaned up.
Examples
I made a Code Sandbox that better outlines the problems mentioned above. Verifying the leaking listeners is harder to show in a Code Sandbox, but to verify that problem, you can:

Copy the code from the Sandbox
Create a story in StoryBook with that code (template: vanilla and autorun: true)
Add a console.log statement to the first line of the runtime client global listener
Every time you press Register Bundler, you should notice that the number of console logs grows because old listeners aren't getting cleaned up

What is the current behavior?
Everything that is mentioned above.

What is the new behavior?

static template calls updateSandbox as part of the constructor (runSandpack should work now)
Rename preregisteredIframes to registeredIframes and track every client that's registered. This way when runSandpack is called, it'll work for clients that are registered after useClient is in a running state
Update createClient so the first step is to clean up any existing clients with the same client id (removes leaking listeners)

What steps did you take to test this? This is required before we can merge, make sure to test the flow you've updated.
I tried the above examples with the code changes. Everything seems to be working as expected. I also added a Storybook story with a similar setup to the Code Sandbox example.
Checklist

[ ] Documentation;
[x] Storybook (if applicable);
[ ] Tests;
[x] Ready to be merged;

This is great! Thanks for working on my issue. Haven't tested the leaking listeners but this definitely fixes runSandpack() :)


Add support for JPEG XL

Hello,
JPEG XL (https://gitlab.com/wg1/jpeg-xl) support has just been merged to Chromium and can be enabled with a flag.
ImageMagick mentions JPEG XL support (https://imagemagick.org/script/formats.php) :
JXL	RW	JPEG XL image coding system	Requires the JPEG XL delegate library.
Is there a way to add this library during the install of imei, so it would support JPEG XL, too?

Hi,
I've already checked this out and it's planned to automatically add support for JPEG XL. However, as of now, I'm not 100% sure, what's needed. As soon as I've figured out, which requirements need to be met, I'll implement it.

Done :)

Wow! That's great, thank you!

...unfortunately, it didn't work for me.
At first it seems ok during the installation. It didn't so I --force(d) imei to build everything again:
Installing dependencies       [OK]
Building aom                  [OK]
Building libheif              [OK]
Building jpegxl               [OK]
Building ImageMagick          [OK]
Verifying installation        [OK]
convert seemed to work, but it generated "classic" JPG files.

/usr/local/bin/convert -list format
JXL is not in the list

/usr/local/bin/convert -version
Version: ImageMagick 7.0.11-6 Q32 x86_64 2021-03-28
(...)
Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype heic jbig jng jp2 jpeg jxl lcms lqr ltdl lzma openexr pangocairo png raqm raw rsvg tiff webp wmf x xml zip zlib

ls -l /usr/local/lib/ImageMagick-7.0.11/modules-Q32HDRI/coders
jxl.la and jxl.lo are there.

Everything seems fine.
Note: I had already installed JPEG XL from the GitLab sources, and I am already producing JXLs by generating PNGs with ImageMagick, then convert them with cjxl. I mean: it definitely compiles on my server.
And the build process of ImageMagick seems normal.
That might be an ImageMagick bug, maybe? I don't know.

Try again with --jxl-version 0.3.3

See https://gitlab.com/wg1/jpeg-xl/-/issues/207
It seems, that IM is currently not fully compatible with JXL.

Great news! https://twitter.com/JackyHallyday/status/1382434351904854025

Well, i don't understand, why it requires a tweet, to get their attention, but better than nothing, i guess 👍

The issue reported at JPEG XL has been labeled as fixed, but there hasn't been any commit yet. So we'll have to wait for the next release, I guess.

Today, a new commit has been pushed to the JXL repo: https://gitlab.com/wg1/jpeg-xl/-/commit/ab7c5e9b6795134377aa4846ceaae2c5bc504f76
I've rebuilt IM 7.0.11-8 using it, but still no luck.

@jackyhallyday Just FYI: It works now without any changes at my end using libjxl 0.3.7 and IM 7.0.11-13.


no-duplicates: allow duplicate if one is namespace and other not

It is a syntax error to put both namespace and non namespace import on the same line, so allow it.
Fix issue #1538

Note that this is a simple implementation which will not check:
import * as ns from './foo'
import './foo'

I'm currently working on something better…

@sveyret Did you ever circle back on this? I am seeing this issue come up with the following:
import firebase from 'firebase/app';
import 'firebase/auth';
import 'firebase/database';

and was trying to figure out if this was a mistake on my side or if I should create an issue.

I don’t really remember, but I don’t think I did anything since this PR. It means an evolution is needed.


[Explore] removing refresh chart overlay on deck_gl charts

Deck gl charts have this weird thing where scrolling the canvas isn't considered renderTrigger: true but also immediately updates the state of the chart. This scrolled state also does not persist across refreshes.
I'm not sure what the long term solution here is, but for the short term I'm disabling the refresh chart overlay for deckgl graphs.
test plan:

scroll on a deck gl chart
verify the state is updated and a refresh chart overlay does not appear

reviewers:
@john-bodley @michellethomas @mistercrunch

After discussion, there was confusion around the fact that autozoom was overwriting the viewport settings.

Codecov Report

Merging #4610 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #4610      +/-   ##
==========================================
- Coverage   71.19%   71.19%   -0.01%
==========================================
  Files         189      189
  Lines       14840    14841       +1
  Branches     1086     1087       +1
==========================================
  Hits        10566    10566
- Misses       4271     4272       +1
  Partials        3        3

Impacted Files
Coverage Δ

superset/assets/javascripts/chart/Chart.jsx
64.95% <0%> (-0.56%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 95a9b04...d38c782. Read the comment docs.

That was part of the confusion. We should still merge this PR, or the overlay will appear incorrectly when deck.gl charts are scrolled.

Also means the overlay won't show up at all even when changing the data, @betodealmeida any thoughts?

@mistercrunch yep- not sure a better way to leverage the overlay here, this is the only instance of a control I've seen that rerenders but also has renderTrigger: false property.

@mistercrunch @betodealmeida can we merge this PR for now and then come up with a more long term solution when you have time to address it? Would like to unblock users :(

@mistercrunch @betodealmeida bump on this?


Add Time tracking in linked task view

It could be useful to have a column "Time tracking" (as it is done for subtasks) in the "Links" table of a task view. This simplify the visualization of time spent on a task.
Typical use case:

One task is a milestone and therefore have a link "is a milestone of" with several other tasks
The manager of this milestone will add subtasks ("Management", "Validation", ...) to estimate and track the time spent around this task.
The manager can see quickly the time spent on the subtasks of this milestone, and on the tasks that targets this milestone.

FYI: I am working on a PR for this.

See master.


Convert the account into an organization

Is there any reason this account is a personal account?
ref: https://help.github.com/articles/converting-a-user-into-an-organization/

Hi Sorry,
I was out on vacation. I intend to use this for personal use.
Is mail id causing any issues?
Sorry for late reply.
Thanks,
Nachiket
From: Toshiyuki Takahashi<EMAIL_ADDRESS>Sent: Saturday, January 17, 2015 8:01 PM
To: flyway/flyway
Subject: [flyway] Convert the account into an organization (#934)
Is there any reason this account is a personal account?
ref: https://help.github.com/articles/converting-a-user-into-an-organization/
—
Reply to this email directly or view it on GitHubhttps://github.com/flyway/flyway/issues/934.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
INFOSYS***** End of Disclaimer *****INFOSYS

I had looked at this in the past, but somehow I think at the time there was no free plan for orgs.
Done.


Flap

New definitions

Codecov Report

Merging #36 into flap will decrease coverage by 2.51%.
The diff coverage is 0.32%.

@@           Coverage Diff            @@
##            flap     #36      +/-   ##
========================================
- Coverage   9.66%   7.14%   -2.52%
========================================
  Files          8       8
  Lines       1708    2309     +601
========================================
  Hits         165     165
- Misses      1543    2144     +601

Impacted Files
Coverage Δ

src/kinem.jl
5.26% <ø> (ø)
:arrow_up:

src/plots/plots2D.jl
0% <0%> (ø)
:arrow_up:

src/lowOrder2D/solvers.jl
9.35% <0%> (-1.52%)
:arrow_down:

src/utils.jl
4.63% <0%> (-0.8%)
:arrow_down:

src/lowOrder2D/postprocess.jl
4.19% <0%> (-2.24%)
:arrow_down:

src/lowOrder2D/calcs.jl
13.25% <0%> (-7.03%)
:arrow_down:

src/lowOrder2D/typedefs.jl
11.48% <1.9%> (-7.09%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f64104d...8dee1ba. Read the comment docs.