Doubled up recording

[csutak40]

Thanks, Judy. What Daniel's given me from your information and logging information from IceTV is enough to go on.

Is your Beyonwiz on a WiFi network connection or on wired Ethernet? The problem appears to be being triggered by network dropouts.

I am on wired Ethernet
Another question.  Can I delete the  doubled up recordings, or should I keep them until you figure it out?

[prl]

You can delete any double recordings and any duplicated timers that aren't marked with the blue IceTV "star".

[csutak40]

You can delete any double recordings and any duplicated timers that aren't marked with the blue IceTV "star".

Hmm.  This caused me to have a look at the timers.  There ARE some doubled up timers there, where only one has the blue IcetV star, however there are also some single timers without the star.  What does that mean?

[IanL-S]

I had doubling up on one of my T2 some weeks back. Relatively certain not happening with U4. I have ethernet connection, not wifi, but I recall having some other network issues about the same time (caused by power outage).

Ian

[prl]

You can delete any double recordings and any duplicated timers that aren't marked with the blue IceTV "star".

Hmm.  This caused me to have a look at the timers.  There ARE some doubled up timers there, where only one has the blue IcetV star, however there are also some single timers without the star.  What does that mean?

One thing it means is that I was missing some information about the problem. I though that the visible issue was that you'd end up with doubled (or multiple) recordings of the same show, with all but one without the "IceTV star". I was puzzled by that because I thought that the underlying cause might also sometimes leave recordings without the star and no duplicates, and now I know that it does.

The problem underlying this is a bit nasty, because it seems to be a two-step thing.

• The enabling bug is that when IceTV sends a full list of timers, rather than just the ones that have changed since the last update, all timers are processed as though they have changed, even if they haven't.
• The visible bug is that sometimes that only part of the update process (delete old PVR recording timer/add updated recording timer) is done.

I can easily replicate part 1 of the problem, but I haven't been able to replicate part 2. The hint from the screenshot may help me replicate part 2 of the problem. If I can do that I can be more certain about whether I've fixed the bug completely. Fixing part 1 alone would probably help with reducing how often part 2 happens, but that would leave everyone with this weird bug that happens very infrequently.

Another oddity is that some people seem to see this problem quite a bit (like yourself), but others (like me) pretty much never see it. That means that there's something to do with the particular usage patterns between the two groups that can trigger the problem. One thing that can trigger both part 1 and part 2 of the bug is a network dropout, which is why I asked about whether you have WiFi.

BTW: I'm sure you've worked this out already, but the simplest thing to do in cases where you have a timer for a recording, but it's not marked with the blue star, just leave it to record, unless its times are wrong enough that your padding won't take care of it.

[csutak40]

BTW: I'm sure you've worked this out already, but the simplest thing to do in cases where you have a timer for a recording, but it's not marked with the blue star, just leave it to record, unless its times are wrong enough that your padding won't take care of it.

Yeah, that's what I've been doing.
Incidentally, about to change to NBN, wonder if that will improve things?

[IanL-S]

Incidentally, about to change to NBN, wonder if that will improve things?
[/quote]

Depends on the version of nbn - FTTH is best, and FTTN is the worst (can be worse than ASDL). As far as I can work out FTTC should be better. HFC theoretically should be as good as FTTH (in short term), but some (few?) users are having problems with modem rebooting (and generally causing havoc). The cause can be hard to pin down, making it difficult in some cases to resolve. On the other hand, Telstra HFC is much more reliable and does not exhibit these issues. The only outages I have had recently have been due to power failures or network maintenance (latter probably related to work for nbn).

[csutak40]

Incidentally, about to change to NBN, wonder if that will improve things?

Depends on the version of nbn - FTTH is best, and FTTN is the worst (can be worse than ASDL). As far as I can work out FTTC should be better. HFC theoretically should be as good as FTTH (in short term), but some (few?) users are having problems with modem rebooting (and generally causing havoc). The cause can be hard to pin down, making it difficult in some cases to resolve. On the other hand, Telstra HFC is much more reliable and does not exhibit these issues. The only outages I have had recently have been due to power failures or network maintenance (latter probably related to work for nbn).
[/quote]
It will be FTTC  It is ready to be installed, just going through my emails to change all the ones that are registered with my ISP as I intend to go to a different RSP
There is something going on with my current router (and it isn't the router - tested another) when doing a speed test, it often crashes during the upload test.  Spent hours on the phone with TPG, got nowhere. Naturally, it is working fine ATM :-) https://www.speedtest.net/result/8067558958.png
BTW,  I really think it must have something to do with old timers not being deleted.
Just started watching the Blacklist and I saw there were two recordings, which I presumed was correct (they often show two episodes)  Turns out it wasn't :-)

[prl]

Incidentally, about to change to NBN, wonder if that will improve things?

It may. I don't really have a "smoking gun" for the exact triggers for the problem. The unnecessary delete/recreate of the timers can also be triggered by a Send all timers from the IceTV side, but I don't yet know how it goes from that issue to the messed up timer lists.

[csutak40]

Just for something different.  >:(  It is now happening on the T2 as well (hardly record anything on that)

[prl]

I don't think there's anything about the bug that would restrict it to one Beyonwiz model. The number of IceTV recordings you have for a device may influence how often the problem happens.

[csutak40]

Have you gotten any further with this Peter?
It is still happening.  Rather, not so much doubling up as shows being recorded under a different name (the name is the show I had scheduled, but the actual show recorded is something different.)  No way of knowing of course if the show was on at a different time and I've missed it or just got cancelled
For instance (just got around to watching it today) Changing Rooms supposedly recorded on Friday and Saturday at 7.30, but what actually recorded was Graham Norton and Ambulance Australia. (no great loss with this particular show ;D)  Come to think of it, Graham Norton also recorded under its correct title, watched that days ago.
Quite possibly Changing Rooms has been axed (not really surprised  :D) as it is not scheduled at all for this week
Another thing that I am not sure about...  Just watched Counterpart that was on last Thursday.  I am convinced that I've missed an episode, as things just weren't making sense  :P  I seem to remember that one of the "problem" shows the previous week was Counterpart

[prl]

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.

[csutak40]

Thank you, Peter.  I should be changing to NBN (and a new router) in the next week or two, so will be intrested to see if anything changes (for the better or worse :-\)

[prl]

Since you're getting FTTC delivery of NBN, you'll probably get reasonably reliable networking.