• 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.

[webif] Web Interface 1.4.x

Status
Not open for further replies.
/df said:
This happens because the <a> is inside the <span> that makes the box. The reverse nesting is allowed and makes the entire box active.
Click to expand...
Good stuff. Are you going to do a diff?
MymsMan said:
Since we have lived it for all these years with apparently no one else noticing/reporting it there is no great need to fix the webif.
Click to expand...
Just because it's always been like that doesn't mean it shouldn't be fixed.
 
prpr said:
Good stuff. Are you going to do a diff?
...
Click to expand...
TBH I had no idea where in the system this toolbar (which I don't use) was generated, but actually this appears to make the entire button active without changing the layout. Your browser may vary...
Diff: 
--- webif/include/toolbar.jim~
+++ webif/include/toolbar.jim
@@ -12,13 +12,13 @@
        } else {
                set width ""
        }
-       puts -nonewline "<span class=toolbarcell>
-           <a href=\"$link\">
+       puts -nonewline "<a href=\"$link\">
+           <span class=toolbarcell>
                <img src=\"$icon\" height=${height}${width} border=0>
                <br>
                $txt
-           </a>
-         </span>
+           </span>
+       </a>
        "
}
 
Last edited by a moderator:
Black Hole said:
When's the next update?
Click to expand...
This afternoon when I have finished fixing the heating - I'll add this along with whatever is needed to fix crop and push it as a beta. I can test for layout changes in my browser, but wider testing would be useful.
 
Next request: on the Browse Media Files pages, could we have the "Queue for" button open a sub-menu rather than instantly invoke the pre-selected action. I think this would be more intuitive and less liable to user error. The button could be changed to "Queue for...".
 
And another:

WebIF >> Browse Media Files >> (recording) >> Crop

It would be very nice to have some controls in addition to "Invert selection". What I suggest is "Add padding at start of keeps" (plus a value in seconds, default 5), and "Add padding at end of keeps" (plus a value in seconds, default 5). This would give similar possibilities to crops defined by manual bookmarking as are available for detectads bookmarks.
 
prpr said:
If you use the WebIf's Rename function to set a new Medialist Title or New Synopsis, it doesn't include the 0x15 prefix on the string.
This usually doesn't seem to matter... except when you get to something like "Les Misérables" when it does.
Without the 0x15, it displays the UTF-8 literally, which makes it show funny characters (technical term!).

The Humax software seems to put these 0x15's in the .hmt file by default.
Click to expand...
@af123
Patch for the above:
Diff: 
humax /mnt/hd2/mod/webif/html/browse # diff rename.jim~ rename.jim
--- rename.jim~
+++ rename.jim
@@ -26,6 +26,9 @@
                        set new [string map {"\n" ""} [
                            string trim [cgi_get "rename_$attr"]]]
                        set old [$ts get $attr]
