Auto-unlock?

MymsMan said:
My experience is that if the machine crashes while playing is the humax doesn't offer to resume at (or close to) the resume point but only offers the play from start option which is a PITA since you then have to fast forward to try to find the spot you were at. Resume only seems to work if you cleanly stop the recording.
Click to expand...
Because it only writes the restart point when you stop cleanly. It's not constantly updating it.
Pressing Media without stopping the currently playing recording allows the recording to play in the background, selecting another recording stops the current playing file and I am able to confirm it can't then be deleted .
Using lsof I can't find any sign of the programme being in use.
Click to expand...
I think it's just in memory of the humaxtv process.
 
prpr said:
Because it only writes the restart point when you stop cleanly. It's not constantly updating it.
Click to expand...
That would be too helpful, it frequently updates hmt during recording so it really should update hmt resume point every few seconds during play back as well.
 
Black Hole said:
...
I don't see the relevance [of the resume point being set]. Resume works regardless of a reboot, so it can't rely on a mechanism which doesn't persist.
Click to expand...
Your test procedure referred to powering off the box, which wouldn't allow the settop binary to write the resume point (without much bigger caps than are seen in the PSU, I suggest). So if the resume point was set in the after hmt and 0 in the before hmt it must have been updated as the file was playing. But as that is disputed in other recent posts, perhaps the posted hmt files came from a test where the box wasn't power-cycled?
 
prpr said:
...
I think [the supposed media in use flag]'s just in memory of the humaxtv process.
Click to expand...
According to the original test report, the in-use flag survived a warm restart (ie where the settop binary is restarted without rebooting the OS).
 
/df said:
warm restart (ie where the settop binary is restarted without rebooting the OS).
Click to expand...
To be precise, I stopped playback by pressing the power button, but immediately powered on again. It didn't have chance to finish housekeeping so there is no certainty settop restarted.

Black Hole said:
Incidentally, that file is due to auto-expire...
Click to expand...
...and it has. WebIF clearly was not inhibited from deletion.
 
MymsMan said:
That would be too helpful, it frequently updates hmt during recording so it really should update hmt resume point every few seconds during play back as well.
Click to expand...
So very Humax. Consistently inconsistent.
Black Hole said:
WebIF clearly was not inhibited from deletion.
Click to expand...
Indeed. I don't believe anything can (hooks like Undelete aside, which actually change the behaviour). Like I said, I think it's just internal to the humaxtv process.
 
Okay, so to confirm the hypothesis (and save me having to research how to do it), how do I restart settop without killing anything else?
 
Yep. Just done that (on a HD-FOX, hoping that wouldn't make any difference), and confirm it releases the "lock".
 
Black Hole said:
I have put this thread to bed by writing a summary in post 1.
Click to expand...
An additional cause of the problem:
Whilst playing press Guide and choose a programme to watch live, Humax displays a popup to ask if you want to stop playing but it causes the locked condition,


I also noticed if you delete a locked recording via webif, command line etc the deleted file remain in the SUI media list until the next rebot (but can't be played)
 
Black Hole said:


When I originally posed this topic, it was on the presumption that some kind of property (separate from the Lock flag) was being recorded in the .hmt file, which could be cleared automatically by a Custom Firmware process. This has proved not to be the case, and is in fact a consequence of an inaccessible state variable in the Humax code (which is why the problem resolves when the unit is rebooted).
Click to expand...

Black Hole said:
Nothing significant there, so far as shows up in the hmt output.

Have put the .hmtx and .hmty in the attached zip for inspection.
Click to expand...


Maybe you are looking in the wrong place?

I have noticed that when a recording is played the 12.9kb 0.Hmt file disappears from mnt/hdr2/tsr . When trying to access the Humax portal 0.hmt still is gone. Exiting the portal and 0.hmt is recreated however the recording is no longer playing and the option to delete the recording that was playing is greyed out.

Using FTP you can move (mv) the 0.HMT file (12.9kb) to the folder of the played recording. Switch names of the O.HMT to the affected recording hmt (2.0kb) and unfortunately the delete option is still greyed out....however

When you resume and stop the recording with that HMT the recording then as above allows the delete option but instead of a new 2.0kb hmt file being formed the hmt remains at the 12.9kb size.

If it was me I might ask what is in the extra 10.9kB. And why use the hmt to as a storage unit for that data?
 
OK, thanks for the interesting observation.

It is odd the 0.hmt file comes and goes. Why bother deleting the file? However, the occasions you say it is disappearing correlate with when the 0.ts buffer is not operating so this does not seem completely off the wall, maybe the presence of the file is a flag to enable the TSR system.

Why is the 0.hmt so large? That's interesting, so far as I know this was not known before, or at least not mentioned by anyone. 0.ts is a circular buffer, so writing to and reading from it requires management of pointers. However, the pointers shouldn't need that much storage space (and IMO would be better kept in memory, or at least the 0.nts). Could we work out what is inside the 0.hmt? Only if the data is in text form - with only the one example, there is nothing to compare and contrast (normal .hmt files were reverse-engineered by observing many examples correlated with their effect on their associated recordings).

It is my view that the greying out of OPT+ for in-limbo recordings is deliberate design, and the lack of greying out of OK is a design error. Could the flags for any in-limbo recordings be in 0.hmt? I doubt it, because (as you say) the 0.hmt gets deleted and recreated each time the TSR stops, but in-limbo status persists on multiple recordings over multiple TSR stops, and even with TSR turned off: Menu >> Settings >> Preferences >> Recording >> Time Shift Recording = On | Off (0.hmt is not present when TSR is turned off, but 0.ts and 0.nts persist).
 
The 0.hmt file seems to be a normal HMT file:
Code: 
# hmt /media/drive1/.tsr/0.hmt
Format:SD
Title:
ITitle:Robert Elms
Channel:721 (BBC Radio London)
Episode:0,0/0
Folder:/media/drive1/.tsr/
Filename:0
Genre:Entertainment (48)
EPG:Singer Ego Ella May speaks about the release of her debut album 'Honey For Wounds'.
Raw file is encrypted on disk.

Recording Status: Zero length (OK)
Flags: SD,New,Unlimited Copies,ODEncrypted,Radio,
Copy count:0

Scheduled start:1593162000 (Fri Jun 26 10:00:00 2020)
Scheduled duration:12600
Recording start:1593162452 (Fri Jun 26 10:07:32 2020)
Recording end:4294967295 (Wed Dec 31 23:59:59 1969)
Duration:2701804843
Stored duration:0
Play resumes at:0 seconds in.
Timezone offset:3600

Service ID (SID):6148
Event ID:8101
Transport Stream ID (TSID):4164
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):3200
Video PID:3202
Audio PID:3202
Bookmarks:0 = 

EPG Blocks:2
  Block:1 Time:2 Offset:0x30c0
    Block1_Title:Robert Elms
  Block:2 Time:0 Offset:0
An audit of HMT files in one Video directory shows a distribution of sizes 2072, 13184, 13888 bytes, with no obvious (to me) relationship to the recording parameters. Doubtless the Wiki page documenting the HMT format shows how these sizes might be achieved.
 
Black Hole said:
Why is the 0.hmt so large? That's interesting, so far as I know this was not known before, or at least not mentioned by anyone.
Click to expand...
hmt files also include EPG fragments at the end which makes them variable size. hmt can show summary information about these - here's my current 0.hmt (13K)
Code: 
EPG Blocks:2
  Block:1 Time:0 Offset:0x30c0
    Block1_Title:Your Money and Your Life
  Block:2 Time:0 Offset:0
 
You must log in or register to reply here.
Back
Top