[webif] Web Interface 1.4.x

[prpr]

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]

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

-        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]

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

 

[MymsMan]

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

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]

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]

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

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]

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]

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:

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?

 

[prpr]

Can anyone see any flaws with this?

Obviously not. Tests OK for me, so will be in the next beta.

 

[prpr]

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]

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.

 

[prpr]

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]

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]

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.

 

[/df]

Based on the above, try this as new file /mod/etc/lighttpd/extra.d/exitalias.conf:

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.

 

[Black Hole]

Does it need to be executable? I'll make it executable anyway, but...

 

[Black Hole]

Based on the above, try this as new file /mod/etc/lighttpd/extra.d/exitalias.conf:

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?

 

[/df]

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.

 

[prpr]

Does it need to be executable?

No, it's a configuration file, not executable code.

 

[prpr]

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.