Beta [webif] 1.4.9-8

[bottletop]

....
This is just directory name confusion, which we already know the Humax software gets wrong.
Because BetaFTPD on the Humax doesn't support the FEAT command to show UTF8 support, and FileZilla is probably set to auto-detect, it fails and defaults to something else (seems to be assuming ISO8859-1 / CP1252).
You can set an option to force it. Details here apparently: https://hosting.xyz/wiki/hosting/ftp/clients/filezilla/utf-8/

Good call. Setting FileZilla/File/Site Manager/<entry name>/Charset/Force UTF-8 helps in navigating to directory and downloading files.

 

[escat]

Also check 3E2 with 741.

Everything should be 0x15. If it's not, then repeat the test to confirm, and then tell me the exact command you are using.

I've rerun the tests using the Webif rename option, with different SD and HD recordings. I've then examined the hmt files directly, and what is displayed on the screen.
In all cases of SD recordings, the 0x106937 prefix for the synopsis field at offset 0616 is unchanged.
In those cases of SD recordings where guidance is provided, the 0x106937 at both offsets 03E2 and 0741 is unchanged.
In all HD recordings, of course, all the relevant prefixes are already 0x15.
All other fields of interest appear to be correct, and there are no anomalies in the screen displays.

 

[prpr]

In all cases of SD recordings, the 0x106937 prefix for the synopsis field at offset 0616 is unchanged.
In those cases of SD recordings where guidance is provided, the 0x106937 at both offsets 03E2 and 0741 is unchanged.

Are you actually setting/editing these fields in any manner? They don't get changed just because something else changes in the .hmt file.

 

[escat]

Are you actually setting/editing these fields in any manner? They don't get changed just because something else changes in the .hmt file.

Thanks for your prompt reply. The only thing I changed, using the Webif Rename function, was the New Medialist Title, and the New Filename to match it. I specifically did not change the New Synopsis or the New Guidance Text. (Though I wonder whether this has any bearing on why the relevant string prefixes in the hmt file were not changed?) I did not edit the hmt files themselves. I also did a complete hex compare of the files; there were no other unexplained differences.

BTW, I also did some more testing on the hmt fields above offset 3000, where I did edit the file. Suffice it to say in summary that one can change the prefixes, the strings themselves, or even remove the whole remainder of the file, without having any discernible impact on what appears on the screen. I wonder if all the relevant fields are extracted on the fly from the transmission stream, rather then the hmt file?

 

[escat]

I specifically did not change the New Synopsis or the New Guidance Text. (Though I wonder whether this has any bearing on why the relevant string prefixes in the hmt file were not changed?)

I could have have done the test myself of course. If I do actually change the guidance and/or synopsis, then the prefix does get changed. I imagine that's easy enough to fix.
I notice that the same changed guidance is applied to both the two fields (offset 03E2 and offset 0741). In one of my tests, the two were different before the change ("Contains images and descriptions of real-life violent crimes" and "Contains descriptions of real life violence, murder and suicide"), but were the same afterwards. This may or may not matter, according to taste, I suppose.

 

[escat]

By design. Everything is converted to UTF-8 (0x15 prefix). This works OK on HD recordings. I haven't got round to testing it on SD ones, but don't really see why it shouldn't work.

They don't get changed just because something else changes in the .hmt file.

Apologies for the earlier blank post.

Can you clarify whether you expect the prefix in the Guidance fields to be changed even if their content isn't changed? I'm not sure whether the philosophy is to change all string prefixes into 0x15, except the 029A Title field, or only those that meet some criteria. Sorry

I've also been looking into Raydon's statement (in his hmt format guide) to the effect that SD recordings use the prefix 0x106937, whilst HD uses 0x15. This is certainly true for the great majority of my recordings. But I have found exceptions - all recent - where SD recordings have 0x15 prefixes. Most commonly, this is on channel 56 (5Select). Since this is broadcast on the BBC HD Mux, I thought that might be the explanation. But I have other examples on channel 11 (Sky Arts) and channel 57 (Smithsomian Channel). These are both on the ARQ A Mux. Is any of this relevant?

 

[prpr]

Can you clarify whether you expect the prefix in the Guidance fields to be changed even if their content isn't changed? I'm not sure whether the philosophy is to change all string prefixes into 0x15, except the 029A Title field, or only those that meet some criteria.

The prefix is part of the string and only gets changed when you write to that particular string. It'll change if you just save the guidance string without editing it (a null save as I referred to it earlier), but it won't change if you edit the title for example.

I've also been looking into Raydon's statement (in his hmt format guide) to the effect that SD recordings use the prefix 0x106937, whilst HD uses 0x15. This is certainly true for the great majority of my recordings. But I have found exceptions - all recent - where SD recordings have 0x15 prefixes. Most commonly, this is on channel 56 (5Select). Since this is broadcast on the BBC HD Mux, I thought that might be the explanation.

