Black Hole
May contain traces of nut
I'll give it a try.
[webif] Web Interface 1.4.x
- Thread starter af123
- Start date
- Status
Black Hole
May contain traces of nut
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
Code:
http://192.168.1.11/epg/service.jim?service=28224?lcn=861I 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?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).
That's what I was suggesting when I wrote
Except URL parameters are introduced by ? and separated by &:
Code:
http://192.168.1.11/epg/service.jim?service=28224&lcn=861Well, 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.
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
May contain traces of nut
- 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.
Last edited:
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.
In a cod-Russian-meerkat voice:
Code:
# 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 !!
#and
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
Well-Known Member
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?
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
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.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.:
Code:
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"
}
}{$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
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.
MymsMan
Ad detector
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)
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
Well-Known Member
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:
Code:
--- 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
Well-Known Member
Thanks, I obviously missed that with the heat induced inability to do anything much.
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
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.
Last edited:
Black Hole
May contain traces of nut
Don't call me...
- Status