WebIF Crop and Bookmarks Not Working

Black Hole

May contain traces of nut
I don't know where to assign blame, so I'm keeping this out of the public forum for the moment.

I have a recording (from FOUR HD as it happens), and I want to keep the first 3 minutes (ish) out of 17. I set a bookmark at the end of the "keep" section on the SUI, then went into WebIF to perform the crop.

Crop doesn't work, it just send the original to the _original folder and leaves no cropped file, in very little time. I tried it with keeping the second part, same result.

Then I went into the Bookmarks editor to try adding more bookmarks, and that doesn't work either.

Initial presumption is this has something to do with 3.14.
 
OK, well I've got crop to work on another recording, but not Bookmarks. The recording I was working on has become corrupted somehow and now won't play at all (annoying).
 
The corruption was an empty .nts, having recreated it the crop works. The bookmark editor still doesn't work though.
 
I dont know if this is new, but I cant see any reason why the beta would have any effect on the webif,

When I tried the bookmark tool it didn't show the slider bar where you can move bookmark locations when there are no pre-existing bookmarks but you can type bookmark positions in the text entry box and save them.
When you reenter the tool the bookmarks are then displayed OK
 
Yes, I see it does. The Update button isn't working for me though, tested on two machines (iOS/Safari might be a complicating factor, I'll run some tests later on Win7/Chrome).
 
It's worse in Safari than Chrome, but still not working. The Update button doesn't work, the pips on the timeline only work if you don't create any more. Both machines on WebIF 1.4.9-6. Tried it on a third machine with 1.4.9-2 - same.
 
The HTML is invalid - not properly terminated, at least, as it abruptly ends with <div id=results class="hidden blood"></div>.
It's difficult to know what the intent is/was - it's been broken like this for 7 years.

The Javascript is also giving errors - $slider is null at line 99 of /mod/webif/html/browse/bookmarks/script.js in update_slider()
So it's hardly surprising it doesn't work properly/at all.
@/df was the last person to touch all this in Pull Request #39.
 
It's not entirely clear (to me anyway, and at this point where it's apparently broken) what the Update button is actually supposed to do.
The rest of it seems to work reasonably adequately (on FF), although you might have to refresh the page between operations using the Save button.

FWIW, the HTML can be fairly easily fixed by adding the equivalent of this to the bottom of the index.jim file in the aforementioned directory:
Code:
puts "</fieldset>"
footer

I had a grep through the Webif and found a whole load more in /mod/webif/html/browse/ which are in error. These are all missing "footer":
audio/audio.jim
chunk/chunk.jim
crop/crop.jim
decrypt/decrypt.jim
mpg/mpg.jim
strip/strip.jim
tvdb/episode.jim

and this one is missing both, the same as in bookmarks:
thumbnail/index.jim

No idea about fixing the Javascript. Will leave that to /df.
 
Last edited:
The update button is supposed to reflect edits in the text bookmark list into the graphical timeline.
 
Something else not working: My multimode is clearly doing what it is supposed to (specifically converting Horror to padding), but when I go into settings for multimode it shows nothing configured.
 
Mine works OK. Not that I ever use it. I found something set I'd forgotten about, so cleared it and set something else, and cleared it, all without any problems.
 
...
The Javascript is also giving errors - $slider is null at line 99 of /mod/webif/html/browse/bookmarks/script.js in update_slider()
So it's hardly surprising it doesn't work properly/at all.
@/df was the last person to touch all this in Pull Request #39.
Apparently it was only tested on files that already had bookmarks: having said that, this stanza at l. 49 ff.,
Code:
        if (!values.length || values[0] == '')
        {                                     
                $slider = null;               
                return;                       
        }
which, when removed, restores the slider, allowing you to add bookmarks by pressing + and moving the slider button, as far as I recall reproduced what happened in the previous version, but perhaps not.
 
Yes, I'd worked that bit out, but what's all this about:
Code:
function
draw_slider()
{
        if ($slider)
                $slider.slider('destroy');
        else
                $slider = $('#slider');
As far as I can see, this only gets called once, when $slider is null, so it initialises it, but what's that 'destroy' thing for, and what does it do, and when?
It seems as though this preceded all your mods. though.
There's also a weird time string that pops up when the bookmark list is empty saying 00:00:00, which disappears when it isn't empty. Anyone know what's that supposed to do?
It's all a bit weird. The stuff on Gitea is also slightly different to what's on the Humax for this file too, just to irk a bit more (it messes up the line numbers).
 
Although I may have treated this as jQuery UI cargo-cult code, I believe that what's happening is: if we already have a slider ($slider), get rid of any pre-existing jQ UI slider widget; otherwise set the slider from the element with ID 'slider'. Then a new jQ UI slider widget is set on the slider. This seems logical as we don't fully control the value of $slider. Perhaps I put that suspect check in after [mis-?]reading the spec for a JQ UI slider.

The rationale is that jQ UI doesn't have a way of changing the number of drag handles in a slider other than destroying it and re-creating it. You can assign differently sized value arrays to a slider, but the number of handles is limited by the size of the array with which the array was initialised (or 1, whichever is larger).

And
...
There's also a weird time string that pops up when the bookmark list is empty saying 00:00:00, which disappears when it isn't empty. Anyone know what's that supposed to do?
...
I suspect a missing not. There could be a line of bookmark times in [h:]m:s format, matching the line in seconds above, and that would be the first item.
 
Last edited:
The HTML is invalid - not properly terminated, at least, as it abruptly ends with <div id=results class="hidden blood"></div>.
It's difficult to know what the intent is/was - it's been broken like this for 7 years.
...
Plainly, as you suggest, the page should have a closing </fieldset> and the tags added by footer to match header, in particular the closing body and HTML tags. The missing tags are unobvious in the Mozilla developer tools which supply the missing tags without comment.

Is it time for the Webif pages to acknowledge HTML5 and say goodbye to "HTML4.01 Transitional"? The W3C validator has only a few quibbles if so:
  • <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> duplicates <meta charset="utf-8">;
  • <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> should be dropped: let anyone who doesn't like the way the page appears in IE8 adjust the local compatibility settings in Windows;
  • images must have alt text (especially necessary for blind users of TV settop applications!);
  • ad-hoc attributes (in this case pos, init should have names beginning data-;
  • table presentation attributes should be CSS, eg instead of </head>...<table class="keyval" cellpadding=5>:
    Code:
    <style>.keyval th, .keyval td { padding: 5px; }</style>
    </head>...
    <table class="keyval">
 
Is it time for the Webif pages to acknowledge HTML5
Probably, but I think it's loads'a'work isn't it? Lots of things didn't validate the last time I looked, and the solution is probably similarly costly.
 
So, thing 1: this thread belongs in Beta Packages.

And thing 2: I have a much improved version of the bookmark display (but the margin of this forum is too small ...*).

There is a problem with the ffmpeg code that generates the bitmaps, because timecodes close to the end of the recording can get wrapped around to the beginning.

Maybe this is a side-effect of the test file having been cropped with nicesplice? Another file is seen by ffmpeg with the right (or at least plausibly correct, in that the end+1 thumbnail is missing) length.

For the problem recording:
  • hmt says duration 1273s, "Stored duration" 1799s, "Scheduled duration" 1800s;
  • ffprobe says "Duration: 00:25:17.56" (1518s);
  • MediaInfo 0.7.8.2 says "Duration: 25mn 16s" (1516s), or 1515s for the video stream.
The recording was cropped at start, end, and in the one ad break.

* "504 Gateway Time-out"
 
Last edited:
Probably, but I think it's loads'a'work isn't it? Lots of things didn't validate the last time I looked, and the solution is probably similarly costly.
Mostly deleting old backward compatibility (IE <= 11) stuff. Also, the page header and footer are both common (when we remembered to include them).
 
Maybe this is a side-effect of the test file having been cropped with nicesplice?
I expect so, seeing as it is mostly a tool for f***ing up your recordings such that other tools don't work properly.
There certainly isn't anything nice about it.
 
Back
Top