Does the I2C library still lock up?

I have an issue with a board I designed where it will be communicating with an LED driver and then suddenly lock up.

I am aware this is likely due to noise in the data lines. I'm not looking for help resolving that. The design is already finalized. I just want it to recover gracefully from the error.

I am also aware there are other I2C libraries out there, but its unclear which ones are good and which are not. For example there is a software I2C library and it says it's faster than another library called I2Cmaster, yet the latter uses hardware calls, and the former's specified max data rates don't look anywhere near I2C's max throughput. I don't really need the fastest library out there and I may even set the speed lower just to help with data corruption if I encounter that issue, but I'd prefer to use a library the uses the hardware and is fast. I have audio playing at the same time as I'm transmitting data and I don't know if that's going to mess up a software implementation.

If I can, simply modifying the wire library might be the ideal solution for me.

I did notice the 1.0.1 version of the Wire library I'm using (I am using the 1.0.1 IDE for this project because that's what it was designed on and I don't want to have to update it and create a new 1284P boards setup just so I can use the newest version) has a slightly different write function. I don't know if the change is supposed to solve this issue or not though:

// if we're in a repeated start, then we've already sent the START
  // in the ISR. Don't do it again.
  //
  if (true == twi_inRepStart) {
    // if we're in the repeated start state, then we've already sent the start,
    // (@@@ we hope), and the TWI statemachine is just waiting for the address byte.
    // We need to remove ourselves from the repeated start state before we enable interrupts,
    // since the ISR is ASYNC, and we could get confused if we hit the ISR before cleaning
    // up. Also, don't enable the START interrupt. There may be one pending from the 
    // repeated start that we sent outselves, and that would really confuse things.
    twi_inRepStart = false;			// remember, we're dealing with an ASYNC ISR
    TWDR = twi_slarw;				
    TWCR = _BV(TWINT) | _BV(TWEA) | _BV(TWEN) | _BV(TWIE);	// enable INTs, but not START
  }
  else
    // send start condition
    TWCR = _BV(TWINT) | _BV(TWEA) | _BV(TWEN) | _BV(TWIE) | _BV(TWSTA);	// enable INTs

  // wait for write operation to complete
  while(wait && (TWI_MTX == twi_state)){
    continue;
  }

New version:

// if we're in a repeated start, then we've already sent the START
  // in the ISR. Don't do it again.
  //
  if (true == twi_inRepStart) {
    // if we're in the repeated start state, then we've already sent the start,
    // (@@@ we hope), and the TWI statemachine is just waiting for the address byte.
    // We need to remove ourselves from the repeated start state before we enable interrupts,
    // since the ISR is ASYNC, and we could get confused if we hit the ISR before cleaning
    // up. Also, don't enable the START interrupt. There may be one pending from the 
    // repeated start that we sent outselves, and that would really confuse things.
    twi_inRepStart = false;			// remember, we're dealing with an ASYNC ISR
    do {
      TWDR = twi_slarw;				
    } while(TWCR & _BV(TWWC));
    TWCR = _BV(TWINT) | _BV(TWEA) | _BV(TWEN) | _BV(TWIE);	// enable INTs, but not START
  }
  else
    // send start condition
    TWCR = _BV(TWINT) | _BV(TWEA) | _BV(TWEN) | _BV(TWIE) | _BV(TWSTA);	// enable INTs

  // wait for write operation to complete
  while(wait && (TWI_MTX == twi_state)){
    continue;
  }

I'm gonna try this new code out on my project tomorrow, but I thought I'd ask before I wasted time on something that won't fix it.

I tested a Due as the I2C master and a Mega 2560 as the slave, and they communicated without fail for 4 days. I was using IDE V1.6.8. Just FYI.

edit: ...and yes, I was using a logic level converter. The Due is 3.3v, and the Mega is 5v.