[webif] Web Interface 1.4.x

prpr

Well-Known Member
Adding a Manual Event on the Scheduled Events page and the time entry/dropdown lists seem to use the 12 hour clock. Everything else on that page uses the 24 hour clock. Ugh. Weird and very off-putting.
 

/df

Well-Known Member
According to https://www.jonthornton.com/jquery-timepicker/, change l.365 of webif/html/sched/list/script.js:

Code:
-        timeFormat: 'g:ia',
+        timeFormat: 'H:i',
Seems to work even if the accompanying documentation is obscure or incomplete. Possibly it would be nice if the top item in the pull-down was the next step in the the list after now (and wrap around after 24:00) but I can't get excited.
 

Black Hole

May contain traces of nut
I was just trying to copy a naked .ts from a UPD into My Video using the WebIF media browser copy&paste, and the paste operation just emptied the paste buffer without actually copying anything. Tried it twice, then resorted to the on-screen menus to do it :speechless:
 

MymsMan

Ad detector
I was just trying to copy a naked .ts from a UPD into My Video using the WebIF media browser copy&paste, and the paste operation just emptied the paste buffer without actually copying anything. Tried it twice, then resorted to the on-screen menus to do it :speechless:
By naked I presume you mean without .hmt or other sidecar files.
I think it is the absence of the .hmt is the problem - the webif .ts class methods assume the existence of an hmt to provide the recording details (even though not needed to do a move/copy)
 

Black Hole

May contain traces of nut
A: It would be nice if it didn't require stuff it doesn't need;
B: If it does require stuff that isn't there, it ought to throw up an error message rather than just pretend to do it.
 

everthewatcher

Forum Supporter
I was just trying to copy a naked .ts from a UPD into My Video using the WebIF media browser copy&paste, and the paste operation just emptied the paste buffer without actually copying anything. Tried it twice, then resorted to the on-screen menus to do it :speechless:
You're using Win7 IIRC? It can do that from time to time.

I've only had a month or so's experience using Win10 in anger on my main PC but I've not had this happen yet.
 

/df

Well-Known Member
By naked I presume you mean without .hmt or other sidecar files.
I think it is the absence of the .hmt is the problem - the webif .ts class methods assume the existence of an hmt to provide the recording details (even though not needed to do a move/copy)
ISTR that the code expects .ts always to have been generated from recordings, even though you can eg youtube-dl a live stream to a .ts and watch it as it grows.

So it looks like a sweep of the code is needed. sidecar -h could be used to create a missing .hmt for a .ts if needed (.nts could also be created for an imported unencrypted file).
 

prpr

Well-Known Member
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)
There are four relevant fields - realloc, pending, offline, spinretry. What I propose is:
Code:
for each field
{
  if value > ack_value
    error
  else
    if value < ack_value
      if (field == pending or field == offline)
      {
        if value > 0
          error
        else
          auto ack
      }
      else
        auto ack
 }
Can anyone see any flaws with this?
 
Last edited:

prpr

Well-Known Member
I was just trying to copy a naked .ts from a UPD into My Video using the WebIF media browser copy&paste, and the paste operation just emptied the paste buffer without actually copying anything. Tried it twice, then resorted to the on-screen menus to do it
Have fixed this too.
 

Black Hole

May contain traces of nut
From the maintenance mode web page, why doesn't the "exit maintenance mode and reboot" button reload the WebIF?

The extant URL has "/exit" appended, which does not exist and (when manually refreshed) a redirection page gets served up and then diverts to the WebIF home page in 5 seconds, but when rebooting from Diagnostics there is "/restart" appended without the same problem – the page reloads the WebIF home page without intervention.
 
Last edited:

prpr

