| 01:26.10 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:26.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:01.52 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 04:35.33 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe93:fa45) |
| 04:41.34 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 07:08.21 | *** join/#asterisk-dev schmidts (~schmidts@vie-086-059-105-021.dsl.sil.at) |
| 07:08.23 | schmidts | good morning |
| 08:03.02 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e9b2:5df8:b4c:86b1) |
| 08:49.40 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 09:22.38 | *** join/#asterisk-dev Tim_Toady (~fuzzy@194.50.55.200) |
| 10:13.43 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 10:39.54 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 10:49.33 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:49.33 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:19.39 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 11:19.40 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 11:38.40 | *** join/#asterisk-dev italorossi (~italoross@189.124.196.68) |
| 12:19.09 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 12:19.10 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:24.49 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 12:24.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:44.54 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:44.54 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:49.08 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 13:40.40 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-usgzdxtkuxvnkind) |
| 13:44.47 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 13:51.53 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 13:55.13 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xrqgzssuggpkjbkz) |
| 14:19.21 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-nmyxlqabrmouitbz) |
| 14:19.21 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:20.44 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 14:58.19 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:58.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:01.04 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 15:01.04 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 15:26.10 | seanbright | sruffell: when feeding /dev/dahdi/transcode samples, if i end up with a short read, (let's say i only get 159 samples before EOF on my input file), should i zero pad to 160 before sending to the device? |
| 15:28.51 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-dfhdfhhxyxtafjen) |
| 15:33.57 | Juggie | i'd say yes, assuming the dsp would know that its silence |
| 15:35.24 | seanbright | i guess my real question is, would it still encode 159 samples |
| 15:35.32 | seanbright | no point in memset()ing if i don't have to |
| 15:35.50 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:37.18 | Juggie | good question |
| 15:37.25 | Juggie | you'd have to see how it handles it when a call ends |
| 15:37.50 | Juggie | does it throw away the last bunch <160 |
| 15:37.51 | Juggie | etc |
| 16:00.28 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:00.28 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:04.12 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:04.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:05.03 | sruffell | seanbright: yes |
| 16:07.38 | sruffell | the driver doesn't currently calculate samples as a function of forrmat and number of bytes.... |
| 16:12.27 | seanbright | so yes, i have to send multiples of 160 bytes if i expect to be able to read() anything |
| 16:12.39 | seanbright | ? |
| 16:14.06 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:14.10 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:40.31 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 16:56.09 | seanbright | sruffell: is there a maximum amount of in flight data that the card can handle? |
| 16:56.26 | seanbright | how many packets can i write before i need to start reading? |
| 16:57.09 | sruffell | seanbright: it's limited by system memory.... |
| 16:57.23 | Juggie | seanbright asks a lot of questions :) |
| 16:58.09 | sruffell | although I'm not sure if the firmware can get innundated. |
| 16:58.28 | seanbright | it doesn't appear so |
| 16:58.34 | seanbright | Juggie: sorry to bother you |
| 16:58.50 | sruffell | it doesn' appear to be limited by system memory? |
| 17:00.49 | seanbright | it doesn't appear the the firmware likes being innundated |
| 17:00.50 | seanbright | :-) |
| 17:01.37 | sruffell | you should just get a mismatch between packets sent and packets received? The firmware should just drop them, right? |
| 17:02.03 | seanbright | correct |
| 17:02.20 | seanbright | 9 frames is where i'm topping out |
| 17:02.24 | sruffell | ok..that makes sense. The network interface is probably able to shuttle data faster than the DSP can encode / decode it. |
| 17:02.56 | sruffell | the *driver* won't drop any packets.... |
| 17:03.19 | sruffell | It'll just back them up on the command list if the network interface is still transferring: |
| 17:03.20 | sruffell | https://github.com/sruffell/dahdi-linux/blob/master/drivers/dahdi/wctc4xxp/base.c#L1629-1636 |
| 17:03.53 | seanbright | gotcha |
| 17:04.17 | seanbright | i'm writing a (very clunky) dahdi_transcode command line program |
| 17:04.30 | seanbright | started with the easy phase-locked approach |
| 17:04.41 | seanbright | now trying to get a O_NONBLOCK version to work |
| 17:04.42 | seanbright | :-) |
| 17:04.50 | seanbright | but i think i'm there, although the code is horrendous |
| 17:04.51 | seanbright | heh |
| 17:06.38 | sruffell | heh…. bad code isn't technical debt, it's an unheged option call. No point in paying any more costs upfront if the call never is going to come in. |
| 17:06.59 | sruffell | http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ |
| 17:07.03 | Qwell | I don't know about you, but I'm definitely going to short that position. |
| 17:07.10 | rmeyerriecks | seanbright: neat, can't wait to see it |
| 17:07.57 | rmeyerriecks | sruffell: sruffell says that and he still hates on my bad code |
| 17:08.28 | file | hates on rmeyerriecks like it's going out of style |
| 17:08.29 | sruffell | if it's intended to be committed to DAHDI…the call will come in... |
| 17:08.30 | file | it's the cool thing to do |
| 17:09.01 | Qwell | file: don't be silly - it'll never go out of style. |
| 17:12.55 | russellb | sruffell: nice link |
| 17:13.02 | mjordan | very good article |
| 17:19.24 | sruffell | seanbright: I'll accept that what the firmware is capable of handling in terms of in-flight packets is something the driver should take care of and not push up to user space…… so….sorry your're having to figure this out. |
| 17:24.35 | seanbright | no sweat |
| 17:54.02 | seanbright | rmeyerriecks: http://pastebin.com/z2UcmzR8 |
| 17:54.18 | seanbright | this is my first time actually writing code that uses select()... so be nice |
| 17:54.21 | seanbright | :-) |
| 18:30.24 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 18:30.24 | *** mode/#asterisk-dev [+o ChanServ] by rajaniemi.freenode.net |
| 18:51.51 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-81-244.user.veloxzone.com.br) |
| 19:07.58 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 19:07.59 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 19:08.38 | rmeyerriecks | seanbright: looks good to me |
| 19:08.56 | rmeyerriecks | seanbright: sruffell and I have talked about making a utility like this a couple times before |
| 19:09.18 | sruffell | nods |
| 19:09.26 | sruffell | <— is slightly embarassed it's not already in tools. |
| 19:09.44 | sruffell | I think someone on the mailing list said they were doing the same thing….like 2 years ago. |
| 19:10.42 | pabelanger | seanbright: line 60, invert and return 0 to reduce indentation :) |
| 19:14.03 | seanbright | on reviewboard now |
| 19:15.23 | sruffell | seanbright: 3 years ago… http://thread.gmane.org/gmane.comp.telephony.pbx.asterisk.user/234718/focus=234841 |
| 19:15.43 | seanbright | that's with the software codec though |
| 19:16.02 | seanbright | at least that is what he said |
| 19:16.07 | rmeyerriecks | seanbright: yay. It will be the first thing I bring in after I get dahdi-tools migrated to git |
| 19:16.27 | sruffell | no..I think he made a standalone tool to "file convert" from a separate process from Asterisk.... |
| 19:16.31 | sruffell | that's how I read it. |
| 19:16.37 | seanbright | ah |
| 19:16.42 | sruffell | (file convert works now by the way....) |
| 19:16.48 | seanbright | yeah i saw that |
| 19:16.53 | seanbright | but what i want to do is this: |
| 19:17.42 | seanbright | mpg123 http://some-audio-stream.com | sox-to-ulaw | dahdi_transcode -e9 - - |
| 19:17.49 | seanbright | and use that as a MoH source |
| 19:17.58 | sruffell | ahh... |
| 19:18.04 | sruffell | yeah…that would have been different. |
| 19:18.35 | sruffell | so you only take the transcoding hit once, as oppossed to once for each connected channel? |
| 19:18.51 | seanbright | correct. and only use a single license |
| 19:19.01 | sruffell | nods |
| 19:19.04 | seanbright | instead of 1 for each of my agents sitting in MusicOnHold() |
| 19:19.05 | sruffell | that looks useful. |
| 19:19.17 | file | don't encourage him! |
| 19:20.13 | sruffell | starts chanting |
| 19:20.18 | sruffell | sean bright sean bright |
| 19:20.25 | seanbright | i feel encouraged! |
| 19:21.26 | rmeyerriecks | seanbright is on a roll, I've got a few jira issues he could work on :OP |
| 19:21.45 | seanbright | i no longer feel encouraged |
| 19:21.47 | seanbright | heh |
| 19:22.27 | sruffell | http://25.media.tumblr.com/tumblr_lz3gd4LugV1r6i3cdo1_500.jpg |
| 19:22.43 | sruffell | who's the downer now? |
| 19:23.04 | rmeyerriecks | wah wah |
| 19:35.34 | rmeyerriecks | tzafrir_laptop: Any luck with the sysfs bug? Sorry if you've already synced with sruffell about this. |
| 19:35.53 | tzafrir_laptop | looking into it now |
| 19:46.43 | JunK-Y | jrose_atDigium: sorry for the french translation, my son was sick the past few days. |
| 19:47.04 | jrose_atDigium | Oh, it's no problem. |
| 20:00.50 | tzafrir_laptop | rmeyerriecks, if you configured, say, 4 dynamic spans, dahdi_cfg starts off by issueing DAHDI_DYNAMIC_DESTROY on 4 spans, right? |
| 20:01.53 | rmeyerriecks | tzafrir_laptop: Looking |
| 20:02.11 | sruffell | tzafrir_laptop: FYI…that happened even without dynamic spans. I just set it up that way so that we could be using the exact same config. |
| 20:02.22 | sruffell | But I first saw it just loading the wct4xxp driver. |
| 20:02.27 | sruffell | on a 2.6.32 kernel.... |
| 20:02.49 | tzafrir_laptop | hmmm.... |
| 20:02.53 | sruffell | didn't happen on the 2.6.18 kernels, and the 2.6.32 test machines had an error which was misleading Russ before the commit... |
| 20:03.23 | tzafrir_laptop | I tested that configuration with dynamic spans yesterday on 2.6.18, and it worked fine. |
| 20:03.34 | tzafrir_laptop | 2.6.32 - crashes (oops) |
| 20:03.45 | sruffell | yeah…ok…that's what we're seeing too. |
| 20:03.47 | tzafrir_laptop | in the DAHDI_DYNAMIC_DESTROY |
| 20:03.52 | sruffell | oh... |
| 20:03.53 | sruffell | hmm. |
| 20:04.05 | sruffell | let me try again... |
| 20:04.26 | tzafrir_laptop | What happened if you had 6 dynamic spans and now want to configure only 4? You'll destroy only 4? |
| 20:08.01 | sruffell | nods |
| 20:08.26 | sruffell | that's in dahdi_cfg…it only destroys numdynamic spans…which it determines from the number of dynamic spans configured. |
| 20:11.06 | sruffell | tzafrir_laptop: same error but with TE800 on 2.6.32-5-686 |
| 20:11.06 | sruffell | https://gist.github.com/4348158 |
| 20:15.25 | tzafrir_laptop | Can you reproduce it with debug=255 (or 128) ? |
| 20:16.58 | sruffell | yeah..one sec… (I had done that before but didn't link) |
| 20:24.21 | sruffell | https://gist.github.com/6866d0e9e267a971c2e7 |
| 20:34.15 | tzafrir_laptop | for whatever reason that file remains there from an unclean startup. I figure it would now take a reboot to get rid of it |
| 20:37.51 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:37.52 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:39.09 | sruffell | yes…I always power cycle between tests. |
| 20:57.52 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 20:58.10 | *** join/#asterisk-dev tm1000 (~tm1000@provisioner.net) |
| 21:21.09 | *** join/#asterisk-dev philippel_mac (~p_lindhei@199.59.105.144) |
| 21:21.25 | philippel_mac | mjordan: ping you there |
| 21:29.18 | mjordan | philippel_mac: yup, for the next 30 min or so |
| 21:30.02 | philippel_mac | hey I'm just curious if you guys are aware that call recording (mix monitor) is broken in 10.11.0 and has been broken since at least 10.9.0 and maybe heartier? |
| 21:30.10 | philippel_mac | earlier |
| 21:30.25 | philippel_mac | it works on 1.8.19 and 11.1 |
| 21:30.57 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 21:30.57 | *** mode/#asterisk-dev [+o ChanServ] by rajaniemi.freenode.net |
| 21:30.59 | mjordan | hm. MixMonitor itself? |
| 21:31.34 | mjordan | 10.11 should reasonably coincide with 11.1, and there aren't any major differences between the two versions, so that's pretty odd that it would be broken between the two |
| 21:31.38 | philippel_mac | I haven't investigated it in detail … ultimately it's mix monitor, here's a forum post on it but I know it's been a problem for a while I was looking into it several weeks ago |
| 21:31.47 | philippel_mac | let me find one post |
| 21:31.50 | mjordan | sure |
| 21:31.57 | philippel_mac | http://www.freepbx.org/forum/freepbx/general-help/asterisk-log-files-warning-file-c-no-such-format#comment-58505 |
| 21:32.09 | philippel_mac | that's a recent post |
| 21:32.25 | philippel_mac | I know I had tested it with queues and conferencing and it was broken there also |
| 21:32.37 | philippel_mac | so it seems it's an underlying issue with mixmonigtor |
| 21:32.53 | philippel_mac | I can say for sure from the testing and rechecking I've done there is nothing weird being passed in for the format |
| 21:33.04 | philippel_mac | they have been 'wav' on the tests I looked at |
| 21:33.31 | mjordan | No such format 'Ãó' |
| 21:33.33 | mjordan | that's messed up |
| 21:33.45 | philippel_mac | and in general, not something that has changed in freepbx either, it just started up not working some time around 10.9.0 and I was also surprised that it worked on 1.8 and 11 but not 10.11.0 |
| 21:33.57 | mjordan | mind filing an issue and linking it? I'd like to make sure we at least get it fixed for the last version of 10 |
| 21:33.59 | philippel_mac | yeah it's messed up, seems like some sort of memory leak/overwriting corruption happening |
| 21:34.03 | mjordan | yeah |
| 21:34.19 | mjordan | possibly just garbage in the file extension char * |
| 21:34.24 | philippel_mac | and that is not consistent by the way .. sometime it is ??? and other things |
| 21:34.32 | mjordan | smells like nothing in the string |
| 21:34.50 | mjordan | if you get it filed I'll make it a blocker for 10.12 |
| 21:35.02 | mjordan | that way at least the final release in Asterisk 10 doesn't have that broken |
| 21:35.11 | philippel_mac | ok let me see about getting it filed or having someone file it as I'm running off in a sec here |
| 21:35.19 | mjordan | heh - i know the feeling :-) |
| 21:35.30 | philippel_mac | yeah having that broken in the final release of 10 would not be good |
| 21:35.47 | mjordan | I'll look for it and if it doesn't come across asterisk-bugs in the next few days I'll make something for it - just probably won't have all the details we'll need |
| 21:36.19 | mjordan | strange that the tests are passing for that. We have ConfBridge tests that use MixMonitor and they actually check that recorded files are created with something written in them |
| 21:36.42 | mjordan | there's specific MixMonitor tests as well, so whatever's causing it might be slightly different than what the tests are using to set up the file path to record |
| 21:36.44 | seanbright | the only relevant change i see is the change from alloca -> ast_alloca |
| 21:37.16 | seanbright | http://svnview.digium.com/svn/asterisk/branches/10/apps/app_mixmonitor.c?r1=370184&r2=370643 |
| 21:37.27 | mjordan | seanbright: if that were causing it I'd almost expect there to be bigger problems |
| 21:37.44 | seanbright | i tend to agree |
| 21:38.36 | seanbright | that code is weird anyway... why are we adding 3 instead of 2? |
| 21:38.38 | seanbright | oh well |
| 21:39.54 | file | I just did a quick test from the CLI on 10 SVN and it worked |
| 21:42.08 | mjordan | seanbright: I'm not sure I ever thought about calling multiple AGIs in the h extension :-) |
| 21:42.30 | mjordan | seanbright: to work around that, you could use hangup handlers |
| 21:42.59 | mjordan | hm. Maybe. |
| 21:43.05 | seanbright | in 1.8? |
| 21:43.10 | seanbright | that'd be sexy |
| 21:43.18 | seanbright | but i'll pass on backporting :-) |
| 21:43.39 | philippel_mac | mjordan: https://issues.asterisk.org/jira/browse/ASTERISK-20834 |
| 21:43.44 | mjordan | thanks |
| 21:43.59 | seanbright | as for the call to alloca, that should be a +2 and not a +3, right? or am i missing something |
| 21:44.07 | philippel_mac | given that is works in 1.8 and 11.1 not surprising it may be fixed in 'trunk' which is always a good thing :) |
| 21:44.07 | tzafrir_laptop | sruffell, on 2.6.32 we get the error: |
| 21:44.11 | tzafrir_laptop | sysfs: cannot create duplicate filename '/devices/dynamic:loc:0/span-1/dahdi/dahdi!channels!1!1/subsystem |
| 21:44.31 | sruffell | nods |
| 21:44.41 | philippel_mac | mjordan: anyhow I did not put a lot of deal but I can tell you I spent some time going over it in details a few weeks ago, rechecking that nothing changed in freepbx and that we were not doing something stupid |
| 21:44.41 | tzafrir_laptop | On 2.6.18 we have "dahdi:" instead of "dahdi/", and I figure that this is why it works |
| 21:44.44 | sruffell | that's what I see…regardless whether using dynamic spans or real (™) spans. |
| 21:44.50 | sruffell | ahh. |
| 21:45.12 | philippel_mac | at first I thought it may have been some weird localization issue in freepbx that was screwing up the format extension :) didn't turn out to be that... |
| 21:45.16 | mjordan | seanbright: seems like it would be 2 |
| 21:45.22 | rmeyerriecks | omg how did he do the tm symbol, its magic |
| 21:45.32 | sruffell | takes no credit |
| 21:45.37 | sruffell | Adium did it automagically for me. |
| 21:45.39 | mjordan | philippel_mac: the one thing I'm curious about is how the MixMonitor is getting set up |
| 21:45.56 | sruffell | and yes..I use Adium still and not console-chat-1989 |
| 21:46.07 | file | sruffell, barbaric |
| 21:46.11 | mjordan | we might need the dialplan snippet leading up to it. I can't play around with it to see if I can't reproduce it - if nothing else, I can rule out how we set it up in the existing test suite tests |
| 21:46.19 | philippel_mac | mjordan: it depends on whether it's a straight call to it, whether it's a conference, queue, etc since they all have different ways to set it up |
| 21:46.24 | sruffell | oh, and I'm on a paleo diet too. so there. |
| 21:46.31 | mjordan | good point, and since its failing on all... .weird. |
| 21:46.38 | rmeyerriecks | sruffell: That's cool if you want to use a gui for your stuff I guess. |
| 21:46.43 | sruffell | lol |
| 21:46.50 | sruffell | collars....popped |
| 21:47.10 | philippel_mac | yeah … I mean I can show you the dialplan that leads up to it, we have a subroutine that gets called for all types that sets up the recording and you pass in what type you are setting it up for |
| 21:47.14 | mjordan | tjat |
| 21:47.17 | mjordan | that'd be cool |
| 21:47.23 | philippel_mac | the underlying foundation is the same but for some things like queues |
| 21:47.23 | seanbright | philippel_mac: what version of asterisk is that log snippet from? |
| 21:47.31 | philippel_mac | it's weird cause some of it is in the queues.conf file ... |
| 21:47.51 | philippel_mac | :( I don't know I got it off the off the forum |
| 21:48.11 | philippel_mac | I could dig through my own log file where I just tested it on 10.11.0 and add it |
| 21:48.13 | seanbright | ling 517 of app_mixmonitor is no where near mixmonitor_save_prep() |
| 21:48.18 | seanbright | in 10 SVN |
| 21:48.40 | file | I have a badddd feeling |
| 21:49.01 | seanbright | they make meds for that |
| 21:49.41 | file | it's 10-digiumphones |
| 21:50.04 | file | I am fairly certain the problem is isolated to that |
| 21:51.13 | seanbright | ahh |
| 21:52.22 | file | confirmed |
| 21:53.13 | seanbright | r365297... i'm calling it |
| 21:53.37 | mjordan | rut roh |
| 21:54.43 | philippel_mac | mjordan: ok added a fuller trace from 10.11.0 specifically as well as the sub-record-check subroutine that gets called |
| 21:58.13 | file | **(ext++) = '\0'; |
| 21:59.27 | file | 11 differs. |
| 22:06.51 | file | 'tis incrementing the wrong pointer |
| 22:07.00 | seanbright | is setting *ext = "raw" correct there either? |
| 22:07.55 | seanbright | the caller passes in ext and uses it once _prep has returned |
| 22:08.15 | seanbright | isn't "raw" effectively stack allocated? |
| 22:09.27 | seanbright | void somefunc(char **foo) { *foo = "hello"; } char *foo; somefunc(&foo); printf("%s\n", foo); |
| 22:09.40 | seanbright | i feel like that is broken |
| 22:09.42 | seanbright | but what do i know |
| 23:00.09 | tzafrir_laptop | sruffell, as of kernel 2.6.19, the kernel actually checks if that symlink operation succeeds |
| 23:00.21 | tzafrir_laptop | f86db396ff455ed586751d21816a1ebd431264e5 |
| 23:01.07 | tzafrir_laptop | It turns out that setting both class and bus for the channel is not a good idea. And in fact, all things work if we just remove the 'class' |
| 23:01.49 | sruffell | ahh... |
| 23:02.03 | sruffell | that makes sense. Since class is deprecated now in favor of bus. |
| 23:02.27 | sruffell | I was looking http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=drivers/base/bus.c;h=aa685a20b64931ecad43549f98b953178a2e8626;hp=4d22a1d10a1c5bda88c552edf6a80d6bdb299f88;hb=f86db396ff4;hpb=370226449ced358e52d198081120826ef52c166b you posted and it didn't jump out at me. |
| 23:03.02 | sruffell | hate to post and run…but…I'll be back later tonight. |
| 23:09.31 | tonyclewis | mjordan: on that recording issue |
| 23:09.41 | tonyclewis | yes the RPMs we use are from digiumphone |
| 23:09.47 | tonyclewis | not normal 10 |
| 23:10.01 | tonyclewis | which is why i bet it happens in 10 and not 1.8 or 11 |
| 23:47.52 | mjordan | tonyclewis: yeup |
| 23:47.56 | mjordan | we'll get it fixed |
| 23:47.59 | mjordan | and now I have to run |
| 23:48.53 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-nmyxlqabrmouitbz) |