+                       if {$attr eq "title" || $attr eq "synopsis"} {
+                           set new "\025$new"
+                       }
                        if {$new ne $old} {
                                if {$attr eq "guidance" ||
                                    [string length $new] > 0} {
 
Minor irritation with webif grid style EPG display
The view switch button is at the bottom of the page
1575213736849.png
instead of being at that the top as it is on the other EPG views including the RS grid view
1575213790389.png
It would be more consistent and much easier to use if it was moved to the same position as on the RS display.
To reduce possible confusion with the "Now" button the label could be "Now/Next view"
 
This post is just to note that the Webif UI for manual decryption and some long-running plugin operations will fail if the operation runs for 360s because
/df said:
...The CF lighttpd webserver is timing out the operation because no data is being sent. ...
Click to expand...

So either the lighttpd parameter server.max-write-idle should be set to some giant value, or the JS/Jim pattern used to run these operations needs to be changed.

The fundamental issue is that the JS fetches a web page that is generated by Jim executing an OS command, but, as the execution is protected by catch, no output is sent by the web server until the command completes. If the command runs for longer than server.max-write-idle seconds, the page is cancelled, without triggering any Jim cleanup -- you might expect that the server sends Jim a SIGTERM or similar which could be caught with catch -signal and passed on to the spawned command, but testing indicates that the CGI GET process is terminated in such an extremely prejudicial way that the JIm code can't tell that it's happening.

Perhaps a home-grown catch replacement could allow the standard output to be written while still protecting the script?
 
Last edited:
Recently I noticed that auto-processing was not running with no decryptions or Sweeper processing taking place
There was nothing in the auto log except 22/01/2020 19:58:31 - Scanning media for flags... with no progress/completion messages

I ran scan from the command line and the problem was revealed
Code: 
/mod/webif/lib/auto/scan:132: Error: could not read "/media/My Video/[Shares]       Do not delete!/[old-NAS]/": Not a directory
in procedure '::auto::buildflagdb' called at file "/mod/webif/lib/auto/scan", line 333
in procedure 'buildflagdb' called at file "/mod/webif/lib/auto/scan", line 190
in procedure 'buildflagdb' called at file "/mod/webif/lib/auto/scan", line 190
in procedure 'file' called at file "/mod/webif/lib/auto/scan", line 132
One of my network drives had gone offline and was causing the problem

This raises a number of questions:
  1. Should scan be looking at Network drives given that bot [Shares] and [old-Nas] given the names are square bracketed?
  2. Could the error condition be caught and the folder bypassed to prevent similar failures in future?
  3. Would it be better to direct the stderr output of scan, deq and other scheduled processes to auto.log rather than the bit bucket dev/null to make it easier to diagnose any other uncaught errors?
 
MymsMan said:
  1. Should scan be looking at Network drives given that bot [Shares] and [old-Nas] given the names are square bracketed?
  2. Could the error condition be caught and the folder bypassed to prevent similar failures in future?
  3. Would it be better to direct the stderr output of scan, deq and other scheduled processes to auto.log rather than the bit bucket dev/null to make it easier to diagnose any other uncaught errors?
Click to expand...

1. I'll have to refresh my memory.. I think it still scans into them looking for flag files that might selectively enable things.
2. definitely
3. definitely
 
I posted before checking the code and the failure is on the line before the checks for special directories
I have patched scan on my box with:
Code: 
if {[catch {file stat "$dir/" st} msg]} {
    log "[string repeat " " $indent]Cant stat $dir - $msg, skipping." 2
    incr indent -2
    return
  }
and updated crontabs with
Code: 
* * * * * /mod/webif/lib/auto/scan >/dev/null 2>> /mod/tmp/auto.log
* * * * * /mod/webif/lib/auto/deq >/dev/null 2>> /mod/tmp/auto.log
 
Last edited:
MymsMan said:
I posted before checking the code and the failure is on the line before the checks for special directories
I have patched scan on my box with:
Code: 
if {[catch {file stat "$dir/" st} msg]} {
    log "[string repeat " " $indent]Cant stat $dir - $msg, skipping." 2
    incr indent -2
    return
  }
and updated crontabs with
Code: 
* * * * * /mod/webif/lib/auto/scan >/dev/null 2>> /mod/tmp/auto.log
* * * * * /mod/webif/lib/auto/deq >/dev/null 2>> /mod/tmp/auto.log
Click to expand...
There is also a similar problem in browse calculating folder sizes
Code: 
23    at file "/mod/webif/html/browse/sizes.jim", line 15
22    du: can't open '/media/My Video/[Shares]       Do not delete!/[old-NAS]': Not a directory
Wierd that an entry can simultaneously be and not be a directory entry!
 
Black Hole said:
Next request: on the Browse Media Files pages, could we have the "Queue for" button open a sub-menu rather than instantly invoke the pre-selected action. I think this would be more intuitive and less liable to user error. The button could be changed to "Queue for...".
Click to expand...
Bump! I keep ticking a box and then hitting "Queue for..." without first choosing my action and getting the default audio extraction to MP2. I know this is user error, but it is very easily done.

Another way to skin this cat would be to make the default action do nothing (preferably without unticking the selections).
 
Status
Not open for further replies.
Back
Top