Sorry but the i2c_t3 library is only for the Teensy 3.0/3.1 devices. It won't work on AVR parts at all.
Not sure on your problem without more diagnostics of what is going on. Things that can hang the bus are if it thinks it is busy (SCL held low), or if it is blocked from sending a START/STOP (either SDA or SCL held low). This can happen if the Master/Slaves get out of sync due to missed clocks (bad wiring, bad pullups, etc).
Another way a Slave can be made to hang the bus is if a Master reads from it, but does not end the read with a NAK. If the Slave outputs a low on SDA as its last output then the bus will hang due to inability of Master to send START/STOP. A poorly made Slave I2C could possibly be made to do this also if it were made to transmit blocks of X bytes, but the Master terminated the read after reading less than X bytes. If you have access to a logic analyzer then a capture might indicate what is going on. If not, then try testing the SDA/SCL to see if either is held low when it gets stuck.
Not sure on your problem without more diagnostics of what is going on. Things that can hang the bus are if it thinks it is busy (SCL held low), or if it is blocked from sending a START/STOP (either SDA or SCL held low). This can happen if the Master/Slaves get out of sync due to missed clocks (bad wiring, bad pullups, etc).
Another way a Slave can be made to hang the bus is if a Master reads from it, but does not end the read with a NAK. If the Slave outputs a low on SDA as its last output then the bus will hang due to inability of Master to send START/STOP. A poorly made Slave I2C could possibly be made to do this also if it were made to transmit blocks of X bytes, but the Master terminated the read after reading less than X bytes. If you have access to a logic analyzer then a capture might indicate what is going on. If not, then try testing the SDA/SCL to see if either is held low when it gets stuck.