Webif browse files missing bottom section

MymsMan said:
A bit extreme, does the services menu show whether betaftpd is running?

Just use Putty, Telnet or the webshell command line (on diagnostics page) to give you a linux command line where you can rename the errant hmt file
You should then be able to use the sidecar tools to rebuild a valid hmt.
Click to expand...
I thought it would seem a bit OTT but I've not had much luck in the past when I've tried to use code.

Having said that, I got lucky this time and after a bit of googling and reading the wiki, I managed to delete the original hmt file via Telnet and then recreate a new one using sidecar.

I'm happy to report that everything is back to normal again.

Thanks everyone and apologies to Andrea Edwards for not taking your suggestion more seriously.
 
Good news.

To fill in what previous posters no doubt understood, the genre member of a ts is normally populated from the output of the hmt -p command, which doesn't provide any error code: therefore the only way to check that the output is valid is by sanity checking each value. This isn't done at present, which explains how the title member can be set to "Invalid HMT file, /media/My Video/Who Dares Wins_20201223_2200.hmt", as displayed to OP.

In the OP's webif version, what was happening is that, while trying to display the line corresponding to each recording (l.330 foreach file $files { entry "$dir/$file" }), the proc entry {file} {{i 0}} routine failed for the suspect recording because the genre info for the recording is invalid, and there is no error check or trap protecting the genre code. As above, in this case all other HMT-derived data was junk as well.

This check replacing l.138 set omenu opt in /mod/webif/html/browse/index.jim should make the Webif display treat a .ts file with an invalid HMT as if the HMT was missing (ie, like a generic .ts video file):
Code: 
                if {[$ts get definition] eq ""} {
                        set type gen
                        set ts 0
                        set img Video_Other
                        set omenu oopt
                } else {
                        set omenu opt
                }
In this routine, the object representing the recording is instantiated in a way that assumes it is a .ts with a valid .hmt, so the preferable approach of failing to instantiate (returning 0 instead) would have unwanted side-effects. The value assigned to the definition member is created in the hmt program (ie not read directly from the file), and is always either "SD" (Radio, or SD flag set) or "HD" (HD flag set); if the HMT is invalid or missing, definition is set to the empty string.
 
The thing (well, one of many) I hate about Jim script is that there is apparently no way to tell if a variable is numeric or not before feeding it to a subsequent operation which then complains if it isn't.
(I found similar with Python the other week when looking at crashes in opkg-make-index where it was trying to conduct some operation on a different variable type to what you thought it was, because of an assignment somewhere upstream changing the type. This sort of crap with interpreted programming languages drives me absolutely insane - it just makes things so unreliable and generates consqequential bugs whenever you change anything.)

