• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

RS Scheduled Event Not Working

Black Hole

May contain traces of nut
I have a couple of advanced rules on RS for my HDR4 to schedule recording ISIHAC (AKA 'Clue'), which show matching events, and show HDR4 is checking in, and yet the events have not been scheduled.

I've looked in rs.log, and it is full of "Error encountered, Error: 28 - Timeout was reached" messages, practically every time HDR4 was due to phone home, which seems like a smoking gun. So despite RS saying HDR4 was seen, it was not "usefully seen"!

What to do?
 

Attachments

Interesting. You are getting quite a few failures from the /mod/bin/rs binary, which in turn are not caught by the /mod/sbin/rs_process script.
The latter we can at least trap. The former are more tricky.
What happens if you run stuff manually e.g. rs -d9 cmd and rs -d9 push ?
I've just done that and got an unexpected error:
Code:
Sending TBL_RESERVATION schedule information to remote server.
Mon Dec  9 12:51:57 2024 Found ISO6937 string: 'Asia'
Mon Dec  9 12:51:57 2024 xconv failed = 'Asiah▒▒*73010F00B0AE576794BB9'
but this is nothing to do with your errors. Perhaps you could do the above and report any anomolous looking output.
Looking closer at my error, the string in the database is "\x10i7Asia", which is different to all the rest which start '\x15' which is UTF8 - I suppose that is broadcaster induced. I don't know why the conversion fails though. There is nothing contentious in the string in hex. - "10693741736961".
it is full of "Error encountered, Error: 28 - Timeout was reached" messages, practically every time HDR4 was due to phone home
But is that a local network problem or a server problem?
Apart from the outage on Sat., mine is reliable, which would seem to point the finger at your LAN.
 
But is that a local network problem or a server problem?
Apart from the outage on Sat., mine is reliable, which would seem to point the finger at your LAN.
I'm willing to accept this problem is local to me, but I don't think it's the LAN, more likely the WAN. Further investigation shows similar bursts of timeout log messages on all my machines, whether WiFi or HomePlug, and anyway I have no difficulty accessing the respective WebIFs.

There is at least a degree of correlation, but for some reason there are sections missing in the log when there should be an entry every 10 minutes. HD3 hasn't logged anything since May (I'll try a fix-flash-packages, but I thought I had done one of those not long ago... and RS reports HD3 as "seen"!). Sometimes the HomePlug units won't get through because the HomePlug network goes into isolation from time to time.