It probably is. WIthout having any direct evidence, I would expect anything on a DVB-T2 mux. to use UTF-8 and the DVB-T muxes to use ISO-6937.

But I have other examples on channel 11 (Sky Arts) and channel 57 (Smithsomian Channel). These are both on the ARQ A Mux. Is any of this relevant?

Probably not. Maybe there is a gradual drift away from 6937 to UTF-8 then, even on DVB-T muxes. It makes no difference to the Humax. And it seems to prove that the current way that hmt and webif work is now an acceptable way of doing things, which is good.
I'll get round to updating the Wiki at some point.

 

[/df]

... examples on channel 11 (Sky Arts) and channel 57 (Smithsomian Channel) ...

Probably because these are new to Freeview, deriving from HD material available on satellite and streaming platforms.

 

[MymsMan]

I have been using the newly revised Play from webif browse and I am finding it useful but have a couple of thoughts:

• The downloaded .m3u playlist files are cluttering my Downloads folder - is there a way to directing them to a temp folder that will be automatically cleaned up?
• The play function works with DLNA indexed files but not with those that are not indexed, Should it work?
• It can take a while before the Humax indexes a file especially after a Move or Rename.
• The DLNAhelper function shows that we can dynamically add usable entries to the DLNA database so I was wondering if we could create a webif function to add a full DLNA entry for a recording when needed.
• This function could either be invoked from Play when asked to play an un-indexed recording or from Rename/Move/Copy or as a new queue-for webif/sweeper action.

 

[/df]

I have been using the newly revised Play from webif browse and I am finding it useful but have a couple of thoughts:

- The downloaded .m3u playlist files are cluttering my Downloads folder - is there a way to directing them to a temp folder that will be automatically cleaned up?

Mozilla on Linux puts them in /tmp/mozilla_xxx. May I suggest that this is a browser configuration issue, or, if there is no such configuration, a browser bug?

- The play function works with DLNA indexed files but not with those that are not indexed, Should it work?

If only you'd asked a year ago ... Yes, it should try to play an unindexed file but (obvs) will fail if it is encrypted. It doesn't know that the file to be played might be encrypted, as [system dlnaurl [file normalize $url] $urlbase] might fail because it's some imported media file unknown to the indexer.

It can take a while before the Humax indexes a file especially after a Move or Rename.
The DLNAhelper function shows that we can dynamically add usable entries to the DLNA database so I was wondering if we could create a webif function to add a full DLNA entry for a recording when needed.
This function could either be invoked from Play when asked to play an un-indexed recording or from Rename/Move/Copy or as a new queue-for webif/sweeper action.

There's a block of commented-out code in proc {ts renamegroup} (webif/lib/ts.class l.458-ish) that seems intended to update the index when a recording is renamed. Such a function ought to be in system.class, or a new .class for DLNA functions. I don't say that this isn't possible, but maybe there's a reason why that code is commented out.

 

[MymsMan]

Mozilla on Linux puts them in /tmp/mozilla_xxx. May I suggest that this is a browser configuration issue, or, if there is no such configuration, a browser bug?

This appears to actually be a deliberate new Feechur in firefox , it is also the behaviour of Edge and other Chromium browsers
Since I always prompt for save location when actually Saving I can set the default download location to Temp but still a PITA

If only you'd asked a year ago ... Yes, it should try to play an unindexed file but (obvs) will fail if it is encrypted. It doesn't know that the file to be played might be encrypted, as [system dlnaurl [file normalize $url] $urlbase] might fail because it's some imported media file unknown to the indexer.

The files are normal decrypted ts files that haven't yet been indexed
But I think the problem is that VLC can't cope with [] in the file name

Your input can't be opened:
VLC is unable to open the MRL 'http://192.168.1.76/media/My Video/[Bin]/Bridge of Lies/Bridge of Lies_20220404_1629x.ts'. Check the log for details.

It worked when I tried to play a file in a normal folder!

There's a block of commented-out code in proc {ts renamegroup} (webif/lib/ts.class l.458-ish) that seems intended to update the index when a recording is renamed. Such a function ought to be in system.class, or a new .class for DLNA functions. I don't say that this isn't possible, but maybe there's a reason why that code is commented out.

Agreed that it should be in a class file, interesting about the commented out code - something to think about when there are some spare tuits

 

[escat]

Thanks for all the help in getting to the bottom of my original problem. This appears to be resolved by leaving the Title field at 029A without any string prefix. I'm also grateful for the enhanced explanation of various fields of the hmt file that have been offered in the process. I'm happy to help with any further investigation or testing in this area if that would be useful.