Well-Known Member
From the maintenance mode web page, why doesn't the "exit maintenance mode and reboot" button reload the WebIF?
It does for me.
The extant URL has "/exit" appended, which does not exist and (when manually refreshed) a redirection page gets served up and then diverts to the WebIF home page in 5 seconds, but when rebooting from Diagnostics there is "/restart" appended without the same problem – the page reloads the WebIF home page without intervention.
Not sure I understand exactly what you mean. Perhaps you could document the exact reproduction scenario?
 

Black Hole

May contain traces of nut
Perhaps you could document the exact reproduction scenario?
I've worked out the sequence of events:

Clicking the web page button to reboot from MM goes to URL <IP Address>/exit to trigger the reset. The web server isn't running because it's being reset, but if the browser keeps retrying eventually the web server is up and it responds with the 404 page, and then auto-diverts (after 5 seconds) to the home page.

The iPad doesn't do this. It gives up retrying, and then a manual retry triggers the 404 action. But it works perfectly fine for the process used by WebIF >> Diagnostics >> Reboot, where there is some JS (or something) running locally in the browser to enforce a delay before reloading.

It seems clunky to use a non-existent URL to trigger the reboot. Is that a necessary consequence of Maintenance Mode? How about including the /exit page as a real page (in normal mode), which immediately diverts to home, rather than rely on the 404 mechanism?
 

/df

Well-Known Member
As I understand it ...

In MM the bootstrap web server is meant to be running (/etc/init.d/S37bootstrap). The files for this are in /var/bootstrap. Although I don't have the source code for this server, strings indicates that it knows about /exit and /reboot.

If the standard web server (lighttpd) is started in place of bootstrapd and somehow uses /var/bootstrap, so finding maint.html, it would fail to link to the /exit link, there being no exit.html or exit/index.jim, etc, in that directory. This doesn't seem to be what's happening.

But if what happens on /exit is that the system reboots, the client may try to re-fetch the same page; when the new (standard) web-server comes up it also has no exit.html or exit/index.jim (in /mod/webif/html) and so the 404 page is served. Probably there should be a redirect page or an alias in /mod/etc/lighttpd/extra.d/ to avoid this.

The Diagnostics page is entirely handled by the standard web server.
 
Last edited:

/df

Well-Known Member
Based on the above, try this as new file /mod/etc/lighttpd/extra.d/exitalias.conf:
Code:
alias.url += (
      "/exit" => "/mod/webif/html/index.html"
)
This will now redirect (which I think is better than directly going to the home page) in 0 seconds flat.
 
Last edited:

Black Hole

May contain traces of nut
Based on the above, try this as new file /mod/etc/lighttpd/extra.d/exitalias.conf:
Code:
alias.url += (
      "/exit" => "/index.html",
)
This will redirect (which I think is better than directly going to the home page) in 0 seconds flat.
No change (in iOS).

The iPad doesn't do this. It gives up retrying, and then a manual retry triggers the 404 action.
What's happening is the page load progress bar stalls and does nothing further, well after the time the reboot should have completed and the web server be up. When I cancelled the load and then hit refresh (URL = /exit), it still went via the "Sorry this page is not available".

Is there no way we can have the "Restarting..." timer in MM?
 
Last edited:

/df

Well-Known Member
The MM restart function is built into /sbin/bootstrapd, so probably not easily.

What happens if you navigate to http://<box>/exit from the normal Webif? Maybe my conf-file is sick or
otherwise being ignored. /tmp/webif.log, /tmp/webif-error.log may have clues.

OK, try the updated version with the full pathname.
 
Last edited:

prpr

Well-Known Member
OK, try the updated version with the full pathname.
It makes no difference to the behaviour. /exit does a redirect to / before it ever gets to anything else. There is a 30s delay on that, which clearly is not enough. It fails to load the index page on both my PC and my (iOS) phone, just the standard "server not responding" type of error. Refreshing shortly after that, having allowed extra time for the restart, brings up the normal index page, as expected.
So it would seem sensible to increase the timeout to say 45s instead, which is within our capability. Will build/test in a bit.
 
Top