• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

standard UI shows a recording not present on disk

cdmackay

cdmackay

Active Member
[although this doesn't perhaps relate directly to CF, I use CF features to illustrate the problem, hence filing it here]

I have a video recording showing up in the standard on-telly UI, but there is no such file shown by WebIF, nor from the cmdline.

From this, I assume that the file clearly no longer exists (it was a valid recording, which was watched and deleted), but the standard UI for some reason seems to think that it still exists.

The WebIF Browse view does not show the file, which is at the top-level of recordings.

Logging in via ssh, in /mnt/hd2/My Video, the recording and associated sidecar files do not appear using ls -a. There are no other extraneous files in that dir.

From the standard on-telly UI, the recording (Sarah Millican: Outsider) is shown as in this link here

when you try to play it, it says: Recording failed: unknown error.

The Info button does nothing.

In all other respects, the Humax is working correctly, both from standard UI and CF. i.e. the standard UI for that top-level dir is showing/playing other new recordings as normal.

Any idea how I get the Humax UI to wake up to this recording's deletion?

I don't think that this can have anything to do with fs corruption, since ls shows nothing untoward other than the fact that the file is no longer there.

I assume that the file is stuck in some Humax db list of recordings, which for some reason isn't getting refreshed. But just for that file?

…

edit: the system has been power cycled regularly (daily), to fully off, many times since the problem was first noticed a few weeks ago.
 
Web interface version: 1.4.2-3
Custom firmware version: 3.03 (build 2368)
Humax Version: 1.03.12 (kernel HDR_CFW_3.03)
Loader Version: Unknown - 012d
System ID: 80bc.7e00
 
Out of interest: does this unit go into standby correctly, or just delinquent standby?

I wasn't aware the SUI used a database to compile the media list (other than the implied file system database); it certainly doesn't rely on the DLNA database, but you could try resetting that.
 
Black Hole said:
Out of interest: does this unit go into standby correctly, or just delinquent standby?

I wasn't aware the SUI used a database to compile the media list (other than the implied file system database); it certainly doesn't rely on the DLNA database, but you could try resetting that.
Click to expand...

that's very interesting, thanks.

It looks like it might be in delinq standby; it's not recording now, yet I can ping it, and reach the WebIF, which says "System is in standby." Yet its next recording is in 90 minutes, and it's not recording now.

I need to find your notes on standby…
 
Looks like I need to fsck the disk, to be sure.

Although that makes no sense to me: why should the Humax UI think a file is there when ls doesn't. I can't imagine filesystem issues resulting in that.
 
I should update the CF first though, I think, since I'm sure the newer versions have some diag/fixdisk improvements.

Will report back when I've upgraded CF and run fixdisk from maintenance mode.

Assuming that the delinquent standby issue doesn't interfere with the CF upgrade…
 
update: I powered-cycled the Humax via the rear switch; when it came back, the offending recording is no longer shown in the UI, which is good.

Even better, it's now going into proper standby, not delinquent half-awake.

Thanks very much indeed for the suggestion.

[I'll still go ahead with the CF upgrade although may postpone fixdisk until there's a problem]
 
I am always amazed when people haven't already tried a power cycle. :eek:It very often fixes 'faults' and should always be the first thing to try.:)
 
Trev said:
I am always amazed when people haven't already tried a power cycle. :eek:It very often fixes 'faults' and should always be the first thing to try.:)
Click to expand...

I'd not agree with always.

One might refer to rebooting solving many problems, and a normal Humax on/standby/on cycle generaly involves a reboot (with the obvious exceptions, like recording, during which you'd not want to power cycle anyway). A mains power cycle, on the Humax, should rarely be necessary, since so little is actually powered during normal standby.

In my case, there was no reboot on standby, since mine was only going to the delinquent half-awake state. I'd not noticed that, for various uninteresting reasons, unfortunately. Of course, from that state, I presume that a mains power-cycle is the only way to recover, resulting in a normal boot.

In general, and not just for Humax, the question of whether rebooting (or power-cycling) is always the first thing to try would depend on whether you want to understand the problem, or just quickly try to cure a fault with no interest as to its cause.

e.g. it's possible, in my case, that someone might have suggested looking at some log, or running some diagnostic code, or otherwise collect more info, whilst it was in the fault state. That might have been beneficial for me, and for others, if it resulted in a code change in CF, for example. Turns out not, in my case, of course, but it surely would be useful in some cases.

It's personal preference, of course, but I prefer to at least try to debug a problem first, before resorting to the big hammer :)
 
prpr said:
How do you know there isn't already a problem?
Just do it.
Click to expand...

By problem I meant a noticeable functional issue, as opposed to a latent fsck anomaly.

I am nervous about fsck on the Humax, since finding that Humax-formatted clean filesystems do not seem to fsck clean on other Linux boxes, e.g. when using a USB disk. I've reported that previously, although I don't think we ever got anywhere with it, and my friend reproduced the issue on his own boxes.

Since I don't understand how that can be, I'm a little nervous, especially presuming that the maintenance-mode fixdisk runs fsck with the -y yes flag to tell it to make any changes needed.

[yes, I have backed up my recordings and CF to other systems]

But perhaps it has a no-changes -n mode, so I will try that and see; I will update to the latest CF first though.

thanks again for the suggestions, much appreciated.
 
cdmackay said:
...There are no other extraneous files in that dir.
From the standard on-telly UI, the recording (Sarah Millican: Outsider) is shown as in this link here
when you try to play it, it says: Recording failed: unknown error.
Click to expand...
I know you said that when you login to the box there are no files associated with this recording. I have had similar "problems" on a 2000T and it is usually down to having a .hmt file with no .ts or .nts. You can't always assume that the filename of the .hmt file is what you think it is. Are you certain there isn't an orphaned .hmt file of any name at the top level (or at any level)?
 
EEPhil said:
I know you said that when you login to the box there are no files associated with this recording. I have had similar "problems" on a 2000T and it is usually down to having a .hmt file with no .ts or .nts. You can't always assume that the filename of the .hmt file is what you think it is. Are you certain there isn't an orphaned .hmt file of any name at the top level (or at any level)?
Click to expand...

It's a good point, but yes, thanks, I am sure there weren't. I logged in with ssh and ran ls -a at the top video level. Since there are just a few dirs there, and not normally any recordings, it was easy to be sure.

I also ran find -iname \*sarah\* on /mnt/hd2, and there was no sign of any files, of any type, matching the stale recording shown in the UI.

Since we don't think that the Humax software keeps a separate DB of recordings, I assume it was in an in-memory table. That wasn't be cleared, since Linux wasn't rebooting on standby, owing to the delinquent half-awake state.
 
I think the UI on the 2000T names the recording from the contents of the .hmt file not the name of the file. I assume the Fox-T2 is the same. What I wondered is whether there is any .hmt file that has "Sarah" somewhere around 384 bytes into the file? (grep rather than find?) somewhere in the file. What you need is some form of binary grep on all the .hmt files looking for "Sarah".
(Note: I did a test and put an orphaned file "bollox.hmt" onto my 2000T. It was a file belonging to a YourTV series Shark. The UI shows Shark, YourTV and the date. I renamed the file to just ".hmt" - a hidden file - and the UI shows the same details. If I try to play it, I get the same error as you reported).
 
Last edited:
EEPhil said:
I think the UI on the 2000T names the recording from the contents of the .hmt file not the name of the file. I assume the Fox-T2 is the same. What I wondered is whether there is any .hmt file that has "Sarah" somewhere around 384 bytes into the file? (grep rather than find?) somewhere in the file. What you need is some form of binary grep on all the .hmt files looking for "Sarah".
(Note: I did a test and put an orphaned file "bollox.hmt" onto my 2000T. It was a file belonging to a YourTV series Shark. The UI shows Shark, YourTV and the date. I renamed the file to just ".hmt" - a hidden file - and the UI shows the same details. If I try to play it, I get the same error as you reported).
Click to expand...

That's very interesting, thanks; I think we could use the hmt utility to find that, rather than grepping binary files. I'll try that later.

But as mine has been rebooted now, and no longer shows the problem, perhaps any offending oddly named hmt file for that recording has been cleared up automatically.
 
I tried:

Code: 
find /mnt/hd2/My\ Video -iname \*.hmt -exec hmt {} \; | grep -i sarah

but it didn't find anything. Will remember if it recurs.
 
You must log in or register to reply here.
Back
Top