<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
Chris Petersen wrote:<br>
<blockquote type="cite" cite="mid1062209433.1217.13.camel@hanuman">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">ok, this was going to be my thought. it *should* be 72, but for some
reason my machine only works when I specify 53.
</pre>
</blockquote>
<pre wrap=""><!---->
Ok, I think my computers are just whacked. I tell them to read 53
bytes, they SAY they read 53 bytes, and produce a string that says it's
53 bytes long, but if I upack the string, I get an array with 72 entries
in it, and my file handle is essentially at position 72 (because the
next read works fine). If I tell it to read 72 bytes, it reads
something wacky like 127 or 128, but like before acts as if it only read
72.
Anyway, since this happens on both of my redhat 9 machines, I'm forced
to believe that it's something wacky in redhat's version of perl, and
have implemented a workaround that shouldn't affect anyone else - I read
in 72 bytes, and then seek to the 72nd byte (which should do nothing on
machines that work properly, and will put the file pointer where it's
supposed to be on machines like mine that read more than they're told).
All of the other reads seem to work fine.
</pre>
</blockquote>
I'm fairly new to MythTV so I'm not up on the details of everything yet
but I do recognize those numbers since I've played with a lot of MIME
encoding stuff a while back.<br>
<br>
When sending binary files through email you would use BASE64 encoding.
The common standard is to take every 53 bytes of binary data and
encoded it into a 72 byte ascii string that can be placed in an email
message. <br>
<br>
Maybe Perl or Myth changed the way it packs things now.<br>
<br>
Trevor.<br>
<br>
</body>
</html>