[webif] Web Interface 1.4.x

[Black Hole]

I'll give it a try.

 

[Black Hole]

So the service_id is an inadequate key. The interface to the 7-day EPG needs to pass the LCN and the search query needs to use the LCN. That means modifying the EPG class to implement searching by LCN, or filtering out records with non-matching LCNs from the returned list of events in webif/html/epg/service.jim.

Without doing that the low-numbered channels could be made to work better. The Humongous query defaults to order by channel_num, start. But when the 7-day EPG is being populated, the query is run with a different sort order strftime('%%H%%J', start, 'unixepoch', 'localtime'), strftime('%%M', start, 'unixepoch'). So we could put the channel_num back like this:

--- webif/html/epg/service.jim
+++ webif/html/epg/service.jim.new
@@ -30,7 +30,7 @@
 
 set records [epg dbfetch dump \
     -service $service \
-    -sort "strftime('%%H%%J', start, 'unixepoch', 'localtime'), strftime('%%M', start, 'unixepoch')" \
+    -sort "channel_num, strftime('%%H%%J', start, 'unixepoch', 'localtime'), strftime('%%M', start, 'unixepoch')" \
     -debug 0
 ]

That works to an extent (not perfect):

Selecting the 81 service in the now-and-next EPG gets the 81 service in the 7-day EPG... but so does selecting the 861 service. Setting a recording from the 81 service (N&N or 7-Day) schedules the 861 service. This is repeatable across duplicated services (eg Yesterday 26/836).

Something to note is that the URLs for the individual services in the N&N EPG (and presumably the grid EPG would be the same) remain identical. That's where I think the problem is: perhaps the URLs themselves should be composed from SvcID and LCN, eg

http://192.168.1.11/epg/service.jim?service=28224?lcn=861

I realise this will affect very few people (or maybe even only me), but it is indicative of there being a hidden problem.

I broke it at one point: I tried commenting out the original line and adding the new one, only to discover nothing worked at all. I now realise the "\" is a continuation and that's all one long line. If I did comment it out, would I have to prefix the whole block with a "#" on all the lines from set to -debug 0 inclusive?

 

[/df]

That works to an extent (not perfect):
...

That's about the extent to which I expected it to work (we're just forcing the lowest LCN since the 7-day page hasn't been told which).

Something to note is that the URLs for the individual services in the N&N EPG (and presumably the grid EPG would be the same) remain identical. That's where I think the problem is: perhaps the URLs themselves should be composed from SvcID and LCN, eg

That's what I was suggesting when I wrote

So the service_id is an inadequate key. The interface to the 7-day EPG needs to pass the LCN and the search query needs to use the LCN. That means modifying the EPG class to implement searching by LCN, or filtering out records with non-matching LCNs from the returned list of events in webif/html/epg/service.jim.

Except URL parameters are introduced by ? and separated by &:

http://192.168.1.11/epg/service.jim?service=28224&lcn=861

I realise this will affect very few people (or maybe even only me), but it is indicative of there being a hidden problem.

Well, yes. Why do you want these duplicate channels (that tunefix will help you to eliminate)? I can see that you might want regional variations but I don't think there's a version of TP packed with "How Green Was My Valley" etc.

I broke it at one point: I tried commenting out the original line and adding the new one, only to discover nothing worked at all. I now realise the "\" is a continuation and that's all one long line. If I did comment it out, would I have to prefix the whole block with a "#" on all the lines from set to -debug 0 inclusive?