What happens if you run stuff manually e.g. rs -d9 cmd and rs -d9 push ?
Code:
HDRFOX4# rs -d9 cmd                                                                               
SQLite3: 3.46.1                                                                                   
Curl version: libcurl/7.63.0 OpenSSL/1.1.1d zlib/1.2.3                                            
String: bare&mac=dc:d3:21:17:85:0f&host=HDRFOX4&id=0e4a028b95154f71560fff9588632c0f               
HDRFOX4# rs -d9 push                                                                              
SQLite3: 3.46.1                                                                                   
Curl version: libcurl/7.63.0 OpenSSL/1.1.1d zlib/1.2.3                                            
QUERY: [select         ersvtype, nsttime, szsttime, nduration, erepeat, usevtid, szevtname, ucrecki
nd, uccridtype, szcrid, szfpbrecpath, szrecordedprogcrid, szeventtorecord, uslastrecordedevtid, len
gth(aulEventToRecordInfo) as accepted, channel.TBL_SVC.szSvcName, channel.TBL_SVC.usLcn, ulPreOffse
t, ulPostOffset, hex(aulEventToRecordInfo) as evlist, channel.TBL_SVC.usSvcId, ulslot from TBL_RESE
RVATION left join channel.TBL_SVC using (hsvc)]                                                   
Sending TBL_RESERVATION schedule information to remote server.                                    
Mon Dec  9 15:11:17 2024 Found ISO6937 string: 'The Archers'                                      
Mon Dec  9 15:11:17 2024 xconv failed = 'The Archers'                                             
Mon Dec  9 15:11:17 2024 Found ISO6937 string: '[MP3]'                                            
Mon Dec  9 15:11:17 2024 xconv failed = '[MP3]*fo] TEXT)'                                         
Mon Dec  9 15:11:17 2024 Found ISO6937 string: 'BBC Inside Science'                               
Mon Dec  9 15:11:17 2024 xconv failed = 'BBC Inside ScienceD'                                     
Mon Dec  9 15:11:17 2024 Found ISO6937 string: '[MP3]'                                            
Mon Dec  9 15:11:17 2024 xconv failed = '[MP3]*'                                                  
Mon Dec  9 15:11:17 2024 Found ISO6937 string: 'More or Less'                                     
Mon Dec  9 15:11:17 2024 xconv failed = 'More or Less'                                            
Mon Dec  9 15:11:17 2024 Found ISO6937 string: '[MP3]'                                            
Mon Dec  9 15:11:17 2024 xconv failed = '[MP3]*640100004800040030E1'                              
Mon Dec  9 15:11:17 2024 Found ISO6937 string: 'Sliced Bread'                                     
Mon Dec  9 15:11:17 2024 xconv failed = 'Sliced BreadcienceD'                                     
Mon Dec  9 15:11:17 2024 Found ISO6937 string: '[MP3]'                                            
Mon Dec  9 15:11:17 2024 xconv failed = '[MP3]*83D'                                               
Mon Dec  9 15:11:17 2024 Found ISO6937 string: 'The Infinite Monkey Cage'                         
Mon Dec  9 15:11:17 2024 xconv failed = 'The Infinite Monkey Cage30E1'                            
Mon Dec  9 15:11:17 2024 Found ISO6937 string: '[MP3]'                                            
Mon Dec  9 15:11:17 2024 xconv failed = '[MP3]*83D'                                               
Mon Dec  9 15:11:17 2024 Found ISO6937 string: 'Curious Cases'                                    
Mon Dec  9 15:11:17 2024 xconv failed = 'Curious CasesienceD'                                     
Mon Dec  9 15:11:17 2024 Found ISO6937 string: '[MP3]'                                            
Mon Dec  9 15:11:17 2024 xconv failed = '[MP3]*83D'                                               
Retrieved checksum from database, 2b53ba16fa8421184a74b6892c654b9e                                
Already up-to-date.                                                                               
QUERY: [select action, ersvtype, nsttime, szsttime, nduration, erepeat, usevtid, szevtname, ucrecki
nd, uccridtype, szcrid, szfpbrecpath, szrecordedprogcrid, szeventtorecord, uslastrecordedevtid, len
gth(aulEventToRecordInfo) as accepted, channel.TBL_SVC.szSvcName, channel.TBL_SVC.usLcn, ulPreOffse
t, ulPostOffset, hex(aulEventToRecordInfo) as evlist, channel.TBL_SVC.usSvcId, ulslot from pending
left join channel.TBL_SVC using (hsvc)]                                                           
Sending pending schedule information to remote server.                                            
Retrieved checksum from database, f1542f2f45448dd11571aeeb1494b3ee                                
Already up-to-date.                                                                               
HDRFOX4#

Could it simply be that the timeout isn't long enough for bad connections like mine?

Another thing: Why hasn't Clue now been scheduled, despite a manual update? Is it that the server thinks it's already been sent, even though the rs package gave up waiting for the response? If so, this process is too prone to communication errors, with no positive handshaking.
 
I've tried refreshing the rules, but I'm not seeing the matching events as pending – is there a delay before RS registers them?
 
Curious:

Is it correct that rs.log only seems to record events once a day unless an error occurs? If so, then not all phone-homes result in an error, just that in those cases the log says nothing:

Code:
24/09/2024 02:03:21 - Sending channel information to remote server.
24/09/2024 02:03:21 - Already up-to-date.
24/09/2024 02:06:14 - Sending disk information to remote server.
24/09/2024 02:06:14 - Error: 28 - Timeout was reached
24/09/2024 02:07:00 - Sending disk error information to remote server.
24/09/2024 02:07:00 - >>> Ok.
24/09/2024 14:52:20 - Error encountered, Error: 28 - Timeout was reached
25/09/2024 02:03:16 - Sending channel information to remote server.
25/09/2024 02:03:16 - Already up-to-date.
25/09/2024 02:05:48 - Sending disk information to remote server.
25/09/2024 02:05:48 -  Updating...
25/09/2024 02:06:45 - Sending disk error information to remote server.
25/09/2024 02:06:45 - >>> Ok.
26/09/2024 02:03:29 - Sending channel information to remote server.
26/09/2024 02:03:29 - Already up-to-date.
26/09/2024 02:05:59 - Sending disk information to remote server.
26/09/2024 02:05:59 -  Updating...
26/09/2024 02:06:21 - Sending disk error information to remote server.
26/09/2024 02:06:21 - >>> Ok.
27/09/2024 02:03:22 - Sending channel information to remote server.
27/09/2024 02:03:22 - Already up-to-date.
27/09/2024 02:05:46 - Sending disk information to remote server.
27/09/2024 02:05:46 -  Updating...
27/09/2024 02:06:10 - Sending disk error information to remote server.
27/09/2024 02:06:10 - >>> Ok.
28/09/2024 02:03:05 - Sending channel information to remote server.
28/09/2024 02:03:05 - Already up-to-date.
28/09/2024 02:05:16 - Sending disk information to remote server.
28/09/2024 02:05:16 -  Updating...
28/09/2024 02:05:26 - Sending disk error information to remote server.
28/09/2024 02:05:26 - >>> Ok.
29/09/2024 02:03:21 - Sending channel information to remote server.
29/09/2024 02:03:21 - Already up-to-date.
29/09/2024 02:05:15 - Sending disk information to remote server.
29/09/2024 02:05:15 -  Updating...
29/09/2024 02:06:06 - Sending disk error information to remote server.
29/09/2024 02:06:06 - >>> Ok.
30/09/2024 02:03:09 - Sending channel information to remote server.
30/09/2024 02:03:09 - Already up-to-date.
30/09/2024 02:05:20 - Sending disk information to remote server.
30/09/2024 02:05:20 -  Updating...
30/09/2024 02:05:45 - Sending disk error information to remote server.
30/09/2024 02:05:45 - >>> Ok.
01/10/2024 02:03:38 - Sending channel information to remote server.
01/10/2024 02:03:38 - Already up-to-date.
01/10/2024 02:05:14 - Sending disk information to remote server.
01/10/2024 02:05:14 -  Updating...
01/10/2024 02:06:02 - Sending disk error information to remote server.
01/10/2024 02:06:02 - >>> Ok.
02/10/2024 02:03:05 - Sending channel information to remote server.
02/10/2024 02:03:05 - Already up-to-date.
02/10/2024 02:05:52 - Sending disk information to remote server.
02/10/2024 02:05:52 -  Updating...
02/10/2024 02:06:19 - Sending disk error information to remote server.
02/10/2024 02:06:19 - >>> Ok.
03/10/2024 02:03:52 - Sending channel information to remote server.
03/10/2024 02:03:52 - Already up-to-date.
03/10/2024 02:05:43 - Sending disk information to remote server.
03/10/2024 02:05:43 -  Updating...
03/10/2024 02:06:26 - Sending disk error information to remote server.
03/10/2024 02:06:26 - >>> Ok.
Bus error
03/10/2024 22:51:03 - Error encountered, Error: 28 - Timeout was reached
Illegal instruction

What are these? Are they evidence that rs might be the source of some of my crashes?:

Code:
05/10/2024 02:04:03 - Sending channel information to remote server.
05/10/2024 02:04:03 - Already up-to-date.
05/10/2024 02:05:21 - Sending disk information to remote server.
05/10/2024 02:05:21 -  Updating...
05/10/2024 02:06:12 - Sending disk error information to remote server.
05/10/2024 02:06:12 - >>> Ok.
Segmentation fault
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {372.96 GiB} 83 {74.64 GiB}
Illegal instruction
05/10/2024 14:41:29 - Error encountered, Error: 7 - Couldn't connect to server
05/10/2024 14:51:26 - Error encountered, Error: 28 - Timeout was reached
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {372.96 GiB} 83 {74.64 GiB}
Bus error
06/10/2024 02:03:40 - Sending channel information to remote server.
06/10/2024 02:03:40 - Already up-to-date.
06/10/2024 02:06:06 - Sending disk information to remote server.
06/10/2024 02:06:06 -  Updating...
06/10/2024 02:06:13 - Sending disk error information to remote server.
06/10/2024 02:06:13 - >>> Ok.
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {372.79 GiB} 83 {74.81 GiB}
06/10/2024 14:52:47 - Error encountered, Error: 28 - Timeout was reached
Segmentation fault
07/10/2024 02:03:17 - Sending channel information to remote server.
07/10/2024 02:03:17 - Already up-to-date.
07/10/2024 02:05:18 - Sending disk information to remote server.
07/10/2024 02:05:18 -  Updating...
07/10/2024 02:06:13 - Sending disk error information to remote server.
07/10/2024 02:06:13 - >>> Ok.
Bus error
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {372.79 GiB} 83 {74.81 GiB}
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
Illegal instruction
08/10/2024 02:04:00 - Sending channel information to remote server.
08/10/2024 02:04:00 - Already up-to-date.
08/10/2024 02:06:03 - Sending disk information to remote server.
08/10/2024 02:06:03 -  Updating...
08/10/2024 02:06:21 - Sending disk error information to remote server.
08/10/2024 02:06:21 - >>> Ok.
Trace/breakpoint trap
Trace/breakpoint trap
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
Trace/breakpoint trap
09/10/2024 02:03:29 - Sending channel information to remote server.
09/10/2024 02:03:29 - Already up-to-date.
09/10/2024 02:05:41 - Sending disk information to remote server.
09/10/2024 02:05:41 -  Updating...
09/10/2024 02:06:43 - Sending disk error information to remote server.
09/10/2024 02:06:43 - >>> Ok.
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
10/10/2024 02:03:55 - Sending channel information to remote server.
10/10/2024 02:03:55 - Already up-to-date.
10/10/2024 02:05:54 - Sending disk information to remote server.
10/10/2024 02:05:54 -  Updating...
10/10/2024 02:06:45 - Sending disk error information to remote server.
10/10/2024 02:06:45 - >>> Ok.
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {371.5 GiB} 82 {76.1 GiB}
Illegal instruction
/mod/sbin/rs_process:88: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 88
    exec /mod/bin/rs cmd
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
10/10/2024 14:51:46 - Error encountered, Error: 28 - Timeout was reached
Trace/breakpoint trap
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {372.51 GiB} 83 {75.09 GiB}
11/10/2024 02:03:53 - Sending channel information to remote server.
11/10/2024 02:03:53 - Already up-to-date.
11/10/2024 02:06:00 - Sending disk information to remote server.
11/10/2024 02:06:00 -  Updating...
11/10/2024 02:06:49 - Sending disk error information to remote server.
11/10/2024 02:06:49 - >>> Ok.
12/10/2024 02:03:58 - Sending channel information to remote server.
12/10/2024 02:03:58 - Already up-to-date.
12/10/2024 02:05:36 - Sending disk information to remote server.
12/10/2024 02:05:36 -  Updating...
12/10/2024 02:06:28 - Sending disk error information to remote server.
12/10/2024 02:06:28 - >>> Ok.
/mod/sbin/rs_process:88: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 88
    exec /mod/bin/rs cmd
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
Trace/breakpoint trap
13/10/2024 02:03:47 - Sending channel information to remote server.
13/10/2024 02:03:47 - Already up-to-date.
13/10/2024 02:05:09 - Sending disk information to remote server.
13/10/2024 02:05:09 -  Updating...
13/10/2024 02:05:12 - Sending disk error information to remote server.
13/10/2024 02:05:12 - >>> Ok.
Trace/breakpoint trap
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {372.72 GiB} 83 {74.88 GiB}
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
Trace/breakpoint trap
14/10/2024 02:03:39 - Sending channel information to remote server.
14/10/2024 02:03:39 - Already up-to-date.
14/10/2024 02:06:02 - Sending disk information to remote server.
14/10/2024 02:06:02 -  Updating...
14/10/2024 02:06:17 - Sending disk error information to remote server.
14/10/2024 02:06:17 - >>> Ok.
Trace/breakpoint trap
/mod/sbin/rs_process:88: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 88
    exec /mod/bin/rs cmd
Trace/breakpoint trap
Trace/breakpoint trap
Segmentation fault
Trace/breakpoint trap
/mod/sbin/rs_process:57: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 74, in push
    pushds 1
  File "/mod/sbin/rs_process", line 57, in pushds
    exec /mod/bin/rs ds {447.6 GiB} {373.86 GiB} 83 {73.74 GiB}
/mod/sbin/rs_process:88: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 88
    exec /mod/bin/rs cmd
/mod/sbin/rs_process:66: Error: child killed by signal SIGSEGV
Traceback (most recent call last):
  File "/mod/sbin/rs_process", line 77
    push 1
  File "/mod/sbin/rs_process", line 66, in push
    exec /mod/bin/rs push
Trace/breakpoint trap
Trace/breakpoint trap
18/10/2024 14:21:12 - Error encountered, Error: 28 - Timeout was reached
19/10/2024 01:41:49 - Error encountered, Error: 28 - Timeout was reached
19/10/2024 09:11:59 - Error encountered, Error: 28 - Timeout was reached
25/10/2024 02:22:23 - Error encountered, Error: 28 - Timeout was reached
28/10/2024 16:20:09 - Error encountered, Error: 6 - Couldn't resolve host name
04/11/2024 17:52:02 - Error encountered, Error: 28 - Timeout was reached
15/11/2024 14:30:57 - Could not acquire lock.
20/11/2024 19:30:51 - Error encountered, <html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx</center>
</body>
</html>
22/11/2024 05:02:32 - Error encountered, Error: 28 - Timeout was reached
 
