No, it will have just have (almost) 2 minutes of the 2nd channel, linked with the .hmt from the current (ie first) channel.
This won't actually play, as the program/channel ids in the hmt won't match those in the stream. This is why you have to wait at least as long back on the first channel, so the unwanted bit gets overwritten, and the bit you wanted becomes the second "section" in the buffer.
At some point I plan to change the behavior from "capture second section" to "capture second section with ids that match the current hmt", then at least you wouldn't have to wait, and won't be possible to end up with non-playing recordings with mismatched ids.
For those who are interested and like mucking about on the command line, the new option in nicesplice is "-tsr <num>" where num is the section of the tsr to grab. It finds "sections" by looking for differences in the frame timestamps that are over a threshold.
eg to get the current buffer you use something like
nicesplice -in /media/drive1/.tsr/0 -out outfile -tsr 0
Its up to the caller to make sure that the ids in 0.hmt matches the section being captured. The magic folders script backs up 0.hmt every few seconds and uses that backup if 0.hmt doesn't exist (as is the case when playing a recording).