Well, this all seems a bit strange! Can you post your code here for the test please? If you copy and paste the minimum test sketch, I can set it up and run it here and see what happens.
What puzzles me is:
It seems like your CHANGE trigger is being set to FALLING instead. Looking at the Mega2560 data sheet, edge triggers on the INTx pins only needs a single clock pulse to register. Assuming a 16 MHz clock, then that means that the edge only has to be present for 0.0625 microseconds.
What do you get if you run the code I provided yesterday?
Cheers,
Norm.
Bye! I apologize for the inactive period.
I have tried your code and it is very fast and works perfectly.
Following these tests: I have improved the efficiency of my code and now I have excellent results.
When there was an interrupt on PIN 18 and 19 if you remember I had multiple calls to the ISR function. I found that in these functions you must never put Serial.print or delay () because it can cause malfunctions like mine.
Now everything is working fine!
Thank you for your time 
No worries. We all have lives to live, things to do – that get in the way of playing with microcontrollers! 
When using interrupts, it’s best to keep the code in the interrupt handler as short as possible. For best results, in many cases, set a flag in the interrupt handler, and use that in the loop() to determine if an action requires carrying out.
Obviously, if all the interrupt handler is doing is turning on a relay or LED – because you can never have too many blinking LEDs – then just do it in the handler.
Well, that’s the advice we are given, however, it’s not quite as simple as “don’t do it”. It’s sometimes ok to call Serial.print from within an interrupt handler because all that does is to add the data “printed” to a buffer, if the buffer is full up, then the underlying write() function which write each data byte into the USART buffer, hangs up waiting for the buffer to free up some space. This is done by the interrupt handler which extracts data from the buffer and transmits it over the Serial transmit pin (D1). Unfortunately, when your interrupt handler is executing Serial.print() etc, and the buffer is full, interrupts are off and the buffer never empties! The sketch simply hangs up waiting for ever for the buffer to start to empty.
It is possible to call Serial.print() in an interrupt handler, but only if you never, ever fill up the buffer. Calling Serial.availableForWrite() might help.
Calling delay() on the other hand, is a definite no-no! As interrupts are off in your interrupt handler, then the Timer 0 Overflow interrupt no longer triggers, and it is this which updates the value for millis() and micros() and this is what delay() uses to count up the delay time. With interrupts off, millis() and micros() never progress, so delay() never returns.
HTH
Cheers,
Norm.