Ice log displays errors

[grampus]

This may be a bit long winded. Apologies


Attachment from U4 Ice log

I have been getting error reports on each scheduled or unscheduled fetch.
The file is the latest from the Ice log.
I was getting all the errors shown but was unable to recover.
I have 2 devices a T3 and a U4 currently the U4 is showing the errors but I seem to recall that some time ago I had these on the T3
The only thing I can recall is that mostly I could resolve these by a re config of Ice'

But to go to extremes this time, I reloaded the U4 firmware from USB (19.3 20210119)
Reconfigured from scratch
Then resent all timers via the Ice website
With the results above.
Points to note that all my timers were sent and installed in the box OK.
The errors shown seem to point the some problem maybe at the Ice server end handling updates to a timer series database.
I have been in touch with Ice support, at this time they cant bring any light to the problem, but say that they aren't seeing any reports from other U4's in the network.
Suggested reconfig Ice, and /or reload U4 s/w
Has been done.
My T3 hasn't hiccuped with this error for some time.
Any thought would be appreciated

[prl]

That's a server-side error. It could be caused by an error on the Beyonwiz side, but unless you happen to have had debug logging enabled when the error happened, that's all the information that there will be on the Beyonwiz side.

Unless you have a debug log, I suggest that you repost on the IceTV forum in the Beyonwiz section [ETA: I now see that you've already contacted IceTV].

If you have a debug log, I'm happy to have a look at it, but it may not have anything useful.

[grampus]

Although I have rebooted, and found that a fetch from Ice worked fine this time,

But I will still attach logs
Probably academic

Enigma2-1970-01-01_10-00-35.log

(53.98 KiB) Downloaded 79 times

enigma2_execution.log

(111 Bytes) Downloaded 88 times

[grampus]

Since a reboot this morning I have had about 5 automatic fetches with no errors.

[Grumpy_Geoff]

Not IceTV related, but -
I think you've forgotten to switch to the beta feed server

[grampus]

tks,
I generally wait until a USB update is available.
Sometimes swing both ways.

[prl]

Enigma2-1970-01-01_10-00-35.log

I assume that this log shows IceTV fetches where there were no errors?

Since your U4 is networked, I'd have expected the timestamp in the log name to reflect the actual time the log started. Having the time not set when the enigma2 starts and the log file is created means that older log files are likely to get overwritten.

[grampus]

Tks Peter,
Yes.
I believe you are correct.
As I said I think all academic.
No errors reported since

Ice support responded with a thought that it was an internal error, or at least that they way I would like to read it

Looking at our logs this looks like a weird error where the beyonwiz is updating timers that don't need an update, but for some reason our server is sending a 500 because it is trying to save a new series recording for a one off timer, but the timer is already set, so it gets an error from the database that there is already a series recording setup for this particular one off timer. We'll look into it tomorrow

[prl]

Ice support responded with a thought that it was an internal error, or at least that they way I would like to read it

Looking at our logs this looks like a weird error where the beyonwiz is updating timers that don't need an update

Except where a user manually changes a timer, the Beyonwiz will only attempt to create or update timers that have been sent to the Beyonwiz by IceTV with action "record" (or more strictly, where the action is not "forget", but the documentation says that there are only two actions: "forget" and "record").

If none of the relevant details (channel, name, start, duration, event id) are changed, then the Beyonwiz will still send a response back with state "pending" (set to record) and message "Timer already up to date 'timer name'".

That behaviour hasn't changed for a long time.