In London we have (for now) 2 HD muxes. The SD channels I mentioned were all on one or other at some point, in particular when the recordings were made.
Essentially, yes: see https://hummy.tv/forum/threads/media-list-sort-order.10539/post-160886.
proc {ts renamegroup} at l.466ff in /mod/webif/lib/ts.class is called with prefix octal 25 == 0x15 at the end of the block containing /mod/webif/html/browse/rename.jim l.30:# find /mod/webif -name '*.jim' -exec grep -Hn '\\025' "{}" \;
/mod/webif/html/browse/rename.jim:30: set new "\025$new"
/mod/webif/html/browse/index.jim:114: if {[string index $bfile 0] == "\025"} {
/mod/webif/html/m/browse.jim:47: if {[string index $bfile 0] == "\025"} {
#
If it's not used by the standard F/W then why does it matter? Old recordings made on old firmware will just get moved to the new standard when modified. The hmt utility will still read either (discarding the char at 0x17F if it's the same as the one at 0x180, which is most likely an error - you can't be 100% certain).
humax /mnt/hd2/My Video/Les Miŝ‘rables # ls -ld ../Les*
drwxr-xr-x 2 root root 4096 Fri 18 Mar 2022 01:02:50 ../Les Mis?????rables
humax /mnt/hd2/My Video/Les Miŝ‘rables # ls -ld ../Les*|hd
00000000 64 72 77 78 72 2d 78 72 2d 78 20 32 20 72 6f 6f |drwxr-xr-x 2 roo|
00000010 74 20 72 6f 6f 74 20 34 30 39 36 20 46 72 69 20 |t root 4096 Fri |
00000020 31 38 20 4d 61 72 20 32 30 32 32 20 30 31 3a 30 |18 Mar 2022 01:0|
00000030 32 3a 35 30 20 2e 2e 2f 4c 65 73 20 4d 69 73 cc |2:50 ../Les Mis.|
00000040 82 e2 80 98 72 61 62 6c 65 73 0a |....rables.|
0000004b
humax /mnt/hd2/My Video/Les Miŝ‘rables # pwd|hd
00000000 2f 6d 65 64 69 61 2f 4d 79 20 56 69 64 65 6f 2f |/media/My Video/|
00000010 4c 65 73 20 4d 69 73 cc 82 e2 80 98 72 61 62 6c |Les Mis.....rabl|
00000020 65 73 0a |es.|
00000023humax /mnt/hd2/My Video/Les Misérables # ls -ld ../Les*
drwx------ 2 root root 4096 Sun 27 Mar 2022 19:20:30 ../Les Mis??rables
humax /mnt/hd2/My Video/Les Misérables # ls -ld ../Les*|hd
00000000 64 72 77 78 2d 2d 2d 2d 2d 2d 20 32 20 72 6f 6f |drwx------ 2 roo|
00000010 74 20 72 6f 6f 74 20 34 30 39 36 20 53 75 6e 20 |t root 4096 Sun |
00000020 32 37 20 4d 61 72 20 32 30 32 32 20 31 39 3a 32 |27 Mar 2022 19:2|
00000030 30 3a 33 30 20 2e 2e 2f 4c 65 73 20 4d 69 73 c3 |0:30 ../Les Mis.|
00000040 a9 72 61 62 6c 65 73 0a |.rables.|
00000048
humax /mnt/hd2/My Video/Les Misérables # pwd|hd
00000000 2f 6d 6e 74 2f 68 64 32 2f 4d 79 20 56 69 64 65 |/mnt/hd2/My Vide|
00000010 6f 2f 4c 65 73 20 4d 69 73 c3 a9 72 61 62 6c 65 |o/Les Mis..rable|
00000020 73 0a |s.|
00000022é which results in ŝ‘ ?
Which version are you talking about? I'd expect that from 1.03.12, as that's where it creates it.
Sorry, poor explanation on my part. No, it is exactly as you say. The real surprise was to find that it didn't matter what was in this field, just as it doesn't matter what is in the path name at offset 0x'0080'. Raydon included the latter point in his Wiki documentation for the hmt format, but not the former.
The coreutils version of 'ls' seems to correctly display directory names.
That was just using the same Glums example that you posted.
s\u0302\u2018 should display as ŝ‘. NB: in my browser's monospace font the circumflexes are rendered horizontally offset to the right: ŝ vs ŝ.é is 0xc3a9.
I don't think I'm sufficiently interested to port it. Getting off 6937 seems to be a good thing in general, and we already have that.
Being completely ignorant of TCL/Jim, it's taken a while to produce a routine to remove the 0x15 character from my library of existing recordings. Although Jim's string-handling does make it easy simply to remove the 0x15, I did wonder what Jim technique could be used to actually set a specific hexadecimal value in a particular location in the hmt file. The binary function seems to be the natural way of doing it in TCL, but it doesn't seem to be present in the Humax Jim implementation. Of course, there are other ways to do this, for example using C cross-compliers or using the hmt routine itself. But is there a natural way to do it in Jim itself? Thanks for any suggestions.
package require binary; also package require pack. hmt is your writable open .hmt file (untested):proc write {fd data {fpos ""}} {
if {$fpos ne ""} {
$fd seek $fpos start
}
return [$fd puts -nonewline $data]
}
proc patch {hmt width offset value} {
pack data $value -intle $width
write $hmt $data $offset
}As the OP said, "Of course, there are other ways to do this, for example using C cross-compliers or using the hmt routine itself."
