Black Hole
May contain traces of nut
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.
Ok, I have updated my previous post.Something like that : )
hmt supports the -bookmarks flag to just display bookmarks which may simplify things
and maybe remove the .bmp afterwards.
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.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.
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.
- The user-specified thumbnail is only available for decrypted recordings, and the ffmpeg package must be installed.
- 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.)
- Stop playing the recording (stop button).
- 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.)
- Click the OPT+ button for the recording in question and click "Set Thumbnail" from the drop-down list.
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.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):
I have not tested this, but observations indicate it should work. Note that is does not require the recording to have been decrypted.
- Set a bookmark at the desired thumbnail frame (it must be the first bookmark in the recording);
- Perform a WebIF crop operation (this removes everything in front of the bookmark, but saves the previous recording as backup);
- Play the cropped file (this causes the Humax to generate a thumbnail for the "new" recording);
- Use FTP or Telnet to copy the new thumbnail to the thumbnail of the backup set;
- Delete the cropped set;
- Move the backup set back to the main folder (optionally delete the "_original" folder).
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).
Webif 0.13.3-2 adds two new OPT+ menu items.
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.
{
transform: scaleY(-1);
-webkit-transform: scaleY(-1);
-o-transform: scaleY(-1);
}
Works perfectly in Firefox! Thanks, I'll roll that it in to the next update.Have you tried applying the css
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.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.
I also don't get a thumbnail in the media details.