| 00:06.26 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 00:06.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:07.51 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 01:28.47 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-153-236.bvtn.or.frontiernet.net) |
| 03:23.03 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 03:23.03 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 03:32.28 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 03:32.28 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 04:24.46 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 05:24.53 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:24.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:28.35 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@static-8-143-241-92-p2mp.broadband.blic.net) |
| 05:28.35 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:30.15 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 06:30.18 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:30.19 | schmidts | good morning |
| 06:59.16 | kaii | moin |
| 07:00.41 | *** join/#asterisk-dev moy_ (~moy@69.157.46.221) |
| 07:04.19 | schmidts | morning |
| 07:21.06 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:24.23 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 07:40.46 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:d9a5:9cc7:c68a:da14) |
| 07:41.14 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:41.14 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 08:24.02 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21c:23ff:fe20:991f) |
| 08:24.02 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:31.14 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:31.14 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 09:19.57 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21f:1fff:fecd:f8e5) |
| 09:19.57 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:27.31 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 11:30.47 | irroot | on SIP rtp_timeout can we rather use ast_hangup to kill and remove the channel .... |
| 11:30.54 | irroot | http://pastebin.com/PneXAXNM |
| 11:51.49 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:51.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:51.52 | *** join/#asterisk-dev t_dot_zilla (~t_dot_zil@firewall-a.buf.ny.i-evolve.net) |
| 12:07.29 | schmidts | irroot i would prefer not doing an ast_hangup cause you will have a lot of deadlock prevention in there which could slow down the monitor thread |
| 12:08.31 | irroot | schmidts i hear you this only trigers when the timeout is hit ie a bad chan this particular case is so bad that it needs to be ripped out with force |
| 12:08.50 | irroot | its orphaned and sitting in the channels list |
| 12:09.35 | schmidts | as far as i remember in the rtp timeout function we only set the need handup flag for this channel |
| 12:09.39 | schmidts | but let me take a look ;) |
| 12:09.54 | schmidts | 1.8? |
| 12:10.08 | irroot | im trying to see where this creeps in initially thought it was app_queue but does not explain missing pvt |
| 12:10.18 | irroot | yeah 1.8 production server |
| 12:12.00 | schmidts | ah ok in 1.8 its still the old way, not the one i have written ;) |
| 12:12.30 | schmidts | ok thats a little bit tricky then ;) |
| 12:12.31 | irroot | clearly |
| 12:13.21 | schmidts | in 1.8 you have only one container which hold every sip dialog, in the do_monitor function you will have a callback to destroy dialogs which will also handle the hangup AFAIK |
| 12:13.35 | schmidts | in this callback there is also the rtp timeout check done |
| 12:13.42 | irroot | yes |
| 12:14.46 | irroot | it checks the dialog->owner->Xrtp for timeout |
| 12:15.06 | schmidts | yes |
| 12:15.09 | irroot | if not on hold |
| 12:19.11 | schmidts | i guess the problem is that an ast_softhangup is used |
| 12:19.24 | schmidts | sorry meant ast_softhangup_nolock |
| 12:19.31 | irroot | currently yes |
| 12:19.55 | irroot | and this will work fine unless things are broken |
| 12:20.59 | irroot | softhangup requires the channel driver to do the work |
| 12:21.41 | schmidts | but i dont understand, cause we can get the lock and there is also a dialog->owner cause you wouldnt get to the point where the rtp timeout is really fired if it wouldnt be like this |
| 12:22.16 | irroot | dialog->owner->pvt is toast it appears |
| 12:23.21 | schmidts | maybe i am wrong but isnt dialog->owner->pvt = dialog |
| 12:24.13 | schmidts | dialog is the sip_pvt and dialog->owner must be a sip channel |
| 12:24.56 | irroot | mmm |
| 12:25.52 | irroot | fixup was failing with no pvt |
| 12:29.37 | schmidts | do you know from where this sip_fixup is called? |
| 12:30.27 | irroot | yeah ast_do_masq |
| 12:30.34 | schmidts | hm ok |
| 12:30.38 | irroot | from a pickup |
| 12:30.58 | irroot | this is the channel dialing *8 to app_directed_pickup |
| 12:31.02 | schmidts | its really strange |
| 12:33.00 | schmidts | its not a problem with the oldchannel sip pvt its the new one |
| 12:33.53 | irroot | yeah |
| 12:34.25 | irroot | and it just sits there did a kludge on the pickup to wait for bridge running autoservice |
| 12:35.59 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21c:23ff:fe20:991f) |
| 12:35.59 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 12:38.32 | schmidts | irroot its just a feeling but i guess its happening here: http://www.asterisk.org/doxygen/asterisk1.8/channel_8c-source.html#l06400 |
| 12:39.24 | irroot | thx im lookin at |
| 12:39.42 | schmidts | btw nothing happens if the fixup will not work, just the warning |
| 12:39.53 | *** join/#asterisk-dev cerienjean (cerienjean@95.138.77.91) |
| 12:40.29 | schmidts | maybe we need a res = -1; and goto done; there too |
| 12:40.33 | irroot | yeah there is a warning in fixup |
| 12:40.46 | schmidts | no mean row 6462 |
| 12:41.24 | schmidts | in the if where the fixup is called, in your pastebin you see the warning from the fixup itself and also the warning from the if but it doesnt change anything if the fixup doesnt work |
| 12:41.37 | *** part/#asterisk-dev cerienjean (cerienjean@95.138.77.91) |
| 12:42.02 | irroot | yeah with you |
| 12:42.33 | irroot | however its when this happens that the channel sits arround and needs kill -9 to stop asterisk |
| 12:43.34 | schmidts | of course it isnt really working cause there is no tech_pvt but the masquerade is even done |
| 12:44.53 | schmidts | but maybe this isnt the problem cause the newchannel which shows this warning is the clonechan from masquerade and this one should be killed |
| 12:44.54 | irroot | yeah masq seems done |
| 12:45.34 | irroot | yeah but as the masq is done we are now it |
| 12:46.20 | irroot | somewhere after the masq has started the channel disapears |
| 12:46.46 | irroot | masq finishes ok and we left in limbo |
| 12:49.24 | schmidts | maybe the problem itself happens on row 06581 cause you dont see a warning from this fixup, but IMHO you should see this |
| 12:49.46 | seanbright | so here is an interesting situation... i think at least |
| 12:50.28 | seanbright | my reps dial into an asterisk box via SIP, asterisk dials another asterisk box via IAX2 and on that server AgentLogin is called |
| 12:51.05 | seanbright | any way i could play hold music for the reps from the box they are dialing into instead of the box where AgentLogin is called? |
| 12:51.59 | irroot | mmm but its calling the underlying call in chan sip that is causing the warning |
| 12:52.25 | schmidts | what you mean? |
| 12:53.10 | schmidts | as far as i have seen the code between the fixup warning you get and row 06581 these both channels are not changed so you should get the same warning there again |
| 12:54.05 | irroot | ok wait im with you |
| 12:55.00 | irroot | 6461/6581 |
| 12:55.36 | irroot | 6476 |
| 12:55.58 | *** join/#asterisk-dev DocAwesome (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:55.58 | *** mode/#asterisk-dev [+o DocAwesome] by ChanServ |
| 12:57.50 | schmidts | ok missed that :D |
| 12:58.53 | schmidts | ok the kill_fixup allways return 0 |
| 12:59.03 | schmidts | thats why there is no warning on 6581 |
| 12:59.26 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 12:59.31 | irroot | yeha |
| 13:00.08 | schmidts | just a stupid idea but atleast the fixup doesnt do anything in this situation why do you dont copy the three rows from 6461 to several places above so you can see where and why this fixup is broken? |
| 13:02.46 | schmidts | irroot can you reproduce this? |
| 13:03.11 | irroot | that is the problem happens 2/3 times a week across > 100 sites |
| 13:03.30 | schmidts | ok so it could be just a very rarely race condition :( |
| 13:03.55 | irroot | yeah |
| 13:04.33 | schmidts | i hate such problems ;) |
| 13:05.45 | irroot | yip +1 |
| 13:06.04 | irroot | and not much to go on |
| 13:06.41 | irroot | if its more frequent/predictable we could put debug on without problems on production |
| 13:07.23 | irroot | once its tech is ast_kill_tech we stuck i guess |
| 13:08.05 | schmidts | i though so, but i doesnt work cause if origchan is set to kill_tech it would return 0 not -1 and you wouldnt see the warning in the first place |
| 13:08.19 | schmidts | sorry clonechan not origchan |
| 13:08.21 | irroot | wait it does not get there |
| 13:08.32 | irroot | clonechan is the one left standing |
| 13:08.37 | schmidts | yes the old one |
| 13:09.00 | irroot | with a bogus tech and 1/2 fixed |
| 13:09.12 | schmidts | and btw you see the warning cause the origchan (the new one) doesnt have the pvt but killtech will only be set to the clonechan (the old one) |
| 13:09.25 | irroot | yeah |
| 13:09.26 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21f:1fff:fecd:f8e5) |
| 13:09.26 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 13:10.17 | schmidts | what i dont understand is why we check for the original->masq on the beginning of do_masq to prevent multiple calls of this function but some rows below we set original->masq to NULL |
| 13:10.43 | schmidts | imho if a second masq to this chan would come in after its set to NULL the check for multiiple masqs wouldnt work or am i wrong? |
| 13:11.42 | schmidts | i mean row 6310 and 6345 |
| 13:13.11 | irroot | is it maybe 6323/4 |
| 13:13.50 | irroot | channels is held but this could be a cause of the problem |
| 13:14.27 | irroot | its not a masq race condition but that does not mean its clobered elsewhere |
| 13:15.51 | schmidts | wouldnt it be better to set clonechan after we get the channel lock? |
| 13:17.07 | schmidts | if there are two channels which both try to masquerade on the same channel, the first one goes well and the second one just slips through the check on 6310 but will stuck on the deadlock prevention until the first one is finished but the clonechan is allready set |
| 13:18.48 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:18.49 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:19.24 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:19.24 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:19.44 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:19.44 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:20.18 | schmidts | but the clonechan will be killed when the first channel finished masquerading so this could lead to a situation like you see |
| 13:20.49 | irroot | yeah i see it |
| 13:21.51 | schmidts | dont know if this really could happen but imho it shouldnt do anything by moving the clonechan = original->masq row below the deadlock avoidance |
| 13:21.54 | irroot | ie make sure all the locks are "stable" first |
| 13:22.40 | irroot | lock channels / original and then clonechan [with avoidance of orig] before any work begins |
| 13:23.39 | irroot | move 6319-6325 to 6305 |
| 13:24.08 | schmidts | nope not a good idea ;) |
| 13:24.16 | irroot | see it |
| 13:24.18 | schmidts | ;) |
| 13:24.32 | irroot | if there 2 it will bounce between them foreva |
| 13:24.36 | schmidts | just move 6316+17 to 6326 |
| 13:24.40 | schmidts | yes ;) |
| 13:25.26 | schmidts | ok moment |
| 13:25.30 | irroot | yeah thats what i was thinking also what you said above |
| 13:25.32 | schmidts | sorry i was completly wrong |
| 13:25.43 | schmidts | the deadlock avoidance is done on the clonechan not on the origchan |
| 13:25.44 | irroot | but you cant |
| 13:25.51 | irroot | ^^^ |
| 13:25.54 | schmidts | ;) |
| 13:25.55 | irroot | indeed |
| 13:26.19 | irroot | we could lock original->masq |
| 13:26.35 | irroot | but that have no diff |
| 13:26.41 | schmidts | yes ;) |
| 13:26.56 | irroot | check the tech of clonechan i thing |
| 13:27.03 | irroot | s/thing/think/ |
| 13:27.17 | irroot | if its null then bomb out |
| 13:28.21 | irroot | is it possible that a pickup starts then a pickup happens and clonechan is targeted |
| 13:28.45 | irroot | pickup of a pickup in progress when the masq is happening |
| 13:28.48 | schmidts | we could check the original->masq->tech first |
| 13:30.44 | irroot | could stop 6462 |
| 13:32.55 | schmidts | but this could change these channels so you might better only check for the tech without changing anything at this place |
| 13:33.51 | irroot | yeah return if tech is not right |
| 13:36.28 | irroot | 6310 && |
| 13:37.43 | schmidts | && !original->masq->tech_pvt |
| 13:38.13 | schmidts | nope you need a || |
| 13:38.53 | irroot | || strcmp(original->masq->tech->type, "Kill") |
| 13:39.12 | schmidts | nope |
| 13:39.27 | schmidts | strcmp is slow |
| 13:39.43 | schmidts | and btw !strcmp cause you want to leave if it is kill |
| 13:40.15 | irroot | yeah im trying to see what i can check |
| 13:40.19 | irroot | missed the ! |
| 13:40.22 | schmidts | but the fixup maybe didnt fail cause its set to kill, i would prefer checking the tech_pvt directly |
| 13:40.57 | irroot | see 654 |
| 13:41.40 | irroot | im going to put some warnings in to show tech / pvt / ... when this happens |
| 13:42.15 | schmidts | yes it is set to Kill if this pvt was killed but if something else happend it might be something different |
| 13:47.20 | irroot | ill have to keep a eye on this |
| 13:47.44 | irroot | thx for the ear/feedback |
| 13:48.29 | schmidts | your welcome |
| 13:50.58 | irroot | i hate these obscure problems |
| 13:51.59 | schmidts | :D |
| 13:52.16 | schmidts | me too! |
| 14:24.40 | irroot | schmidts think i got something |
| 14:24.59 | irroot | race between ast_hangup and ast_do_masq |
| 14:25.11 | russellb | masquerades are the root of all asterisk evil |
| 14:25.38 | schmidts | :D |
| 14:25.50 | irroot | see line 2750 |
| 14:26.52 | irroot | ast_do_masq is trying to do its thing but the deadlock avoidance lets ast_hangup get in and this calls ast_do_masq .... |
| 14:26.59 | schmidts | chan_sip or channel.c ? |
| 14:27.04 | irroot | channel.c |
| 14:27.20 | schmidts | ok thats why i am wondering what the TCP Tls helper thread has to do with it :D |
| 14:27.40 | irroot | lol sorry we were looking at channel.c earlier |
| 14:27.53 | schmidts | i know ;) |
| 14:27.55 | schmidts | ok got it |
| 14:28.18 | schmidts | yes possible could be the issue |
| 14:28.32 | schmidts | then you will have the situation we have talked about earlier |
| 14:29.08 | irroot | yeah if it looks like a duck and quacks like a duck its probably a chicken with a identity crisis in drag |
| 14:30.52 | irroot | i dont understand why we will want to get the masq finished in ast_hangup messing with the locks ?? |
| 14:31.36 | schmidts | its in the code: |
| 14:31.37 | schmidts | 02737 /* Don't actually hang up a channel that will masquerade as someone else, or |
| 14:31.38 | schmidts | 02738 if someone is going to masquerade as us */ |
| 14:32.06 | irroot | yeah but this in hangup |
| 14:32.19 | schmidts | hmm the problem could be the lock |
| 14:32.35 | irroot | yip |
| 14:32.50 | irroot | it unlocks to proceed |
| 14:33.00 | irroot | and this is the race point |
| 14:33.54 | schmidts | it could be |
| 14:41.33 | irroot | clonechan is set to original->masq already in ast_do_masq |
| 14:41.33 | irroot | that dl avoidance will unlock it and let ast_do_masq run in ast_hangup then run here again after all the insides have gone through a blender |
| 14:41.33 | irroot | this is then a obscure race it requires a lock on clonechan at the same time original is been hungup |
| 14:41.33 | schmidts | sounds possible |
| 14:43.10 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 14:43.10 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://xkcd.com/303/ |
| 14:43.24 | irroot | anonymouz666 its tricky to do it as you copying the insides from one channel to another while the channels are runing |
| 14:43.33 | irroot | ^^ kpfleming +1 |
| 14:43.36 | anonymouz666 | hah |
| 14:44.27 | irroot | ~beer |
| 14:44.27 | infobot | ACTION has disconnected (Read error: 99 (Connection reset by beer)) |
| 14:44.40 | irroot | had to he was looking for it |
| 14:44.48 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:44.48 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:45.22 | irroot | outta here lets find the snow .... |
| 15:19.57 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21f:1fff:fecd:f8e5) |
| 15:19.57 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:28.06 | seanbright | [Jul 29 11:27:33] WARNING[1108]: translate.c:426 ast_translator_build_path: No translator path: (starting codec is not valid) |
| 15:28.09 | seanbright | [Jul 29 11:27:33] WARNING[1108]: file.c:184 ast_writestream: Unable to translate to format g722, source format slin44 |
| 15:28.12 | seanbright | any idea how to fix that? |
| 15:28.39 | kpfleming | don't use slin44 |
| 15:28.50 | kpfleming | it shouldn't exist :-) |
| 15:29.13 | kpfleming | anyway... codec_resample should know how to resample from slin44 to slin16. if it doesn't, that's a bug. |
| 15:29.45 | seanbright | i don't have codec_resample |
| 15:29.49 | seanbright | or it's not built... will check |
| 15:30.19 | kpfleming | well, if you are going to connect streams of different sample rates, you need resampling :-) |
| 15:32.00 | seanbright | you make a good point |
| 15:32.22 | kpfleming | sometimes i do, yes |
| 15:32.50 | kpfleming | it's habit-forming |
| 15:38.39 | *** join/#asterisk-dev irroot (~irroot@197.171.50.204) |
| 15:41.49 | seanbright | oh that sounds good |
| 15:43.00 | kpfleming | indeed. wideband audio is very nice. |
| 15:43.45 | seanbright | actually, while you're here... :-) |
| 15:43.51 | seanbright | scrolls back |
| 15:44.05 | seanbright | my reps dial into an asterisk box via SIP, asterisk dials another asterisk box via IAX2 and on that server AgentLogin is called |
| 15:44.05 | kpfleming | i am about to head out for lunch |
| 15:44.15 | seanbright | any way i could play hold music for the reps from the box they are dialing into instead of the box where AgentLogin is called? |
| 15:44.16 | kpfleming | but ok |
| 15:44.19 | seanbright | heh |
| 15:44.22 | seanbright | sorry, go to lunch |
| 15:44.22 | kpfleming | hmm |
| 15:44.42 | seanbright | i feel like there is some iax2 protocol feature i can use |
| 15:44.45 | seanbright | like magic |
| 15:44.48 | kpfleming | i don't think so, because this isn't a typical 'hold' situation |
| 15:44.52 | seanbright | right |
| 15:44.56 | seanbright | they arne't on hold |
| 15:44.57 | kpfleming | AgentLogin is directly calling ast_moh_start() |
| 15:45.15 | kpfleming | if it was sending AST_CONTROL_HOLD, things would be different |
| 15:45.19 | kpfleming | so no, i don't think so |
| 15:45.24 | kpfleming | not without hacks |
| 15:45.26 | seanbright | right |
| 15:45.30 | seanbright | ok, thanks |
| 15:45.34 | seanbright | you may now eat |
| 15:45.38 | kpfleming | cool |
| 15:48.03 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21f:1fff:fecd:f8e5) |
| 15:48.03 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:51.56 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:51.56 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:00.42 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:00.42 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:08.21 | irroot | ok think i have this race condition / resource leak / orphan sorted |
| 16:09.26 | irroot | after the DL avoindance check the sanity of continuing the channels cant be removed as we have the channels lock but they may have been masqed already in another thread while we were not watching |
| 16:13.20 | irroot | https://reviewboard.asterisk.org/r/1323 russellb re earlier / kpflemming the other day |
| 16:44.24 | seanbright | this looks sane, right: http://pastebin.com/NhdV4PrJ |
| 16:45.08 | Qwell | is that in wav_write or something? Why would it be read only? O.o |
| 16:45.18 | seanbright | without this patch, *CLI> file convert something.wav something.g722 |
| 16:45.43 | seanbright | generates an error message because of a short write |
| 16:45.54 | seanbright | which, in turn, is caused by a bad descriptor error |
| 16:46.00 | seanbright | since the fd was opened r/o |
| 16:46.03 | Qwell | I think you're attacking the wrong thing. |
| 16:46.11 | Qwell | Why would a convert be trying to write to the source file? |
| 16:46.15 | seanbright | it's not |
| 16:46.24 | seanbright | it's trying to close the ast_filestream |
| 16:46.57 | Qwell | yeah it's definitely trying to fwrite to it. :p |
| 16:47.09 | seanbright | i'm confused |
| 16:47.31 | Qwell | I think the stuff in wav_close shouldn't be in wav_close |
| 16:47.36 | seanbright | ah |
| 16:48.05 | seanbright | well then i retract my patch :-) |
| 16:48.17 | Qwell | well, it would fix the problem - I just think there's going to be some other way to do it |
| 16:48.29 | seanbright | when would you call update_header? |
| 16:48.33 | seanbright | after each write? |
| 16:48.44 | Qwell | it isn't update_header that's fwriting |
| 16:48.53 | Qwell | fwrite()ing. stupid english. |
| 16:49.07 | seanbright | sure it is |
| 16:49.27 | seanbright | if (s->filename) { update_header(s->f); } |
| 16:49.29 | Qwell | I'm looking in trunk, and it's calling fwrite in wav_close |
| 16:49.43 | seanbright | ah, i'm looking at 10 |
| 16:50.05 | Qwell | It's doing the fwrite in wav_close there too :p |
| 16:50.09 | Qwell | <PROTECTED> |
| 16:50.29 | seanbright | ok... i think we're talking about the same thing |
| 16:50.37 | seanbright | we try to write to a file that is opened read only |
| 16:50.42 | Qwell | well, yes |
| 16:50.44 | seanbright | how's that? |
| 16:50.57 | seanbright | update_header is called before the fwrite you are talking about |
| 16:51.01 | seanbright | and update_header calls fwrite |
| 16:51.08 | Qwell | yuck |
| 16:51.19 | seanbright | which is where the error i was seeing was coming from |
| 16:51.34 | seanbright | regardless... we shouldn't try to write to a file that is r/o |
| 16:51.38 | seanbright | annnnnd go |
| 16:51.40 | Qwell | no, I agree witht hat |
| 16:51.49 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:51.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:52.14 | seanbright | update_header has to be called when the stream is closed |
| 16:52.22 | seanbright | or on each write |
| 16:52.33 | Qwell | each write would be a lot of fseeking |
| 16:52.37 | seanbright | i prefer the former |
| 16:52.38 | seanbright | yes. |
| 16:53.01 | seanbright | i don't see how my patch is attacking the wrong problem |
| 16:53.15 | Qwell | It's a problem with how the module is designed. |
| 16:53.41 | Qwell | your patch would work. looking at it, I think it would be too much work to change how its done |
| 16:53.51 | seanbright | what is the 'correct' way to fix the issue |
| 16:53.58 | seanbright | regardless of level of effort |
| 16:54.08 | Qwell | I don't know. |
| 16:54.11 | seanbright | heh |
| 16:54.13 | seanbright | thanks for coming out |
| 16:54.31 | Qwell | This will be a problem in other modules too, I bet. |
| 16:54.40 | Qwell | Pretty much anything with a .close, maybe? |
| 16:54.46 | seanbright | only 2 of them have .close |
| 16:54.51 | seanbright | wav and ogg |
| 16:55.03 | Qwell | yeah, ogg has a s->writing |
| 16:55.07 | seanbright | and ogg handles it properly, albeit with it's own ->writing struct member |
| 16:55.27 | Qwell | Ship it! |
| 16:55.33 | Qwell | (your patch) |
| 16:55.35 | seanbright | i don't see how you get around calling update_header() in wav_close |
| 16:55.44 | seanbright | regardless of how the module is designed |
| 16:55.59 | seanbright | short of writing it on each write |
| 16:56.27 | Qwell | I'm surprised that more formats don't have a close function |
| 16:57.13 | Qwell | Oh, that's why! format_wav_gsm does call update_header on every write. gross. |
| 16:57.23 | seanbright | ah... fun |
| 16:58.30 | kpfleming | it's not all that bad, it's all in cache anyway |
| 17:00.04 | seanbright | is that bit test correct? |
| 17:00.25 | seanbright | if ((s->mode & O_RDONLY) == O_RDONLY) { |
| 17:00.31 | seanbright | O_RDONLY on my machine is 0 |
| 17:07.08 | kpfleming | no, that's not correct |
| 17:07.16 | kpfleming | O_RDONLY is a combination of bits not a single bit |
| 17:07.27 | kpfleming | if (s->mode == O_RDONLY) would be correct |
| 17:17.57 | seanbright | k |
| 17:23.49 | *** part/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:17.44 | seanbright | wasn't there a conversation on the -users or -dev list about the way that the files in the core-sounds tarball were encoded? |
| 18:18.01 | seanbright | i feel like someone external wrote an email describing the "right" way to do it and then you guys converted all of the sounds based on that |
| 18:18.11 | seanbright | or am i making that up? |
| 18:18.49 | seanbright | might have had something to do with speex |
| 18:31.44 | *** part/#asterisk-dev irroot (~irroot@197.171.50.204) |
| 18:33.30 | seanbright | "Jean-Marc Valin (from Octastic) had been experimenting with high-pass filters on the existing Asterisk sound files and found a configuration which dramatically reduced the amount of low-frequency sound on the prompts..." |
| 18:33.50 | seanbright | that... is there any more info on it? |
| 18:35.29 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 18:37.39 | lmadsen | seanbright: unfortunately there is not |
| 18:38.00 | lmadsen | seanbright: he didn't really explain in any of the emails the what and why, just the how :) |
| 18:38.00 | seanbright | son of a... |
| 18:38.20 | seanbright | i'm all about the how |
| 18:38.26 | lmadsen | the actual numbers and such are in a script that is used to generate the sounds, which should be in repotools I believe |
| 18:38.34 | seanbright | ahh, nice |
| 18:38.50 | seanbright | sure enough... you're a smart dude |
| 18:38.50 | lmadsen | so you can look -- I had no idea what the numbers meant and how he got them, because I know nothing about FFT |
| 18:38.54 | seanbright | i don't care what russellb says |
| 18:38.59 | lmadsen | I build the sounds, so I know SOME stuff :) |
| 18:39.12 | lmadsen | but the actual knowledge is just the "what button to press" |
| 18:40.11 | seanbright | no, this is perfect |
| 18:40.13 | seanbright | thanks a bunch |
| 18:43.22 | lmadsen | np |
| 19:27.59 | seanbright | i can't type a ? in the asterisk cli? |
| 19:28.03 | seanbright | anyone else seeing that? |
| 19:28.09 | Qwell | ? == <TAB> |
| 19:28.16 | seanbright | seems like it |
| 19:28.22 | russellb | it's a feature |
| 19:28.26 | seanbright | ah, ok |
| 19:28.28 | seanbright | heh |
| 19:28.31 | Qwell | A silly and fairly useless one. |
| 19:28.39 | russellb | agreed |
| 19:28.53 | Qwell | ? by itself should be help, but more than that is...meh |
| 19:29.30 | Qwell | Or, maybe doing "queue show ?" would give the help for "queue show". Certainly not <TAB> though. |
| 19:31.15 | seanbright | the CLI needs all kinds of work |
| 19:31.19 | seanbright | but who has time for that? |
| 19:31.31 | seanbright | also: audiofilter ftw |
| 19:31.32 | Qwell | you do! |
| 19:31.42 | seanbright | my g729 moh sounds somewhat decent now |
| 19:31.55 | Qwell | gross |
| 19:32.08 | seanbright | iax2 connection to BZ |
| 19:32.20 | seanbright | not going to do anything high quality |
| 19:32.24 | seanbright | bandwidth is expensive |
| 19:47.37 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 20:10.15 | *** join/#asterisk-dev Jamuel (~Adium@209.116.43.2) |
| 20:50.04 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 20:50.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:10.49 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@2001:41b8:203:dc11:21c:23ff:fe20:991f) |
| 21:10.49 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 22:55.03 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |