Thumbnails - any configuration?

What would happen if the generated .thm was actually a byte longer than required? If the Humax doesn't reject it, you have a marker that can be read from the file size.
 
Good point, worth experimenting with.

I'll add the OPT+ method to the next version of webif....
 
Webif 0.13.3-2 adds two new OPT+ menu items.

thm.png


View Thumbnail will show the current thumbnail for the recording in a pop-up window (albeit upside down at present), if your browser/OS combination can render BMP files.

Set Thumbnail will be greyed out unless the recording is decrypted and has at least one bookmark. If active, then it will extract the frame at the bookmark location (based on "seconds into recording") and replace the existing thumbnail with that.

Query to concept to beta solution in a day! Thanks to all who contributed.
 
WebIF auto-updated, tested. Brilliant!

As a quick user guide to the new facility above:
The Humax-generated thumbnail image shown against each recording in the Media listing only takes a frame from very near the start of the recording, which rarely is much good for identifying the programme. The latest WebIF includes a facility for the user to select the image from any point in the recording.
  1. The user-specified thumbnail is only available for decrypted recordings, and the ffmpeg package must be installed.
  2. Play the recording, and set a bookmark (remote control button above "SLEEP") at a suitable image in the recording. This must be the first bookmark in the whole recording. (Bookmarks are shown as dots on the playback timeline, and can be deleted by pressing the bookmark button again when playback is at that point. Then next button to the right skips playback to the next bookmark.)
  3. Stop playing the recording (stop button).
  4. Find the recording in the WebIF media browser. The recording must have the "Dec" icon against it, denoting the recording has been decrypted. (There are several pre-conditions to decrypting a recording, for information see HERE - click.)
  5. Click the OPT+ button for the recording in question and click "Set Thumbnail" from the drop-down list.
Once done, exit and re-enter the media browser on the TV screen (to refresh the thumbnail display) and the new thumbnail image should be shown.
Click to expand...
Weird that the Humax stores the thumbnail images upside down to normal, there must be a reason but I can't think what it might be.

Perhaps the auto-thumbnail process can have a "blank" option for people who prefer not to have a thumbnail at all (perhaps if the blank image is set to transparent it won't even leave a black box overlaying the live video in the Media menu). The auto-thumbnail should be over-writable by the manual thumbnail, then we can have the best of both - this will rely on a flag. I like the idea of invisible thumbnails until I set my own!

I strongly suspect the Humax thumbnail generation process is triggered simply by the non-existence of a .thm. When it decides to do it (if not rebooted) is another matter, although playing the recording definitely prompts the generation.

I have thought of a way we could have set a thumbnail frame using facilities pre-0.13.3-2, with encrypted recordings. See the update to my post here:

http://hummy.tv/forum/threads/thumbnails-any-configuration.3241/#post-38027
 
Black Hole said:
Update: a self-contained process has been developed for decrypted recordings (see the rest of this topic), but actually there is a process which would achieve the desired effect (albeit long-winded):
  1. Set a bookmark at the desired thumbnail frame (it must be the first bookmark in the recording);
  2. Perform a WebIF crop operation (this removes everything in front of the bookmark, but saves the previous recording as backup);
  3. Play the cropped file (this causes the Humax to generate a thumbnail for the "new" recording);
  4. Use FTP or Telnet to copy the new thumbnail to the thumbnail of the backup set;
  5. Delete the cropped set;
  6. Move the backup set back to the main folder (optionally delete the "_original" folder).
I have not tested this, but observations indicate it should work. Note that is does not require the recording to have been decrypted.
Click to expand...
This could be speeded up by setting two bookmarks very close to each other. The first bookmark will set the thumbnail location and the second will indicate the end of the temporary file. That way the crop process will quickly produce a very short file.

If a background process was created to perform these tasks, it could create the second bookmark automatically.
 
Umm...

Very annoying that bookmarks can't be set while playback is in pause or slow motion. It makes selecting the thumbnail frame rather like hitting the moving targets at a fairground shooting gallery.

Possible alternative: instead of using the time index of the first bookmark, use the playback resume point. Find the frame you want using any combination of forward / reverse / slo-mo / pause, then stop the playback at the point to use for the thumbnail. I realise there is a problem with the 1 second quantisation of the time index for frame extraction.
 
Black Hole said:
Perhaps the auto-thumbnail process can have a "blank" option for people who prefer not to have a thumbnail at all (perhaps if the blank image is set to transparent it won't even leave a black box overlaying the live video in the Media menu).
Click to expand...

Yes - I was thinking of a new package (name to be decided) with options to:

Replace all system generated thumbnails with:
  • blank;
  • custom image;
  • new thumbnail from X seconds into recording (if recording long enough) - particularly useful for those who use padding.
I still need to decide on a way to detect manual thumbnails - I like the extra byte idea but didn't get round to testing that last night. For now, be aware that any thumbnails you create manually using the OPT+ method will still be considered automatic so don't delete the bookmarks just yet.

NB: Bitmaps don't support transparency. There are some workarounds but none that I can see helping here.
 
af123 said:
Webif 0.13.3-2 adds two new OPT+ menu items.

thm.png


View Thumbnail will show the current thumbnail for the recording in a pop-up window (albeit upside down at present), if your browser/OS combination can render BMP files.
Click to expand...

Have you tried applying the css
Code: 
{
  transform: scaleY(-1);
  -webkit-transform: scaleY(-1);
  -o-transform: scaleY(-1);
}
to the image. That should flip the image vertically.
 
Next version will show the thumbnail in a dialogue box at double size (rather than a popup window) and also include the image as part of the media details:

hc.png
 
As my small practical contribution, I confirm the extra byte flag works.

Not being a UNIX guru, I used FTP to transfer various files to my PC for manipulation, where I appended a random byte (actually a space character) to the end of a 43,680 byte .thm and used it to replace the .thm for a different recording on the HDR. The new .thm was displayed without objection, and has survived a string of plays and reboots. I sucked it back to the PC for examination, and it remains intact at 43,681 bytes long.

I suspect the additional byte can be built into the dd command, but in any case needs to be added before the write to .thm to avoid contention. There may be a small chance of a problem, if the Humax happens to decide to generate a .thm at the same time. This is avoidable if the process is only run on recordings with existing .thms, although running it again if the .thm is found to be missing the flag byte afterwards is no great shakes.
 
How about this for an idea: generate five different thumbnails at half-second intervals centred on the bookmark, present them in the WebIF and choose the one to use. There could even be a button to generate another five (earlier or later in the recording) if the user doesn't like any of the above. If there is no bookmark in the recording selected, start at time index zero.
 
If you don't want to use the extra byte you could always create the flag in an unused byte of the hmt file. Byte offset 0x4C8 doesn't seem to be doing anything.
 
Update: I mis-read Raydon's post above and didn't realise he is talking about the .hmt file.

Every fourth byte doesn't do anything either, as its use as an alpha (transparency) channel seems to have been ruled out. What made you single out 0x4C8 in particular?

The reason I suggested an extra byte is so the status can be read from the file properties without having to read the file itself.
 
Black Hole said:
Every fourth byte doesn't do anything either, as its use as an alpha (transparency) channel seems to have been ruled out. What made you single out 0x4C8 in particular?

The reason I suggested an extra byte is so the status can be read from the file properties without having to read the file itself.
Click to expand...
I have a full breakdown of the known hmt format. I chose 0x4C8 simply because it is unused, and on the start of a 4 byte boundary. I suggested writing to the hmt file because that's where Humax stores its flags and because it cannot conflict with any Humax writes to a thm file. I'm not saying it's a better way, only offering an alternative. How the information is read back is irrelevant, whether it be hmt file read or thm properties read.
 
I read this thread with interest and decided to try it out.
I decrypted a SD and a HD recording and set a bookmark in each but I am not getting the option to Set Thumbnail.
I also don't get a thumbnail in the media details.
Either I am doing something wrong (very likely!), or is it because I'm on 1.02.29 and CF 2.12?
Thanks for any advice.
 
My Humax shows about 40% of recordings with the default blank icon anyway, even after a reboot.

What about using the channel icon as a default thumbnail?
 
aciddad said:
I also don't get a thumbnail in the media details.
Click to expand...

Do you see the option but greyed out? If not then you are probably not running the latest version of the webif package. Go to package management and check for updates.
 
You must log in or register to reply here.
Back
Top