• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Thumbnails - any configuration?

Thanks, I can now change the thumbnail, however I still don't get a thumbnail displayed in media details in the web-if.
I haven't re-booted since installing ffmpeg (because of a recording) so that may be why.
If not, any other suggestions?
 
aciddad said:
Thanks, I can now change the thumbnail, however I still don't get a thumbnail displayed in media details in the web-if.
I haven't re-booted since installing ffmpeg (because of a recording) so that may be why.
If not, any other suggestions?
Click to expand...
That's coming in the next version. For now, you can click OPT+->View Thumbnail if you wish to view it from the web interface.
 
raydon said:
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.
Click to expand...

Sorry Raydon, I didn't realise you were talking about the .hmt file rather than the .thm (damned anagrams!).

I don't see how that would work. Using an unused byte in the .hmt can be used to flag that a custom thumbnail has been set, sure, but the flag would not get reset if the Humax came along and wrote its own thumbnail file. This could happen if (by a slim chance) the Humax happened to be working on a thumbnail at the same time as the custom software automated process, the custom .thm gets written and then is immediately over-written by the Humax .thm.

With the custom flag as part of the .thm data, if the .thm gets over-written so does the flag.
 
Black Hole said:
Sorry Raydon, I didn't realise you were talking about the .hmt file rather than the .thm (damned anagrams!).

I don't see how that would work. Using an unused byte in the .hmt can be used to flag that a custom thumbnail has been set, sure, but the flag would not get reset if the Humax came along and wrote its own thumbnail file. This could happen if (by a slim chance) the Humax happened to be working on a thumbnail at the same time as the custom software automated process, the custom .thm gets written and then is immediately over-written by the Humax .thm.
Click to expand...
Where a thumbnail for a recording doesn't exist it will only be created by the Humax under two conditions. Immediately, at start of playback, or at the next reboot. If you delete a .thm manually it will be recreated under the same two conditions. If deemed necessary, both of these can be taken into account by an automated process. Once the Humax has created a .thm file it sets a bit flag in the .hmt file at byte offset 0x028E, bit 1 (bit 0 is the on-disk encrypted flag). If you try setting this bit manually on a recording that doesn't have a thumbnail, the .thm is still created under the same two conditions so I don't understand how or why the Humax uses this flag.
With the custom flag as part of the .thm data, if the .thm gets over-written so does the flag.
Click to expand...
You can create a custom thumbnail, even before the Humax writes one, and regardless of the hmt's flag bit condition, once a .thm exists it will not be overwritten by the Humax.
Hopefully there's now enough information in the pool, thanks to the group effort, and I'm sure that af123 will use whatever means he considers best suited for the pupose.
 
