Paging stops working after system reboot

#1

I restarted my fpx distro 13 server today to make a time zone setting change. (not that it’s related) Afterwards paging stopped working. It attempts to page, I hear the tone, then it just hangs up. I set up a simple paging group with one extension for a test. Can anyone see what is wrong?

[[email protected] ~]# asterisk -rvvvvvvvvvvv
Asterisk 13.5.0, Copyright © 1999 - 2014, Digium, Inc. and others.
Created by Mark Spencer [email protected]
Asterisk comes with ABSOLUTELY NO WARRANTY; type ‘core show warranty’ for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type ‘core show license’ for details.

Connected to Asterisk 13.5.0 currently running on freepbx (pid = 2569)
– Connected line update to SIP/480-0000043c prevented.
– SIP/448-0000043d answered SIP/480-0000043c
– Channel SIP/448-0000043d joined ‘simple_bridge’ basic-bridge
– Channel SIP/480-0000043c joined ‘simple_bridge’ basic-bridge
> 0x7f5a0415b880 – Probation passed - setting RTP source address to 10.0.2.101:11784
> 0x7f59b86c7990 – Probation passed - setting RTP source address to 10.0.2.69:11794
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– Executing [[email protected]:1] Goto(“SIP/407-0000043e”, “app-pagegroups,05,1”) in new stack
– Goto (app-pagegroups,05,1)
– Executing [[email protected]:1] Macro(“SIP/407-0000043e”, “user-callerid,”) in new stack
– Executing [[email protected]:1] Set(“SIP/407-0000043e”, “TOUCH_MONITOR=1449063939.26065”) in new stack
– Executing [[email protected]:2] Set(“SIP/407-0000043e”, “AMPUSER=407”) in new stack
– Executing [[email protected]:3] GotoIf(“SIP/407-0000043e”, “0?report”) in new stack
– Executing [[email protected]:4] ExecIf(“SIP/407-0000043e”, “1?Set(REALCALLERIDNUM=407)”) in new stack
– Executing [[email protected]:5] Set(“SIP/407-0000043e”, “AMPUSER=407”) in new stack
– Executing [[email protected]:6] GotoIf(“SIP/407-0000043e”, “0?limit”) in new stack
– Executing [[email protected]:7] Set(“SIP/407-0000043e”, “AMPUSERCIDNAME=xxx”) in new stack
– Executing [[email protected]:8] GotoIf(“SIP/407-0000043e”, “0?report”) in new stack
– Executing [[email protected]:9] Set(“SIP/407-0000043e”, “AMPUSERCID=407”) in new stack
– Executing [[email protected]:10] Set(“SIP/407-0000043e”, “__DIAL_OPTIONS=Ttr”) in new stack
– Executing [[email protected]:11] Set(“SIP/407-0000043e”, “CALLERID(all)=“xxx” <407>”) in new stack
– Executing [[email protected]:12] GotoIf(“SIP/407-0000043e”, “0?limit”) in new stack
– Executing [[email protected]:13] ExecIf(“SIP/407-0000043e”, “0?Set(GROUP(concurrency_limit)=407)”) in new stack
– Executing [[email protected]:14] ExecIf(“SIP/407-0000043e”, “0?Set(CHANNEL(language)=)”) in new stack
– Executing [[email protected]:15] GotoIf(“SIP/407-0000043e”, “0?continue”) in new stack
– Executing [[email protected]:16] ExecIf(“SIP/407-0000043e”, “1?Set(__CALLEE_ACCOUNCODE=)”) in new stack
– Executing [[email protected]:17] Set(“SIP/407-0000043e”, “__TTL=64”) in new stack
– Executing [[email protected]:18] GotoIf(“SIP/407-0000043e”, “1?continue”) in new stack
– Goto (macro-user-callerid,s,29)
– Executing [[email protected]:29] Set(“SIP/407-0000043e”, “CALLERID(number)=407”) in new stack
– Executing [[email protected]:30] Set(“SIP/407-0000043e”, “CALLERID(name)=xxx”) in new stack
– Executing [[email protected]:31] Set(“SIP/407-0000043e”, “CDR(cnum)=407”) in new stack
– Executing [[email protected]:32] Set(“SIP/407-0000043e”, “CDR(cnam)=xxx”) in new stack
– Executing [[email protected]:33] Set(“SIP/407-0000043e”, “CHANNEL(language)=en”) in new stack
– Executing [[email protected]:2] Set(“SIP/407-0000043e”, “_PAGEGROUP=05”) in new stack
– Executing [[email protected]:3] GotoIf(“SIP/407-0000043e”, “1?:busy”) in new stack
– Executing [[email protected]:4] Set(“SIP/407-0000043e”, “DEVICE_STATE(Custom:PAGE05)=INUSE”) in new stack
– Executing [[email protected]:5] Gosub(“SIP/407-0000043e”, “app-paging,ssetup,1()”) in new stack
– Executing [[email protected]:1] Set(“SIP/407-0000043e”, “_SIPURI=”) in new stack
– Executing [[email protected]:2] Set(“SIP/407-0000043e”, “_ALERTINFO=Ring Answer”) in new stack
– Executing [[email protected]:3] Set(“SIP/407-0000043e”, “_CALLINFO=;answer-after=0”) in new stack
– Executing [[email protected]:4] Set(“SIP/407-0000043e”, “_SIPURI=intercom=true”) in new stack
– Executing [s[email protected]:5] Set(“SIP/407-0000043e”, “_DTIME=5”) in new stack
– Executing [[email protected]:6] Set(“SIP/407-0000043e”, “_ANSWERMACRO=”) in new stack
– Executing [[email protected]:7] Set(“SIP/407-0000043e”, “PAGE_CONF=1449063939794”) in new stack
– Executing [[email protected]:8] Return(“SIP/407-0000043e”, “”) in new stack
– Executing [[email protected]:6] Set(“SIP/407-0000043e”, “PAGEMODE=PAGE”) in new stack
– Executing [[email protected]:7] Set(“SIP/407-0000043e”, “PAGE_MEMBERS=442”) in new stack
– Executing [[email protected]:8] Set(“SIP/407-0000043e”, “PAGE_CONF_OPTS=1dqsxm”) in new stack
– Executing [[email protected]:9] Set(“SIP/407-0000043e”, “ANNOUNCEMENT=beep”) in new stack
– Executing [[email protected]:10] AGI(“SIP/407-0000043e”, “page.agi”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/page.agi
– Called [email protected]
– Executing [[email protected]:1] Wait(“Local/[email protected];2”, “1”) in new stack
– Executing [[email protected]:1] Wait(“Local/[email protected];2”, “1”) in new stack
– Called [email protected]
– Executing [[email protected]:1] Macro(“Local/[email protected];2”, “autoanswer,442”) in new stack
– Called [email protected]/n
– Executing [[email protected]:1] GotoIf(“Local/[email protected];2”, “1?knowndial”) in new stack
– Goto (macro-autoanswer,s,19)
– Executing [[email protected]:19] Set(“Local/[email protected];2”, “DIAL=SIP/442”) in new stack
– Executing [[email protected]:20] ExecIf(“Local/[email protected];2”, “0?Set(DIAL=DAHDI/442)”) in new stack
– Executing [[email protected]:21] GotoIf(“Local/[email protected];2”, “0?macro”) in new stack
– Executing [[email protected]:22] Set(“Local/[email protected];2”, “USERAGENT=PolycomSoundPointIP-SPIP_650-UA/4.0.3.7562”) in new stack
– Executing [[email protected]:23] ExecIf(“Local/[email protected];2”, “0?Set(USERAGENT=)”) in new stack
– Executing [[email protected]:24] ExecIf(“Local/[email protected];2”, “0?Set(CALLINFO=sip:broadworks.net;answer-after=0)”) in new stack
– Executing [[email protected]:25] ExecIf(“Local/[email protected];2”, “0?Set(ALERTINFO=Intercom)”) in new stack
– Executing [[email protected]:26] ExecIf(“Local/[email protected];2”, “1?Set(ALERTINFO=info=Auto Answer)”) in new stack
– Executing [[email protected]:27] ExecIf(“Local/[email protected];2”, “0?Set(ALERTINFO=ring-answer)”) in new stack
– Executing [[email protected]:28] ExecIf(“Local/[email protected];2”, “1?Set(__SIP_URI_OPTIONS=intercom=true)”) in new stack
– Executing [[email protected]:2] Set(“Local/[email protected];2”, “_DOPTIONS=b(autoanswer^s^1(info=Auto Answer,;answer-after=0))”) in new stack
– Executing [[email protected]:3] Dial(“Local/[email protected];2”, “SIP/442,5,A(beep)b(autoanswer^s^1(info=Auto Answer,;answer-after=0))”) in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
– SIP/442-0000043f Internal Gosub(autoanswer,s,1(info=Auto Answer,;answer-after=0)) start
– <SIP/407-0000043e>AGI Script page.agi completed, returning 0
– Executing [[email protected]:1] GosubIf(“SIP/442-0000043f”, “1?addheader,1(Alert-Info,info=Auto Answer)”) in new stack
– Executing [[email protected]:1] SIPAddHeader(“SIP/442-0000043f”, “Alert-Info: info=Auto Answer”) in new stack
– Executing [[email protected]:2] Set(“SIP/442-0000043f”, “PJSIP_HEADER(add,Alert-Info)=info=Auto Answer”) in new stack
[2015-12-02 08:45:39] ERROR[10586][C-000004b4]: res_pjsip_header_funcs.c:515 func_write_header: This function requires a PJSIP channel.
[2015-12-02 08:45:39] ERROR[10586][C-000004b4]: res_pjsip_header_funcs.c:515 func_write_header: This function requires a PJSIP channel.
– Executing [[email protected]:3] Return(“SIP/442-0000043f”, “”) in new stack
– Executing [[email protected]:2] GosubIf(“SIP/442-0000043f”, “1?addheader,1(Call-Info,;answer-after=0)”) in new stack
– Executing [[email protected]:1] SIPAddHeader(“SIP/442-0000043f”, “Call-Info: ;answer-after=0”) in new stack
– Executing [[email protected]:2] Set(“SIP/442-0000043f”, “PJSIP_HEADER(add,Call-Info)=;answer-after=0”) in new stack
[2015-12-02 08:45:39] ERROR[10586][C-000004b4]: res_pjsip_header_funcs.c:515 func_write_header: This function requires a PJSIP channel.
[2015-12-02 08:45:39] ERROR[10586][C-000004b4]: res_pjsip_header_funcs.c:515 func_write_header: This function requires a PJSIP channel.
– Executing [[email protected]:3] Return(“SIP/442-0000043f”, “”) in new stack
– Executing [[email protected]:3] Return(“SIP/442-0000043f”, “”) in new stack
== Spawn extension (from-internal, PAGE442, 1) exited non-zero on ‘SIP/442-0000043f’
– SIP/442-0000043f Internal Gosub(autoanswer,s,1(info=Auto Answer,;answer-after=0)) complete GOSUB_RETVAL=
– Called SIP/442
– Executing [[email protected]:11] Answer(“SIP/407-0000043e”, “”) in new stack
– SIP/442-0000043f is ringing
– Local/[email protected];1 is ringing
> 0x7f5a04111100 – Probation passed - setting RTP source address to 10.0.2.27:11796
– Executing [[email protected]:12] MeetMe(“SIP/407-0000043e”, “1449063939794,dqwxAG,”) in new stack
[2015-12-02 08:45:39] WARNING[10574][C-000004b1]: app_meetme.c:1657 build_conf: Unable to open DAHDI pseudo device
[2015-12-02 08:45:39] WARNING[10574][C-000004b1]: app_meetme.c:1657 build_conf: Unable to open DAHDI pseudo device
== Spawn extension (app-pagegroups, 05, 12) exited non-zero on ‘SIP/407-0000043e’
– Executing [[email protected]:1] ExecIf(“SIP/407-0000043e”, “1?Set(DEVICE_STATE(Custom:PAGE05)=NOT_INUSE)”) in new stack
– Executing [[email protected]:2] Answer(“Local/[email protected];2”, “”) in new stack
– Local/[email protected];1 answered
> Launching Wait(5) on Local/[email protected];1
– Executing [[email protected]:2] Answer(“Local/[email protected];2”, “”) in new stack
– Local/[email protected];1 answered
> Launching Playback(beep) on Local/[email protected];1
– <Local/[email protected];1> Playing ‘beep.gsm’ (language ‘en’)
– Executing [[email protected]:3] MeetMe(“Local/[email protected];2”, “1449063939794,xq,”) in new stack
== Parsing ‘/etc/asterisk/meetme.conf’: Found
== Parsing ‘/etc/asterisk/meetme_additional.conf’: Found
== Spawn extension (app-page-stream, s, 3) exited non-zero on ‘Local/[email protected];2’
– Executing [[email protected]:3] MeetMe(“Local/[email protected];2”, “1449063939794,xqA,”) in new stack
== Parsing ‘/etc/asterisk/meetme.conf’: Found
== Parsing ‘/etc/asterisk/meetme_additional.conf’: Found
== Spawn extension (app-page-stream, s, 3) exited non-zero on 'Local/[email protected];2’
freepbx*CLI>
Disconnected from Asterisk server

#2

Had to restart dahdi. Found that in another thread. Not sure why since I’m not using anything dahdi but it worked.

2 Likes
#3

Strange. Can you make sure it’s REALLY fixed by rebooting again when you get some time, and see if it’s broken again?

#4

Amazing. I was JUST testing paging and am having the EXACT same issue on 1 of my machines. Another machine is working fine. I was searching all over the place. I searched the error from the asterisk CLI;

app_meetme.c:1657 build_conf: Unable to open DAHDI pseudo device

and found this post.

I haven’t restarted dahdi or anything yet, but it seems odd we both have the exact same problem at the same time…
I should be able to reboot my box late tonight if freak can’t.

PS: I also don’t use dahdi (all VoIP). However from THIS thread it sound like paging uses meetme, which uses dahdi. So if something is wrong with dahdi it would effect paging. Or so I think (my understanding of dahdi is low).

#5

Realistically, you should probably be using confbridge, rather than meetme. You can change that in Advanced Settings.

#6

Any side effects to making that switch? I’m not up to speed on the current differences in functionality between the two but remember something years ago that there were things meetme did that confbridge didn’t. I’m looking at making use of the Conference Pro module for a group to setup random internal meetings, as well as people calling in through IVR (room number and PIN). Does confbridge handle all that stuff? Thanks.

#7

It should be fine. All new installs have used it.

#8

I don’t know why this says SOLVED now because it really isn’t solved. I just tested it again and after a reboot paging does not work. The work around is to restart dahdi. I’m going to file a bug.

#9

Here is the easiest way I have found to fix it…

amportal stop
amportal start

Below is a log of what happens when I do it…

[[email protected] ~]# amportal stop

Fetching FreePBX settings with gen_amp_conf.php…

!!!amportal is depreciated. Please use fwconsole!!!
forwarding all commands to 'fwconsole’
Running FreePBX shutdown…

Checking Asterisk Status…
Run Pre-Asterisk Shutdown Hooks
Restapps daemon was not running
XMPP Server was not running

Shutting down Asterisk Gracefully…
Press C to Cancel
Press N to shut down NOW
Stopping Asterisk…
120/120 [============================] 100%
Asterisk Stopped Successfuly

Running Post-Asterisk Stop Scripts
Wanrouter: No valid device configs found, if you have no Sangoma cards this is OK
Stopping DAHDi for Digium Cards
DAHDi Stopped
Running VQPlus Hooks
Stopping Queue Callback Daemon
Queue Callback Daemon Stopped
[[email protected] ~]# amportal start

Fetching FreePBX settings with gen_amp_conf.php…

!!!amportal is depreciated. Please use fwconsole!!!
forwarding all commands to 'fwconsole’
Running FreePBX startup…
Setting Permissions…
40387/40387 [============================] 100%
Finished setting permissions

Checking Asterisk Status…
Run Pre-Asterisk Hooks
Wanrouter: No valid device configs found, if you have no Sangoma cards this is OK
Starting DAHDi for Digium Cards
DAHDi Started
PagingPro daemon done
Running Sysadmin Hooks
Restarting fail2ban
fail2ban Restarted

Starting Asterisk…
100/100 [============================] 100%
Asterisk Started on 3819

Running Post-Asterisk Scripts
Running Restapps Hooks
Starting Restapps daemon
Restapps daemon done
Running VQPlus Hooks
Starting Queue Callback Daemon
Queue Callback Daemon Started
Running XMPP Hooks
Starting XMPP Server
XMPP Server Started
Stopping fail2ban: [ OK ]
Ensuring logfiles are presentStarting fail2ban: WARNING ‘action’ not defined in ‘php-url-fopen’. Using default one: ''
WARNING ‘action’ not defined in ‘lighttpd-auth’. Using default one: ''
WARNING ‘action’ not defined in ‘lighttpd-fastcgi’. Using default one: ‘’
[ OK ]

#10

I switched “conference room app” to app_confbridge from app_meetme and paging survives a reboot. I don’t know if anything else that depends on dahdi would work or not because I don’t know what else depends on dahdi. The conference room app help states “The app_confbridge application is considered ‘experimental’ with known issues” and this makes it a little scary but at least it works for now.

#11

Noticed the same as you. Something is wrong with dahdi/meetme on reboot. And confbridge says it is experimental, although I can confirm new installs use it by default (which is why my other newer installs didn’t see this problem) and has worked fine.

I would file a bug as well. Post it here if you can as well. Thanks.

#12

http://issues.freepbx.org/browse/FREEPBX-10941

#13

Wow! They closed the bug, told me to stop posting random logs in the ticket system and figure it out in the forums. Which is what I thought we did.

#14

Well, they closed it and told you to discuss it in the forums. Which, lets be honest, will lead nowhere. So I guess you should just move to confbridge or find a new PBX software.

I don’t get it. They can’t replicate for whatever reason, yet you and I both can make it occur repeatedly without fail. I will be on break for Christmas in a few weeks. I’ll spin up a current release and test and installing an older freepbx version, updating it to current release, and see if the issue shows up. If it does, I’m going to be pretty annoyed with this whole situation.

And here I though ticketing systems were made for reporting bugs in software. I don’t know what more they want short of telling them “here is the problem and how to fix it”. I mean, it’s pretty straight forward what is going wrong here and what the problem relates to. It’s right in the “random” log. And instead of saying, “can you provide this or that” they rather just close it and pretend the issue(s) don’t exist.

I don’t know what has been going on since the Sangoma merger but reporting anything as a bug seems to be greeted with a closing of the ticket and nothing being addressed. I’m STILL having UCP Node issues after updates even though it was “supposedly” fixed. But they don’t want to hear it and obviously it must be something I’m doing wrong (since running module updates seems to be a problem for FreePBX now). Vanilla installations (a whole bunch of them actually) all with the same exact problem, multiple people STILL posting they have the problem in the forums, but it’s not a bug…umk.

Yea, I’m a bit pissed off, I am. I’ve spend good money towards the FreePBX project. I just spend over 2k in commercial module licenses during the cyber sale alone. But whatever, I’m just going to give up on submitting anything as it is a waste of my time (what little I actually have).

#15

My guess is that they are under pressure to get tickets closed and don’t like seeing new tickets come in. I don’t know what else to do short of hiring someone to find the error in their code. I can replicate it. I gave them the logs of what happens during the failure and logs of what it takes to fix it. None of the logs were “random” as they claimed.

#16

My guess is that it is related to:-

http://issues.freepbx.org/browse/FREEPBX-10859

That one remains open , perhaps you should add your observances there.

#17

I’m not sure I feel comfortable commenting on bugs now. One person commented that they could reproduce the problem as well and they said “The ticket system is not a discussion system (that is why we have forums).”.

#18

@freak
If you read what @tm1000 indicated, it was that attempts by the dev team to reproduce this were unsuccessful. He said once there is a dianosis that translates into something that can be reproduced, by all means file a bug so we can take further action. There are many more eyes in the forums, and much more brain power available when there are what appear to be ambiguous or un-reproducable problems. We triage every issue and we have multiple engineers who’s full time job it is to develop, work the bugs, etc.
Part of managing a large project is to triage issues and apply the limited resources in the most efficient way possilbe. Problems like this are often solved much more quickly by asking that they be hashed out to where we can get reproducable and actionable issues that we can go after. We could have just left your ticket in the ticket system, and then it would simply stagnate. That wouldn’t do anyone any good. It’s entirely more productive to encourage further disussion here and one of the HUGE benefits of the code base being Open Source.

Thank you for pointing that out. The information is wrong and outdated and I’ve brought this up to the team. That was written a few years ago when app_confbridge was in fact new. In the supported versions of Asterisk, it is not only mainstream, but I believe we should no longer support app_meetme. I’ve already brought such up to the team and we will make the evaluation. We should have noticed this during FreePBX 13 development and simply removed it, but this was an oversight. At a minimum we will make sure app_confbridge is the default and the information is updated appropriately, and then remove app_meetme from the next version. The team will however deliberate if we should be removing it from 13 as an oversight for something that should have already been done.

So are you insinuating that there isn’t a community of people of all calibers here, including all the developers of the project, who don’t ineract in the forums, never provide help, never contribute to troubleshooting, finding bugs, etc.? Your very interaction in this thread and the feedback and help you’ve provided to @freak would seem to show the opposite.

Yup, that appears to be the case here. I can tell you from a decade of experience on this project that this happens often. It’s usually “impossible” to solve in the lab because there is something different. So we can have an engineer spend hours beating their head on the wall with no results while a lot of other bugs go un-worked, but that doesn’t make sense for the rest of the user base or us. When this happens, it’s usually solved by discussions in the forums. Sometimes it leads to a bug that gets reported and fixed, sometimes it’s a mis-configuration, external component, portions of the system not fully updated where the problem is already fixed, or other localized issues. We are very far from perfect, but with hundreds of thousands of systems out there, we’ve gotten reasonably good at also detecting when to “look harder” even if we can’t reproduce it in the lab. We do not ignore issues. When there are enough signs, between forum reports, tickets opened from multiple sources, our own support services, etc. we go beyond our own development and test systems to further diagnose issues ‘in the field’ where they can be reproduced. We do that based on data though, and there’s enough systems out there to get that data, we don’t do it because one individual is “a bit pissed off” and “is going to be pretty annoyed with this whole situation.” Our goal is to maximize the value for as much of the community as we can.

If you are going to make such bold statements, maybe you can back them up with data from the ticket system, after all, it’s completely transparent and the data is there for you to pull and either demonstrate that we have “lost our way” or otherwise show there may be a big difference between your perception and the reality of the situation. Given that I sit on our bug triage meeting every week, I can tell you that we assign out dozens and dozens of tickets constantly to be fixed, further triaged, dialoged with reporters to get more needed information, etc. Maybe I’m seeing what I want to see? Why don’t you go to the ticket system and see which way the scale tips since if it’s in the direction that you are claiming, I would very much like that corrected. However, I think you may find otherwise.

#19

Seriously what more could we have done in the forums? Two of us consistently reproduce the problem so I file a bug. I’m not sure what else is expected of us to troubleshoot this for you.

#20

we are not asking you to troubleshoot this for ‘us.’ It is the opposite, you are asking ‘us’ to troubleshoot this for you. This may very well end up being a bug that we need to fix. It may also just as likely be an external influence or change present on just some systems. Until root cause is found, we won’t know.

However, we tested this in the lab and we couldn’t reproduce it. So I’ll ask you a similar question: What more should we have done? Some of our option are, leave the ticket open but ignore it since we couldn’t reproduce it, leaving you the impression that somehting is being done. That one doesn’t sound great. Should we contact you and see if we can get on your system to determine if we can see what’s going on since you can reproduce it? Maybe, we do that, quite frequently as I’ve indicated, once we’ve seen enough clear evdience that there is something ‘systemic’ going on and it’s not just possibly one or two individuals, who, for all we know happen to have both installed the same ‘third party add on’ of some sort which cause the problem.

How about we suggest the issue get’s brought up in the forums. What might the outcome be here. Well for starters, maybe there’s a discussion which leads to you finding out that you would be better using app_confbridge and your immediate problem goes away. Hmm, not to bad. In the process, we find out that we messed up by leaving incorrect infromation about app_confbridge in the tolltip that justifiably made you nervous to use it when in fact, app_meetme should have gone away and that was our bad for missing that. So far, not a bad start. And, hmm, multipe developers from the project plus knwowledgable outside contributors are providing data like possible tickets it may be related to and their own ability to reproduce the problem. That sounds pretty useful as well, and that sort of dialog is not something that occurs in the ticket system.

What else might happen. Well maybe ten other people come along, vs. one other, and say hey that happens to me also. That has happened before, sometimes resulting in a solution from the community as a result of the open source process which we love because it’s one less thing we have to solve. Or sometimes resulting in us seeing the type of data that I indicated, and thus further leading to take the time to get onto an outside system where the problem does occur so we can try to track down the issue since we can’t in the lab. That is sometimes the outcome, and has repeated itself countless times in the past, and is one of the many reasons it is so useful to bring such discussions to the forums.

And lastly, whether the problem ends up as a bug that we utlimately fix, or whether it ends up being user error, external components, or many other influences, it often gets solved and the solutions expressed in the forum and then, guess what, all that energy that was expended by the various people who contibuted to help solve the problem gets indexed by google and the next person show comes along with the same problem and searches for a solution has a very strong chance of finding the help that they need as a result of the community efforts to help each other.

So … sorry for the slight “attitude” here that I clearly expressed, but comments like “us troubleshoot this for you” need to be put in a bit of perspecitve. But I also hope you can see through your frustration, which I’m truly sorry that you have gone through, and realize that there are reasons and good intentions for such requests, and some pretty descent outcomes as well.