| 01:01.28 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 01:34.11 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 05:33.02 | *** join/#asterisk-bugs implicit_ (i=implicit@gateway/tor/x-1720dcf0bb9849d8) |
| 08:35.10 | *** join/#asterisk-bugs jmls (n=jmls@81.138.42.77) |
| 09:07.10 | *** part/#asterisk-bugs jmls (n=jmls@81.138.42.77) |
| 11:04.04 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:33.27 | *** join/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 14:36.30 | *** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-8e4200b978e8e23c) |
| 14:36.31 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 14:39.31 | Qwell | so I had the weirdest 2-second dream at some point this weekend. I "saw" a commit from Tilghman which closed like 12 bugs |
| 14:40.16 | putnopvut | Maybe it's a prediction of the future? |
| 14:40.21 | Qwell | perhaps |
| 14:40.32 | putnopvut | Did you happen to remember any of the bug id's? |
| 14:40.38 | Qwell | no, heh |
| 14:40.45 | Qwell | that'd be something, if I did |
| 14:52.51 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:52.51 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 14:55.32 | *** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:09.14 | putnopvut | M11634 |
| 15:09.15 | MuffinMan | No information available. |
| 15:09.35 | putnopvut | Why is 11634 private, and is it even an actual bug? |
| 15:09.51 | file | I just changed it to public |
| 15:10.32 | file | I wouldn't call it a bug |
| 15:30.37 | *** join/#asterisk-bugs Laureano (n=chatzill@200.59.172.38) |
| 15:31.50 | *** join/#asterisk-bugs Greek-Boy (n=email@41.221.58.5) |
| 15:32.02 | *** part/#asterisk-bugs Greek-Boy (n=email@41.221.58.5) |
| 15:47.35 | *** join/#asterisk-bugs Greek-Boy (n=email@41.221.58.5) |
| 15:53.08 | *** join/#asterisk-bugs jsmith (n=jsmith@70.5.195.227) |
| 15:53.09 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 15:53.51 | *** join/#asterisk-bugs infobot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 15:53.51 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Goodbye 1.2. We'll miss you. Maybe. -=- Overall issue count: >360 -=- Monitor new reports in #asterisk-commits |
| 16:20.44 | *** join/#asterisk-bugs miguel3239 (n=elguerom@h-68-167-124-171.cmbrmaor.covad.net) |
| 16:37.50 | De_Mon | I did a /lastlog 11634 .... as you might imagine, it did NOT do what I wanted. I wonder if theres a way tell irssi to abort without restarting next time. |
| 16:38.07 | De_Mon | I just waited it out, but man that sucked. |
| 17:01.29 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:26.18 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:43.29 | Corydon76-dig | PI!!! |
| 17:49.05 | jsmith | Corydon76-dig: I prefer pecan pie ;-) |
| 17:51.27 | Corydon76-dig | jsmith: 314 bugs in the Asterisk project |
| 17:51.27 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 17:52.11 | jsmith | Corydon76-dig: Gotcha ;-)... but wouldn't that be floor(100*pi)? |
| 17:52.23 | d1mas | russellb: Hello. Regarding 11628 - I believe that dropping DTMF_BEGIN does not fix the whole issue |
| 17:55.16 | russellb | well i don't think there is a problem at all |
| 17:55.20 | russellb | it's not ideal ... but it's not broken |
| 17:55.33 | russellb | the dtmf length is not kept, but the digit does not get lost, which is what happened before |
| 17:58.35 | d1mas | russellb: well the whole idea is wrong :) ast_read uses DTMF_END as input for process which emulates DTMFs. And autoservice basically collects _the output_ of that process and then feeds it back to the input |
| 17:59.59 | russellb | but it's not broken ... |
| 18:00.23 | russellb | i completely understand how it could be made better |
| 18:00.45 | russellb | but i have yet to see a way that is broken, other than DTMF length not being kept when a digit is read during autoservice |
| 18:01.24 | russellb | and i'm not that concerned with that part, as at least the digits don't get lost, which is the important part |
| 18:02.09 | d1mas | russellb: but at the end ast_read deals with both DTMF_ENDs it already generated plus DTMF_end coming from the channel driver... |
| 18:03.43 | d1mas | russelb: and since the timing between different ENDs is important things may be broken - DTMF which is read from channel driver may be ignored because coming without proper interval from last END (which was really properly separated but this time it comes from the autoservice queue) |
| 18:03.50 | d1mas | let me check the code... |
| 18:13.48 | d1mas | russellb: it looks like audiohooks will be called twice with that _END frame. Isn't it ? |
| 18:16.07 | russellb | that is true |
| 18:16.27 | d1mas | that is bad :) |
| 18:17.09 | russellb | true, but given the uses of that feature (only func_volume IIRC), then i'm not that concerned at the moment :) |
| 18:20.04 | *** join/#asterisk-bugs Laureano (n=chatzill@200.59.172.38) |
| 18:20.52 | d1mas | russellb: another thing: what happens what if when the last time autoservice called ast_read, it got DTMF_END('0') from the channel driver and started emulation. Next, autoservice queues back DTMF_END ('1') it collected. What happend on next ast_read? I have to analyze more thoroughly but at the first glance it looks like '1' will be queued _past_ '0' |
| 18:21.24 | d1mas | I mean that at the end, application will read '1', '0' not '0','1' |
| 18:24.10 | d1mas | russellb: Thebottom line - i believe that current behavior brings lots of problems most of which are not so obvious and very difficult to reproduce if someone hits them. I honestly believe we need to fix the real problem not just workaround known issues... |
| 18:25.30 | d1mas | russellb: how about changing frame source to "autoservice" when it is read by autoservice and fixing ast_read to immediately return without further processing any dequeued frame if its source is "autoservice"? |
| 18:42.26 | russellb | maybe ... |
| 18:42.35 | russellb | but probably only if you can demonstrate a problem i can't fix :) |
| 18:42.43 | russellb | i'm about to commit one more small change ... |
| 18:43.20 | d1mas | russellb: well, what about digit re-ordering I explained above ? |
| 18:44.04 | russellb | well, i don't think that could happen ... if the code is in the middle of emulating a digit, then it will not collect another one |
| 18:44.11 | russellb | it will be put in the queue to be processed later ... |
| 18:44.28 | russellb | but, it is possible to lose a digit, if it was in the middle of emulation when autoservice got stopped ... |
| 18:44.39 | russellb | actually, no, that wouldn't lose it ... |
| 18:45.14 | russellb | it would continue to be processed as normal ... |
| 18:45.20 | d1mas | russellb: will it work if I be able to give you step-by-step scenario which triggers error but it will be "in theory"? :) |
| 18:45.33 | russellb | yes, that's fine :) |
| 18:45.37 | d1mas | will try |
| 18:45.46 | russellb | but also check this chagne .. |
| 18:45.50 | d1mas | sure |
| 18:45.53 | russellb | A94797 |
| 18:45.54 | MuffinMan | [94797] Committed by russell on 2007-12-26 14:46:39: When a channel is in autoservice, mark a flag on the channel that says that |
| 18:50.37 | d1mas | russellb: offtopic: I was always wondering why the code sets DTMF_END_ONLY and then clears it but never tries to _restore_ original value of the flag. Isn't it possible that the flag will be set from different places due to different reasons? |
| 18:53.02 | russellb | that's on topic :) |
| 18:53.22 | russellb | for the sake of safety, you're probably right ... |
| 18:53.35 | russellb | i couldn't think of a case where that would happen, but that doesn't mean it won't happen in the future |
| 18:53.36 | russellb | i will fix it up. |
| 19:01.24 | russellb | thanks for all the help, as always |
| 19:19.35 | d1mas | russellb: np. Have troubles figuring out digit re-ordering scenario since END_ONLY flag is set :) but have scenario with another side-effect. Do you want it here (on the channel) or as private message? |
| 19:20.03 | russellb | here is fine |
| 19:20.29 | d1mas | #1 |
| 19:20.31 | d1mas | 1. user presses '0' |
| 19:20.32 | d1mas | 2. ast_read sees DTMF_END('0') and since END_OLY is off, it starts emulation and generates DTMF_BEGIN('0') |
| 19:20.34 | d1mas | 3. autoservice started and sets END_ONLY |
| 19:20.35 | d1mas | 4. autoservice eventually reads DTMF_END and queues it. |
| 19:20.37 | d1mas | 5. autoservice stopped, it queues DTMF_END('0') and clears END_ONLY |
| 19:20.38 | d1mas | 6. ast_read sees DTMF_END('0') and since END_OLY is off, it starts emulation and generates DTMF_BEGIN('0') again |
| 19:20.40 | d1mas | as result, final application receives double _BEGIN('0') |
| 19:21.50 | russellb | in that case, the end application should only get a single '0' |
| 19:22.21 | d1mas | #2 |
| 19:22.22 | d1mas | The application just misses all _BEGIN frames received during autoservice although channel did not have END_ONLY in the beginning so probably the channel cares about _BEGIN ones |
| 19:22.22 | russellb | it will get a single BEGIN and END |
| 19:22.45 | d1mas | oh, #2 is wrong sorry |
| 19:23.53 | d1mas | regarding #1: I'm pretty much sure it will receive two |
| 19:25.34 | d1mas | russellb: the first BEGIN application receives before it called autoservice_start. It happens when DTMF_END is received from the channel driver and ast_read starts emulation. |
| 19:25.48 | russellb | ohhh |
| 19:26.31 | russellb | ok, then yeah, you're right ... the application could see 2 BEGINs in that case, and a single END |
| 19:26.39 | d1mas | yep |
| 19:27.11 | russellb | ok, so how about this .... |
| 19:27.25 | russellb | nevermind, won't work ... |
| 19:27.29 | russellb | i'll have to think about it |
| 19:28.52 | d1mas | i believe that having a way for autoservice to queue frames back with a note "do not process, just return" attached to them would fix the issue. But I also have to think about it :) |
| 19:29.40 | russellb | but i'm not sure how to mark them that way ... i don't want to break the ABI by changing struct ast_frame |
| 19:29.50 | russellb | and i don't want to just use frame->src and a string comparison |
| 19:30.01 | russellb | i feel like it's too expensive to do on _every_ frame |
| 19:30.58 | d1mas | well. you do not need string comparison really :) |
| 19:31.03 | d1mas | just a pointer comparison |
| 19:31.51 | d1mas | autoservice will have to use some global constant declared by frame.h and defined in the frame.c |
| 19:35.27 | russellb | ah ... good point ... |
| 19:39.58 | d1mas | russellb: another way which is probably a Good Thing :) - there is has_timing_info int field which is almost unused. |
| 19:40.34 | d1mas | russellb: you can convert it into frame_flags and define FRAME_FLAG_HAS_TIMING=1 |
| 19:40.56 | d1mas | and add more flags as needed |
| 19:41.03 | russellb | well it is used in some places ... |
| 19:41.06 | russellb | ohhhhh |
| 19:41.07 | russellb | i see |
| 19:41.24 | russellb | good idea. |
| 19:41.39 | russellb | i need to grab some food |
| 19:41.51 | russellb | you might want to create a report on mantis so i don't forget :) |
| 19:42.25 | d1mas | Ok, so I will be proposing rename of has_timing_info in the report. Ok ? |
| 19:42.37 | russellb | sounds good |
| 19:42.59 | d1mas | russellb: Bone Appetit :) |
| 19:43.07 | russellb | thanks! |
| 20:02.25 | *** topic/#asterisk-bugs by Qwell -> Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Goodbye 1.2. We'll miss you. Maybe. -=- Overall issue count: >=360 -=- Monitor new reports in #asterisk-commits |
| 20:03.46 | *** topic/#asterisk-bugs by russellb -> Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Overall issue count: >=360 -=- Monitor new reports in #asterisk-commits |
| 20:03.53 | russellb | i'm tired of saying goodbye to 1.2 |
| 20:03.54 | russellb | :) |
| 20:04.52 | jsmith | But the overall issue count is around 314, according to Corydon76 |
| 20:05.03 | file | jsmith: of the Asterisk project |
| 20:05.34 | jsmith | Oh, gotcha ;-) |
| 20:12.20 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 20:15.00 | *** topic/#asterisk-bugs by Qwell -> Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Overall issue count: ~360 -=- Monitor new reports in #asterisk-commits |
| 20:35.03 | d1mas | russellb: 11635. Sorry for untested patch, but this is "reminder" issue anyway :) |
| 20:35.42 | russellb | thank you |
| 20:36.09 | russellb | i was actually in the middle of working on it |
| 20:36.14 | russellb | so i'll take pieces from yours and finish it up |
| 20:36.15 | russellb | :) |
| 20:37.18 | d1mas | russellb: still not perfect solution anyway because there is still a code which can generate DTMF before the queue is read. But I doubt if conflict is possible. NP :) |
| 20:37.23 | d1mas | next turn... |
| 20:37.27 | d1mas | file: are you there? :) |
| 20:37.41 | file | yes |
| 20:40.18 | d1mas | file: great. if by any chance you have seen v4-asterisk-t38.patch from 11614, there implementation how to read T38 status from a channel. I found the chan_tech structure has pointer to a queryoption function which is not used at all. So I implemented queryoption for chan_sip and introduced T38_STATE option. The question: is this approach Ok for reading T38 status or you had something... |
| 20:40.19 | d1mas | ...different in mind? |
| 20:40.51 | file | I have no current concept in mind. |
| 20:42.09 | d1mas | file: ok, but hasn't been queryoption deprecated? (there were NO usages of it). And is it Ok in general to use queryoption for reading something what is not really an option? |
| 20:42.53 | file | I have not looked at that 'nor know the answer to your question |
| 20:43.02 | d1mas | ok |
| 20:44.29 | file | is it the solution overall? I do not know... perhaps |
| 20:44.38 | d1mas | file: if I create a patch which just adds API for reading of T38 status without any real users of the API and submit it as separate issue - will it be easier for you to review? |
| 20:44.55 | d1mas | "without any real uses" |
| 20:45.04 | file | I have not given it further design thought and it has not been on my mind... other things have |
| 20:46.36 | d1mas | file: well if you have read my email and have no general objections against the approach, I could take your branch and implement all I wanted and submit everything as a huge patch if you want... |
| 20:47.38 | file | I have to let it roll around in my head for awhile, I can't give an instant yes or no like that |
| 20:48.19 | d1mas | file: i see |
| 20:50.33 | file | and I would hate to see you do all that only to ultimately have it redone again |
| 20:51.50 | d1mas | file: me too :) |
| 21:42.49 | *** join/#asterisk-bugs jsmith (n=jsmith@68-247-236-122.area3.spcsdns.net) |
| 21:42.49 | *** mode/#asterisk-bugs [+o jsmith] by ChanServ |
| 23:01.33 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 23:01.34 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 23:17.02 | *** part/#asterisk-bugs zerohalo (n=zeroHalo@pool-71-162-97-18.bstnma.east.verizon.net) |
| 23:22.19 | Qwell | hmm, 355 |
| 23:23.12 | putnopvut | No, I can't actually bench that much yet. |
| 23:23.22 | Qwell | I totally can |
| 23:23.29 | putnopvut | ...ounces? |
| 23:23.29 | Qwell | well, 35.5, anyways |
| 23:23.35 | Qwell | ...maybe |
| 23:24.05 | Qwell | so, get this. freshman year in high school (where I was put in a year early - so I was...12?) |
| 23:24.10 | Qwell | they put me in weight training |
| 23:24.26 | Qwell | random bit of info there :p |
| 23:24.40 | putnopvut | How'd you do? |
| 23:24.45 | Qwell | let's put it this way |
| 23:24.49 | Qwell | the bar was half my weight |