raydon said:
You can create a custom thumbnail, even before the Humax writes one, and regardless of the hmt's flag bit condition, once a .thm exists it will not be overwritten by the Humax.
Click to expand...
I disagree. This is an area I have experience with, and is a typical problem in a multi-processing environment with processes competing for resources (this is usually handled at the operating system level, so processes operating at a lower priority don't need to worry about it, but in this case there is no OS involved and the humaxtv process does not expect to have anything contending with it).

I admit that it is an unlikely case, but unlikely cases have a habit of turning up and biting you. The exact circumstances are these: the WebIF decides to create a custom .thm. At around the same time, humaxtv looks for a .thm and doesn't find one because it has not been created yet, so starts generating one. If we are lucky, the two processes clash at the file creation stage and the OS throws up an error. If we are unlucky, the WebIF completes the creation of the .thm and releases it before the humaxtv process starts writing its own version. The WebIF .thm then gets over-written by the Humax version, and unless the flag is actually contained in the .thm file there is nothing to indicate this has happened.

af123 will decide to implement it anyhow he wants, how successful it will be depends on experience in multi-processing programming. In my opinion the least troublesome will be to restrain the .thm generation until the humaxtv process has already generated and released its own .thm file, this will ensure there are no conflicts later. If he wishes to implement an "early" generation strategy, some means is required to detect that a collision has occurred, and the effect of having the .thm open for writing at the same time as humaxtv tries to write to the file needs to be tested. Without the means to control humaxtv, we have to work around it.

My engineering team used to handle this kind of thing in hardware (because it can't be completely solved in software unless the hardware support exists). There are several ways to approach it, I think these days indivisible read-test-write cycles are the defacto implementation, but the way we did it using the technology of the day was to have a special hardware register associated with each resource which would only accept a write if the ID field matched the equivalent field in the attempted write, or the "reserved" flag was clear. With the "reserved" flag clear, process A attempts to acquire the resource by writing ID=A, "reserved" to the register. Process A then reads the register, and finds ID=A, so knows it now has control of the resource. While process A has the resource, process B attempts to acquire the resource by writing ID=B, "reserved" to the register. Process B reads the register back, and finds ID=A because the write was not accepted. Process B then has to try again later. When process A has finished, it writes ID=A, "not reserved" to the register. Next time another process attempts to acquire the resource it will be successful.

I'm not saying af123, Raydon, xyz321 et al are in this category, but most people have no idea how much goes on inside their PCs etc to make things work properly!
 
Black Hole said:
The exact circumstances are these: the WebIF decides to create a custom .thm. At around the same time, humaxtv looks for a .thm and doesn't find one because it has not been created yet, so starts generating one.
Click to expand...
If you read my post properly you would see that the only two circumstances under which humaxtv will create a thumbnail are well defined. It doesn't just occur at random. I also said that both of these conditions could be taken into account by an automated process before attempting to create any custom thumbnail. I stand by what I said, any thumbnail created outwith these two conditions will not be overwritten. However, I'm sure you will have the last word as you always do, so I won't comment any further on this.
 
Raydon as you are founding member of the Humax Custom Firmware and someone without who's help it may not have taken off at all, can I just say your input is always welcome. Please don't feel you have to butt-out
 
I'm not asking anyone to butt out, this is a technical discussion. I'm sorry some people think trying to explain a technical point is "having the last word". I have much respect for Raydon, but it is af123 who puts in the programming effort.

Situation: no existing thumbnail. WebIF background process picks up the existence of a recording to process the automatic thumbnail generation at around the same time as the user decides to play the recording. As Raydon has said, this is the trigger for humaxtv to also generate a thumbnail. It could happen. If you do not agree, please explain why.

This is a race condition and the consequences are undefined. We don't know what humaxtv will do if it finds a file it was expecting to write to is locked, in the worst case it could crash. If it gets in after the WebIF process has created the file, it might over-write the auto-generated file with nothing to show this has happened (apart from it being the wrong thumbnail). Various tricks can minimise the time window during which a conflict can exist, but never entirely eliminate it. The race condition can be avoided completely by the WebIF background process refusing to run until the humaxtv thumbnail has been generated.

This is a typical problem with conflicting asynchronous processes, something I have had to consider almost all my career, and I am trying to offer my engineering experience to complement the software skills exhibited by others.

OK, carry on. Generate the auto-thumbnail asynchronously. The things I mention may never happen.
 
@BH Raydon has been working on the foxsat mods for longer than us.

Your arrogance is rubbing people up the wrong way. How many mods have you written for the T2 again?
If you are determined to prove yourself right, then put your money where your mouth is and write a program to prove it rather than drowning out everyone else with huge responses.

You remind me of Mr You-Don't-Wanna-Do-It-Like-That.
 
Just going back to topic if I may

I don't suppose in theory this could be made to work on none .TS files ? I have some mp4 videos on a NAS which I would love to have a thumbnail for. I know the humax creates a .hmi file when the file is played but no other files. Is this possible or will this only be for files created by the humax (.TS)
 
The decision to place a thumbnail next to it's title is still made by the Humaxtv process so I would say that unless the file is a *.TS, the answer is no
 
You must log in or register to reply here.
Back
Top