Hi, Judy.
There are two (probably related) bugs here. One is that there's a bug that whenever IceTV sends all of your current timers (e.g. after a "Resend all timers"), the Beyonwiz does delete/recreate operations with the IceTV server on all timers in the list sent from the server, even ones that are unchanged by the new lot of "set timer" messages. As well as being triggered by "Resend all timers", this can also be triggered if an IceTV update fetch fails (e.g. because of a network problem). This bug is only apparent from looking at the debug logs either on the Beyonwiz or on the IceTV server. You'd normally not see any effect on the Beyonwiz user interface, other than it running a bit slower than it should.
The second bug is that it appears that sometimes when a delete/recreate operation is done for a timer, one or other part of the pair can fail. If the delete fails, you get two recording timers, one with the IceTV "star", and the other (the older one) without it. If the "recreate" fails, then the old timer loses its IceTV "star" and the new timer isn't created. I think you've seen both of those cases. This bug may also be being triggered by a network failure.
The possibility of the cause being a network dropout is why I asked about whether you were using WiFi to connect your T2.
I've been able to replicate the first bug. However, I tried forcing the first bug on a realistic timer load (47 timers - the timer load that was then current on our in-use T4) doing the unnecessary delete/recreate of all those timers 100 times over (yes, it was a bit tedious

without seeing any instance of the second bug. It may be that the second bug can only be triggered by a network problem.
My current state on this is that I've fixed the bug that causes unnecessary delete/recreates for IceTV timers on the Beyonwiz on my test version of the Beyonwiz IceTV plugin. That was relatively simple. On the way I also found two other minor and unrelated bugs and fixed them. I could not find any cause for the second bug other than the possibility of a networking error, either by stress-testing (as above), or by examining the code.
However, because the fix of the first bug will remove unnecessary delete/recreates I hope that the likelihood of the second error happening will be much reduced. I'm sorry that I can't promise more.
The current state is that I intended to test my modifications on our in-use T4 today, but other things have intervened. I will try to get that going on tomorrow. I'll also make the new version available to Daniel to try if he wants to.
Once I've run that for a few days without problems, I'll submit the fix to the code repository. From there it will need to wait until peteru accepts the changes and builds a firmware release containing them. He's very busy with other stuff at the moment, but I'll ask him if he could make time. In the short term, you may need to run public beta firmware for a while to take advantage of the changes. It will depend on how long it takes between having the changes in public beta to when they are released as official firmware.
Daniel - please get in touch if you'd like a patch kit with the changes.