Problem transferring some SD and HD recordings with Webif

[jack616]

FYI
&eacute (HTML) is ascii E9 (hex) - its perfectly "standard"
If I had to guess I'd say something somewhere is filtering on sets [a-z,A-Z,1-9] or mis-using a regex
Presumably if you're still stuck you could transfer the .ts to a PC and rename then recreate the sidecars with av2hdr
I had this isse last year I think and I'm pretty sure all I did was rename the file with the remote - but I'm not certain on that.
I can't imagine how you'd end up with " %C3%83%C2%A9 é " without some sort of corruption or wrong character table or miss use of utf8 maybe.

 

[MymsMan]

I'm not near a HDR-FOX to check, but I am pretty sure that you can only change the recording title with the remote control handset. Without custom firmware the only way to change the filename is remotely by FTP.

I did try it before posting, When you change the title with the remote control the file name does change to match the new title

 

[MontysEvilTwin]

I did try it before posting, When you change the title with the remote control the file name does change to match the new title

Fair enough, I have had chance to try it now and you are correct.

 

[MontysEvilTwin]

FYI
&eacute (HTML) is ascii E9 (hex) - its perfectly "standard"

Incorrect terminology on my part, I was struggling to find a suitable descriptor. What would you call it, extended character?

 

[Black Hole]

I did try it before posting, When you change the title with the remote control the file name does change to match the new title

Yes, I confirm this. The filename is the medialist title suffixed with the timestamp (even after the medialist title is edited via the SUI OPT+ rename option).

 

[Ezra Pound]

Incorrect terminology on my part, I was struggling to find a suitable descriptor. What would you call it, extended character?

I wouldn't go down that path, it will only start a prolonged exercise in 'Hair Splitting', let us just define them a characters that cause problems and characters that don't cause problems

 

[prpr]

&eacute (HTML) is ascii E9 (hex) - its perfectly "standard"

I can't imagine how you'd end up with " %C3%83%C2%A9 é " without some sort of corruption or wrong character table or miss use of utf8 maybe.

E9 becomes C3 A9 after one pass of UTF-8 coding.
After another one, C3 becomes C3 83 and A9 becomes C2 A9.
So something is doing this, not once but twice, and not decoding it.

 

[MontysEvilTwin]

I wouldn't go down that path, it will only start a prolonged exercise in 'Hair Splitting', let us just define them a characters that cause problems and characters that don't cause problems

I don't mind what they are called, but a succinct unambiguous name would be a bonus: by 'non-standard' I meant irregular rather than not conforming to a technical standard.

 

[prpr]

Non-ASCII. ASCII was originally 7 bits. Extended ASCII is 8 bits.