vicidial.org

When agents are making calls at random some will see that the recording file on their screen shows "5" instead of the recording file name. For example on a call an agent took earlier today it showed

Code: Select all

RECORDING FILE:
5
RECORD ID: 8600052


However when I looked up the lead in the list it showed the recording file as 20131118-183747_1001. As far as we can tell this happens to random leads with nothing in common. One thing we did notice though is that it seems to happen to the lead again if it shows up once, although it doesn't always hit that lead twice. If it has happened to a lead before it will most likely show up on that lead again. We have tried to look for something they have in common but have been unable to see the common link. Anyone seen this or have any ideas on what it could be. We tried clearing out the list and reloading it thinking there maybe something wrong with the list but it is still occuring.

First guess is that you got some data that contains bad characters that the agent interface cant handle,
look for comma ( , ) or ampersand ( & ) in the lead data.

are you running a translated agc or the original?

look for errors in vicidial_mysqli_errors.txt and similar files in the www dir agc and vicidial
if you don't find any then you could try to write your own error logging and place it in on an appropriate place in vicidial.php

All the data should be clean I can look at the lead data for the ones in question. the odd part is we use the current time and agent name so it should read datatime_agent# as the recording file. it also look find if you look in the modify lead page. I will check for errors

for a test, change the recording filename back to stock. if that fixes it, consider changing the order of the filename you require (which may help...). there may be a truly odd coincidence occurring because of a filename collision.

compile a list of "these filenames refused to show", get at least 20 so you can search for "oddities" or a recurring theme in them.

fun problem to hunt down (from a technical standpoint, that is). linux is full of them. lol

I know this is an old thread but I still haven't been able to track and kill this gremlin. I have checked and the filename appears be correct. I am going to do some testing tonight to see what I can find. I am thinking it may have something to do with the tinydate / date variable getting messed up. Not sure why in the world it would default the whole string to 5 though

I have been chasing this issue down for a while now and keep coming up empty handed. I also setup a virtual machine to do some testing and even with a VICIdial virtual machine with nothing done to it I still seem to have this issue. If I check everywhere else I don't seem to see any issues and the recording filename shows correct. The only two places it shows 5 are the dispo URL and the agent's actual screen. Anyone have any ideas where to look or what to check.

Also do anyone know exactly where these are being pulled from? I am thinking I may need to start tracing it back.

*** I did find a piece of code to have an alert popup with all the data from vdc_db_query.php that vicidial pulls so I enabled that and am still trying to do some debugging.

other than "i think something is broken", we have nothing to bite into here. no real way to help.

when you say "fresh virtual system has same problem", what I'm NOT seeing is an exact detail of what precise problem there is and if you are able to reproduce it. when you reach that level, it'll be fixable. even without the fix, an exact problem statement in a fresh virtual box must include deep details for us to be able to get our teeth into it.

complete call path, date/time/filename (full for each) log entries from /var/log/astguiclient and /var/log/asterisk/messages ... possibly the agi logs, anything with deep detail and a chronicle of a single call gone bad.

Sorry for the lack of detail. This one kinda has me scratching my head and clawing at it to see what I can find. The issue I am having is that in the VICIdial agent screen it shows "5" for the Recording File at complete random. It will also do that when it passes the data to the dispoURL. The part that is making this so hard to track though is that every other place I can think to look it shows the Recording File perfect.

Last night I dug into it more and played with the VDC_query php script that if I am understanding right is ran by the javascript and used to hit the database. I enabled the popup for alert(xmlhttp.responseText); and it popped up the data after each call. The interesting part is that I never saw 5 as the Recording File there and from what I understood that is where it is pulling the information for the recording file.

Not sure that helps anyone help me but that is what is happening. I setup a virtual machine and put a couple list through it dialing and it did the same thing. Showed 5 for the recording file in the agent screen then showed the right information in the DB and everywhere else.

Since this happens with no one else ... perhaps you should be looking at how your system may differ from everyone else. Browser? Addons?

I have been looking at this and activated some of the debug features in the vicidial.php script. I can't seem to find anything in our setup that is It would seem that we are getting an error from vdc_dbquery of "Log Not Entered". This has been moved from just a annoyance to now real concern as it seems there may be some sort of DB connection issue going on.

Perhaps you should post the actual error instead of a vague reference to it. Probably helpful ... (and a couple lines above it, perhaps to show what may have caused the error ...)

I know this old and I wanted to post back our solution. Our was by no means a true track down of what was happening but it was effective none the less. The error we got when I turned on debugging was as follows "log not entered", followed by some data. The error is what comes back from vdc_db_query.php as "log not entered". I never found out why or what caused this, but it then pulls "5" as the filed name of the recording. I solved this by adding an if then before the code that updated the recording file name. If the recording ID was going to be updated to "5" it uses the value from when the call started and doesn't update the log. The code is below. All I did was tell it not to update the recording filename if it was going to make it a 5.

Code: Select all

                         if (MDlogRecorDings_array[2] != 5){
                        var RecDispNamE = MDlogRecorDings_array[2];                  
                        last_recording_filename = MDlogRecorDings_array[2];
                        if (RecDispNamE.length > 25)
                           {
                           RecDispNamE = RecDispNamE.substr(0,22);
                           RecDispNamE = RecDispNamE + '...';
                           }
                        document.getElementById("RecorDingFilename").innerHTML = RecDispNamE;
                        document.getElementById("RecorDID").innerHTML = MDlogRecorDings_array[3];
                        }
                        else
                        {
                  //   alert(xmlhttp.responseText);
                        }
                        }

Good postback. Hopefully no one else will ever need it, but if they do ... maybe it'll save them some hair pulling. LOL

I think I fixed this this weekend in svn/trunk, it was a display error, not actually changing the filename to "5".