It seems in this case that the only way to stop a numeric operation effectively crashing is to actually let it crash inside a [catch {} ] command and then return 0. So I was going to propose replacing as follows, the crash being caused by $genre being an empty string:
Code: 
humax /mnt/hd2/mod/webif/lib # diff -u ts.class~ ts.class
--- ts.class~
+++ ts.class
@@ -807,7 +807,8 @@
 }

 ts method genrenib {} {
-       return $($genre >> 4)
+       if {[catch {set v $($genre >> 4)}]} { set v 0 }
+       return $v
 }

 ts method genre_info {} {
 
/df said:
the genre member of a ts is normally populated from the output of the hmt -p command, which doesn't provide any error code:
Click to expand...
Yes, and it outputs the error message on standard output rather than standard error too. This really is very daft (polite version).
 
Thanks. I did search the documentation several times trying to find something like that. That (the documentation) is another thing I hate - you need to know what you need to know before you can know it.
 
Thaddeus said:
I'm happy to report that everything is back to normal again.

Thanks everyone and apologies to Andrea Edwards for not taking your suggestion more seriously.
Click to expand...
But because you deleted the .hmt rather than saving it (eg by renaming it .hmtx), we can now never know whether it really was a broken .hmt or a .hmt containing unexpected data. Either way, the WebIF code needs fixing so it doesn't throw a wobbly if the data field doesn't happen to contain one of a few "valid" options.
 
prpr said:
Thanks. I did search the documentation several times trying to find something like that. That (the documentation) is another thing I hate - you need to know what you need to know before you can know it.
Click to expand...
I have read it too often trying to (re)find something - Far too much technical documentation is like that, it only makes sense if you are already an expert.
 
Black Hole said:
But because you deleted the .hmt rather than saving it (eg by renaming it .hmtx), we can now never know whether it really was a broken .hmt or a .hmt containing unexpected data. Either way, the WebIF code needs fixing so it doesn't throw a wobbly if the data field doesn't happen to contain one of a few "valid" options.
Click to expand...
Sorry. I did try to rename it with an mv code but it just seemed to hang without doing anything, so I decided to go double or quits with an rm which was more successful.
 
prpr said:
...So I was going to propose replacing as follows, the crash being caused by $genre being an empty string:
...
Click to expand...
A test in the ts::genrenib method would fix the crash, but not the more general problem that other fields that were assumed to have been set were actually set to empty strings when the HMT was present but invalid.

The ts::_parse method, which tries to set the ts object's members (instance variables) from the tab-separated hmt output, bears analysis.

The first line apparently tries to set the read-only built-in member vars, which presumably is ignored and ought to be removed.

Then the tab-separated hmt output is split and each value is assigned in turn to the listed variables: each variable is interpreted as an instance variable of the ts object if it is one, or a local variable otherwise (eg flags_list). But if there aren't enough values the remaining variables get set to "".

What's needed is something like this:
Code: 
# assign ts values from a string generated by proc {ts exec}
# var list as a default param to allow overriding by caller 
ts method _parse {hmtvals
               {hmtvars {title synopsis definition channel_num channel_name
                start end flags_list guidance bookmarks schedstart scheddur 
                genre resume status seriesnum episodenum episodetot}}} {    
                                                  
        # {ts exec} wraps "hmt -p", producing tab-separated data: listify
        set hmtvals [split $hmtvals "\t"] 
        
        # avoid setting unspecified vars to ""
        lassign $hmtvals {*}[lrange $hmtvars 0 $([llength $hmtvals] - 1)]

        set synopsis [xconv $synopsis]

        set flags [split [string range $flags_list 0 end-1] ,]
}
But if this was done, my proposal above for a check while displaying file entries would have to be reworked.
 
Last edited:
Thaddeus said:
Thanks everyone and apologies to Andrea Edwards for not taking your suggestion more seriously.
Click to expand...
Thank you for the apology, sometimes simple works better than coding yourself into a hole, though through this forum I have mastered or at least acquired some coding skills with reference to sweeper, thanks to Black Hole, who encouraged me, thank you Black Hole

I've had partial directory listings a few times over the years, whereby the file management section at the bottom is missing, it took several workarounds to come to the conclusion it was something corrupted from where the listing stopped, it seems you were thrown due to the corruption being in the last file

In handling the corruption, I create a temp folder and move files either using telnet or FTP, then you can use the WebIf to see a complete list in the original directory, (a refresh may be needed) the using the WebIf move those recordings visible in the temp directory, you may have to alter how the list is sorted

As an aside, rather than using FTP to move recordings from one Humax HDR to a second, I now have foxlink configured with a couple of 'if path exists' conditions, recordings are transferred automatically, after being decrypted and shrunk
 
Last edited:
Andrea Edwards said:
Thank you for the apology, sometimes simple works better than coding yourself into a hole, though through this forum I have mastered or at least acquired some coding skills with reference to sweeper, thanks to Black Hole, who encouraged me, thank you Black Hole

I've had partial directory listings a few times over the years, whereby the file management section at the bottom is missing, it took several workarounds to come to the conclusion it was something corrupted from where the listing stopped, it seems you were thrown due to the corruption being in the last file

In handling the corruption, I create a temp folder and move files either using telnet or FTP, then you can use the WebIf to see a complete list in the original directory, (a refresh may be needed) the using the WebIf move those recordings visible in the temp directory, you may have to alter how the list is sorted

As an aside, rather than using FTP to move recordings from one Humax HDR to a second, I now have foxlink configured with a couple of 'if path exists' conditions, recordings are transferred automatically, after being decrypted and shrunk
Click to expand...
Thanks Andrea. Hopefully things will be okay for me for a while but I'll bear your tips in mind if I come unstuck again.
 
You must log in or register to reply here.
Back
Top