I'm willing to accept this problem is local to me, but I don't think it's the LAN, more likely the WAN.
Sometimes the HomePlug units won't get through because the HomePlug network goes into isolation from time to time.
Sounds like it's both then. Moving might be a blessing.
Mon Dec 9 15:11:17 2024 xconv failed = '[MP3]*640100004800040030E1'
So this is the same as what I get, which points the finger at a bug in the rs binary (or maybe the libxconv stuff).
Is it correct that rs.log only seems to record events once a day unless an error occurs? If so, then not all phone-homes result in an error
The 10 minute check-ins don't seem to generate any output, which is probably a good thing. Anything else that happens should get logged, regardless of the time. It's probably just that nothing is happening apart from the routine overnight update.
What are these? Are they evidence that rs might be the source of some of my crashes?
These are curious. I'm almost tempted to say you have a hardware problem. Segmentation violations are one thing, possibly software induced, but Illegal instruction, Bus error and Trace/breakpoint trap are probably not.
Does this unit do other weird things? Have you checked the obvious hardware stuff? If it's RAM going bad or something similar then it sounds terminal.

I'm afraid I can't answer any of your other questions about RS operation.
 
So this is the same as what I get, which points the finger at a bug in the rs binary (or maybe the libxconv stuff).
This is just some confusing debug, caused by non-null terminated strings in the latter, although really the former shouldn't be displaying it as the conversion was unnecessary (AKA 'failed' here).
It's fixed in the latest update.
 
Sounds like it's both then.
I know the HomePlugs are a problem, that's not news and not this problem.

These are curious. I'm almost tempted to say you have a hardware problem.
The unit works well enough in other respects, mainly used for grabbing Radio 4 and converting to MP3 for in-car listening (on a daily basis). Apart from RS, the only problems are when it crashes and I don't notice.

It's fixed in the latest update.
Is that a minor fix?

I'm afraid I can't answer any of your other questions about RS operation.
No, but I have pointed this thread at someone who can.
 
Shock!:

Code:
07/12/2024 19:43:50 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 19:53:53 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 20:04:48 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 20:14:57 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 20:24:24 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 20:34:29 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 20:43:58 - Error encountered, Error: 28 - Timeout was reached
07/12/2024 20:53:37 - Error encountered, Error: 28 - Timeout was reached
08/12/2024 13:00:51 - Error encountered, Error: 28 - Timeout was reached
09/12/2024 19:22:44 - Error encountered, Error: 28 - Timeout was reached
10/12/2024 08:11:48 - Processing command 'schedule auto'
10/12/2024 08:11:50 - *Schedule 6912/786/2/704/BBC Radio 4/1734373800/I'm Sorry I Haven't A Clue
10/12/2024 08:11:52 - *Trying source service/event ID.
10/12/2024 08:11:53 - _Found event - I'm Sorry I Haven't A Clue
10/12/2024 08:11:54 - _Successfully scheduled event.
10/12/2024 08:12:02 - push
10/12/2024 08:12:02 - Sending TBL_RESERVATION schedule information to remote server.
10/12/2024 08:12:02 -  Updating...
10/12/2024 08:12:02 - Sending skiplist information to remote server.
10/12/2024 08:12:02 - >>> Skipped 0.
10/12/2024 08:12:02 - Sending pending schedule information to remote server.
10/12/2024 08:12:02 - Already up-to-date.
10/12/2024 08:12:03 - ds 447.6 GiB 372.36 GiB 83 75.24 GiB
10/12/2024 08:12:03 - Already up-to-date.

Just got lucky I suppose. The trouble is, I now have a duplicated entry in the schedule, because my strategy of scheduling both Monday and the Sunday repeats no longer works - they used to have different S-CRIDs.
 
HD3 hasn't logged anything since May
This is a red herring. I trawled the logs again this morning, and checked what RS was reporting, for all machines, and found that sometimes the Diagnostics log viewer fails to display the whole log despite clicking the Reload button. I checked the logging is active by setting test recordings from RS.

I assume the display is assembled at the server (the 'FOX) with Jim, rather than in the browser using JS? If it were the latter, I could understand that the download of the log file got interrupted, but I don't know how to explain it if powered by Jim at the server.

HDR4 hasn't logged a timeout since Tuesday, but another machine has.
 
I assume the display is assembled at the server (the 'FOX) with Jim, rather than in the browser using JS?
The whole file is downloaded in to the browser by Jim, than paged though with JS.
Getting a partial log seems weird. You can test what the Jim is doing by issuing a command such as:
Code:
cd /mod/webif/html/log
QUERY_STRING="file=/mod/tmp/rs.log&dload=-" ./fetch.jim
which gives the HTML formatting, otherwise you can get the raw file by setting "dload=1" in the above command.
 
Back
Top