And also the final line with the ] that matches the opening [ of the expression being assigned to records.

Comments in TCL and especially in Jim TCL are a bit weird. Basically, # is a no-op command, so the comment string still has to be a valid command (including matching {}). Inside a command evaluation, like the lines that were modified [epg dbfetch dump ... ], a comment isn't syntactically valid, at least not until Jim v0.81 which implements the TIP 582 proposal for comments in expressions, to match TCL 8.7; it's only taken 30 years to get this.

 

[Black Hole]

Why do you want these duplicate channels (that tunefix will help you to eliminate)?

• The more recent firmwares are reported to eliminate the early problems we had with multiple tuned transmitters, which I am trying to build up a body of evidence for;
  
  
• They have provided a stop-gap when reception goes pear-shaped;
  
  
• They help show up deep bugs in the CF;
  
  
• And probably the most relevant reason: I'm lazy.

 

[/df]

In fact the interface to the 7-day should pass just the LCN (as in http://192.168.1.11/epg/service.jim?lcn=861: perhaps that would make service.jim poorly named), since the service_id can always be found as usSvcId in TBL_SVC. EPG records (as with the on-air format) only mention the service_id. The 7-day EPG should be populated with records whose service_id matches the usSvcId corresponding to the LCN of the page URL. I'd be more confident about this if there had been any EPG data newer than 5 months old on the machine that I hoped to use for tests.

 

[prpr]

This is a bit naff. Why are these boxes different widths?

 

[/df]

In a cod-Russian-meerkat voice:

# find webif -name '*.j*' -exec grep -Hn -B 2 'WARNING !!' '{}' \;
webif/include/diskcheck.jim-48- puts "
webif/include/diskcheck.jim-49-<div id=smartwarning class=warningbox><center>
webif/include/diskcheck.jim:50:!! WARNING !!
webif/include/notify.jim-7-puts {
webif/include/notify.jim-8-<div id=sysnotify class=warningbox style="width: 90%"><center>
webif/include/notify.jim:9:!! WARNING !!
#

 

[/df]

One might think having one or more read-only disk partitions (filesystems) might be something the WebIf ought to display to the user as an alert, in a similar manner to the SMART generated ones.
...

and

This is a bit naff. Why are these boxes different widths?
...

Try this patch, detecting RO filesystems on the system HDD partitions and tidying the layout (for me the warning box aligns with the top bar and doesn't crash the disk space pie). Obviously I tweaked it to confirm RO detection but I hope not to experience the problem condition(s), so extra testing would be welcome.

 

[prpr]

This is a bit naff...

This is even more naff:

Having fixed the aforementioned pending sectors, it now tells me that they've been reallocated, which is exactly as expected. So how do I get rid of this damned useless warning box (which seems visually more like a catastrophic error box), and why does it overlay the Status box in an ever-so-irritating way?
I've already been to Disk diagnostics to look at things and done a fixdisk run. There is no problem any more. So what am I supposed to do?

As you can probably tell, I've never seen this before as I've never had duff sectors before, but it really is crap design. Surely others must have had this?

 

[prpr]

Try this patch, detecting RO filesystems on the system HDD partitions and tidying the layout

Thanks. I'll try and get round to looking at it when I can stand the heat, but for the moment I'm outta the kitchen...

 

[xyz321]

In 'Scheduled Events' it also overlays the tabs at the top, preventing access to the visual schedule or schedule backup and restore.

To remove it you have to go to the disk diagnostic page and click the Acknowledge any current disk faults button at the bottom of the page.

 

[/df]

This is even more naff:
View attachment 5618
Having fixed the aforementioned pending sectors, it now tells me that they've been reallocated, which is exactly as expected. So how do I get rid of this damned useless warning box (which seems visually more like a catastrophic error box), and why does it overlay the Status box in an ever-so-irritating way?
I've already been to Disk diagnostics to look at things and done a fixdisk run. There is no problem any more. So what am I supposed to do?

As you can probably tell, I've never seen this before as I've never had duff sectors before, but it really is crap design. Surely others must have had this?

Isn't this a result of the algorithm employed to detect errors, which is to compare the current values of selected SMART parameters against the previously saved values?
webif/include/diskcheck.jim ll.35ff.:

foreach sa $smartattrs {
        if {$smartattribs(SMART_$sa) != $smartattribs(SMART_ack_$sa)} {
                append smartmsg \
                    "Disk $sa sector count is: $smartattribs(SMART_$sa)"
                if {$smartattribs(SMART_ack_$sa) > 0} {
                        append smartmsg " (was $smartattribs(SMART_ack_$sa))"
                }
                append smartmsg "\n"
        }
}

Should probably have {$smartattribs(SMART_$sa) > $smartattribs(SMART_ack_$sa)} since all the selected parameters ({realloc pending offline spinretry}) increase with badness. Also there is a SMART_ack_status that is mentioned in a comment but is not actually populated.
And

In 'Scheduled Events' it also overlays the tabs at the top, preventing access to the visual schedule or schedule backup and restore.

To remove it you have to go to the disk diagnostic page and click the Acknowledge any current disk faults button at the bottom of the page.

This could be by design. If the box has a bad disk it's probably a Good Idea to deal with that before worrying about scheduled recordings that might well be corrupted.

 

[xyz321]

If it were to use > instead of != then it should also handle the < case to reset the values since someone may swap out the disk. This assumes it is not done elsewhere.

 

[MymsMan]

I think it went with != because a single run of fixdisk doesn't always fix all problems and their may still be some unresolved issues that you should be aware of and acknowledge.
So a better fix would be to skip the Alert box if the values have been reset to zero but retain it for non zero values (even if lower than before)

 

[prpr]

Try this patch, detecting RO filesystems on the system HDD partitions and tidying the layout (for me the warning box aligns with the top bar and doesn't crash the disk space pie). Obviously I tweaked it to confirm RO detection but I hope not to experience the problem condition(s), so extra testing would be welcome.

It looks good, although I've tweaked it to improve the spacing in the message components, which now works properly for all three error conditions (I inverted the tests in the script for this purpose), and got rid of the pointless if/else:

--- diskcheck.jim~
+++ diskcheck.jim
@@ -64,13 +64,7 @@
                {format "Filesystem %s on %s is read-only" [lindex $line 1] [lindex $line 0]}] "\n"]
 }
 
-# why not HD too?
-if {[system model] eq "HDR"} {
-       set smartmsg [system disksmart]
-} else {
-       set smartmsg [system disksmart]
-}
-
+set smartmsg [system disksmart]
 set romsg [system diskro]
 
 if {$smartmsg ne "" || $romsg ne ""} {
@@ -99,18 +93,18 @@
        if {$smartmsg ne ""} {
                puts "
 [string map {"\n" "<br>"} $smartmsg]
+<br>
 "
        }
        if {$romsg ne ""} {
                puts "
-<br><br>
 [string map {"\n" "<br>"} $romsg]
+<br><br>
 "
        }
        if {$env(SCRIPT_NAME) ne "/diag/disk.jim"} {
                puts "
-<br>
-<a href=/diag/disk.jim>Go to disk diagnostics</a>
+Go to <a href=/diag/disk.jim>Disk Diagnostics</a>
 "
        } else {
                puts "

 

[prpr]

To remove it you have to go to the disk diagnostic page and click the Acknowledge any current disk faults button at the bottom of the page.

Thanks, I obviously missed that with the heat induced inability to do anything much.

 

[prpr]

Try this patch

This is a bit unnecessary too:

diff --git a/webif/include/diskcheck.jim b/webif/include/diskcheck.jim
old mode 100755
new mode 100644

 

[/df]

... the pointless if/else:
...

Only completely pointless if HDs turn out always to be able to do system disksmart properly. This might depend on the USB-SATA bridge or equivalent in use. It works for at least one of mine (olde-worlde Sky box 500GB disk in a powered caddy) but other configurations might not do so well: if so there would have to be some sort of filter for the HD case.

And

This is a bit unnecessary too:
...

That was an accident that I let through thinking that the include fragment wasn't meant to be executed on its own. But actually it could be useful for testing.

 

[prpr]

Only completely pointless if HDs turn out always to be able to do system disksmart properly.

Shirley the place to handle that is in system disksmart itself?

 

[Black Hole]

Don't call me...