| 03:20.11 | *** join/#asterisk-dev dakudos (~dakudos@c-73-217-33-206.hsd1.co.comcast.net) |
| 04:03.47 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.53) |
| 06:17.58 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:18.22 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:44.36 | *** join/#asterisk-dev jkroon (~jkroon@41.169.49.18) |
| 06:58.53 | *** join/#asterisk-dev hehol (~Adium@ip-176-199-151-97.hsi06.unitymediagroup.de) |
| 07:03.06 | *** join/#asterisk-dev dakudos (~dakudos@c-73-217-33-206.hsd1.co.comcast.net) |
| 09:58.50 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 11:26.51 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 11:26.51 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 12:42.49 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:47.04 | *** join/#asterisk-dev jkroon (~jkroon@41.169.49.18) |
| 12:55.22 | *** join/#asterisk-dev spatel (~spatel@pool-98-118-124-216.bstnma.fios.verizon.net) |
| 12:57.44 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-lhbqeiwlznzfgnta) |
| 12:57.44 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:18.56 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-jhftyneulbufsbnp) |
| 14:18.56 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:50.59 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 14:50.59 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 15:44.46 | *** join/#asterisk-dev sahmed (~sahmed@12.252.7.226) |
| 18:09.40 | kharwell | The only way to get a channel snapshot is by creating one or querying the cache for the latest correct? |
| 18:10.28 | kharwell | and I'm assuming querying the stasis cache is faster than creating a new snapshot? |
| 18:15.57 | file | kharwell: depends on what you have - in 17 and master if you have an ast_channel you can also get the snapshot from that |
| 18:17.44 | file | and yes, using the API I think would be faster than creating |
| 18:17.53 | kharwell | this will be in 13+. Trying to fix a deadlock that I believe is due to the channel being locked in pbx_outgoing_attempt (pbx.c), and then returned to the calling function |
| 18:18.23 | kharwell | I'm thinking to fix I can get a way with bumping the channel's ref, and using the snapshot instead of locking the channel |
| 18:19.45 | kharwell | since it looks like (at least in this particular case) it just wants the channel for AMI event output. It holds the lock right after dial so the channel won't change between raising the AMI event and the dial |
| 18:19.55 | file | nods |
| 18:59.03 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-afuyxhifshlkhuvk) |
| 18:59.03 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 19:51.11 | *** join/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |
| 20:08.37 | seanbright | so then the page _shouldn't_ be updated? |
| 20:11.47 | file | it should be, I disabled the 15 part for now |
| 22:23.52 | *** join/#asterisk-dev spatel (~spatel@pool-98-118-124-216.bstnma.fios.verizon.net) |
| 22:50.04 | seanbright | do we require gnu ld? |
| 22:52.12 | *** join/#asterisk-dev spatel (~spatel@pool-98-118-124-216.bstnma.fios.verizon.net) |
| 23:05.30 | *** join/#asterisk-dev spatel (~spatel@pool-98-118-124-216.bstnma.fios.verizon.net) |