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

    This upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

'Visual' not displaying correctly

peterworks

Ye Olde Bowler
My 'Visual schedule' looks like this this morning (both machines):
Capture02-02-2019-10.51.10.jpg
The 'Recording List' is fine.
Is this a hangover from yesterdays RS problems or something new ?

Edit: Looks like 'Skip' in RS isn't functioning properly either
 

MymsMan

Ad detector
Yes, the Visual problem is a Beta bug that was spotted yesterday

Don't think Skip problem has been identified before
 
OP
peterworks

peterworks

Ye Olde Bowler
Thanks MymsMan - I'm trying to keep up...

Following logs may help ?
Recmon log:
Recmon log.jpg

Webif error log:
Webif error log.jpg
 

af123

Administrator
Staff member
It seems to be an existing bug but one that does not get triggered with the previous version of jim. I don't have time today to look at it unfortunately but I'll try later this evening. It should only be affecting people who have opted in to the beta packages.
 

prpr

Well-Known Member
For the first, are you on rs version 1.5.1-2 ?

For the second, it seems to be some weird bug in the Jim clock scan function.
It fails on the Humax by returning -1. It fails on my Linux PC as well, but in a different way - generating a large negative number.
The Jim code implementing this doesn't seem to have changed for a while, but it definitely works properly on 0.77 and fails on 0.78

Anyway, here's a work-around for rs for now (and a better, more obvious, more efficient way):
Code:
humax# diff -u /mod/webif/html/sched/visual/index.jim~ /mod/webif/html/sched/visual/index.jim
--- /mod/webif/html/sched/visual/index.jim~
+++ /mod/webif/html/sched/visual/index.jim
@@ -306,7 +306,7 @@
        set tomorrow {}

        # Midnight today.
-       set day [clock scan "00:00:00" -format "%T"]
+       set day [expr [clock seconds] - [clock seconds] % 86400]

        set elength [llength $events]
        set eindex 0
 
Last edited:

prpr

Well-Known Member
OK, found it. Here's the commit that changed the behaviour: https://repo.or.cz/jimtcl.git/commitdiff/f85a6e7c5a6387d721f19335984a838863237131
Specifically, these bits are of interest:
Code:
static int clock_cmd_scan(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
{
     char *pt;
     struct tm tm;
-    time_t now = time(0);
+    /*time_t now = time(NULL);*/

and

-    /* Initialise with the current date/time */
-    localtime_r(&now, &tm);
+    /* Set unspecified fields to 0, e.g. HH:MM becomes 00:00 */
+    memset(&tm, 0, sizeof(tm));
+    /* But this is 1-based */
+    tm.tm_mday = 1;
Docs. for strptime(), which is called immediately afterwards, say:
In principle, this function does not initialize tm but stores only the values specified. This means that tm should be initialized before the call.
This is especially important if you are going to feed the result back into mktime(), which is exactly what happens.

But is it a bug in Jim or not? That is debatable.
The documentation is hardly explicit about what it's supposed to do.
IMO, you are somewhat abusing clock scan and getting it to do something it probably wasn't really designed to do, and the result you wanted was just a side-effect that happened to work at some points in time, and now doesn't.
My solution above would appear to be the correct one regardless.

I expect there might be a DST problem here though, but I think there always might have been?
(The Jim docs. don't even mention the -gmt option on clock scan).

Probably also worth reviewing these:
html/xepg/index.jim: set tt [clock scan \
lib/rsv.class: set stamp [clock scan $spaced -format "%Y %m %d %H %M %S"]
lib/rsv.class: set today [clock scan 00:00:00 -format "%T"]
 
Last edited:

/df

Active Member
OK, found it. Here's the commit that changed the behaviour: https://repo.or.cz/jimtcl.git/commitdiff/f85a6e7c5a6387d721f19335984a838863237131
...
Docs. for strptime(), which is called immediately afterwards, say:

This is especially important if you are going to feed the result back into mktime(), which is exactly what happens.

But is it a bug in Jim or not? That is debatable.
I think it's a bug. The doc for the Jim clock command says:
Code:
 ...
clock format seconds ?-format format?

    Format the given time (seconds since the epoch) according to the given format. See strftime(3) for supported formats. If no format is supplied, "%c" is used.

clock scan str -format format

    Scan the given time string using the given format string. See strptime(3) for supported formats.
...
It looks as if it was decided that these would be more accurate inverses if the default time for scanning was the Epoch, even though callers would almost never want that and would in fact expect the previous behaviour where the default values were based on the current localtime. If I want to convert some time in 1970 I'd expect to have to mention 1970 in the time string.

In the new code, setting tm_mday is a bit pointless since it should be set when mktime is called and canonicalizes the struct tm, but the is_dst member ought to be set to a negative value (since strptime provides no way to specify the DST setting).
The documentation is hardly explicit about what it's supposed to do.
IMO, you are somewhat abusing clock scan and getting it to do something it probably wasn't really designed to do, and the result you wanted was just a side-effect that happened to work at some points in time, and now doesn't.
My solution above would appear to be the correct one regardless.
Even if it would have been reasonable to expect the clock scan approach to work, I can't disagree with that.
I expect there might be a DST problem here though, but I think there always might have been?
...
There always is one.
 

MontysEvilTwin

Well-Known Member
This issue may be unrelated to the above, but since carrying out the latest beta package updates (including RS) one of my units is no longer communicating with the RS server. I tried running 'rs/checkin' but got the following response:
Code:
>>> Beginning diagnostic rs/checkin

Running: rs/checkin
/mod/sbin/rs_process:62: Error: child killed by signal SIGSEGV
in procedure 'push' called at file "/mod/sbin/rs_process", line 76
at file "/mod/sbin/rs_process", line 62


>>> Ending diagnostic rs/checkin
 

MontysEvilTwin

Well-Known Member
As post #5... are you running rs 1.5.1-2 ?
Yes, RS 1.5.1-2 is installed.
EDIT. Sorry I was on 1.5.1-1 not 1.5.1-2. I was looking on the wrong machine. After updating, running 'rs/checkin' worked. Sorry about that.
 
Last edited:

MymsMan

Ad detector
I am not sure what Web interface version: 1.4.4-6 was intended to fix but it hasn't corrected the Visual display problem
 

af123

Administrator
Staff member
I am not sure what Web interface version: 1.4.4-6 was intended to fix but it hasn't corrected the Visual display problem
It wasn't intended to - 1.4.4-7 should do that.
+ set day [expr [clock seconds] - [clock seconds] % 86400]
Thanks prpr! There's a small race condition in this and since Jim will use integer arithmetic unless one of the operands is decimal, I went for this:
https://github.com/hummypkg/webif/commit/b9bf4fc5d39aef9de405b6ad7b2beccc4af36bc6
 
Top