[mythtv-users] Write failures partway through mythutil --copyfile

[Mark Perkins]

> On 29 Dec 2013, at 12:04 am, "John Pilkington" <J.Pilk at tesco.net> wrote:
> 
>> On 28/12/13 12:17, John Pilkington wrote:
>>> On 28/12/13 12:09, John Pilkington wrote:
>>> In MythArchive import, which has recently been working as expected, I
>>> have just had this failure after part-writing video files. The parts
>>> transferred during re-runs of the mythutil command line for two examples
>>> are 152 MB (2m 06s) and 66 MB (3m 57s); the source files are 2.2 GB and
>>> 1.5 GB.  Both SGs have adequate space available.  The CHANID implied by
>>> the filename (which is HD) does not exist on the importing machine, but
>>> MythArchive seems to have accepted one that does.  The files are SD
>>> converted from HD and play without problems. Any suggestions?
>> 
>> I should have said that all the files concerned are on the same FE/BE,
>> having been rsynced in.
>>> 
>>> mythutil --copyfile --infile '/path_to_xxx.mpg' --outfile
>>> 'myth://Default@192.168.1.4:6543/xxx.mpg'
>>> 
>>> 2013-12-28 11:05:59.935443 I  96468992 bytes copied, 5% complete
>>> 2013-12-28 11:06:01.948625 E  ERROR, couldn't write at offset 159383552
>>> 2013-12-28 11:06:01.960178 I  Wrote 159383552 bytes total
>>> 2013-12-28 11:06:01.960188 I  Waiting for write buffer to flush
> 
> mythutil --help tells me:
> File Options:
> --copyfile                       Copy a MythTV Storage Group file using RingBuffers
>  --infile                         Input file URI
>  --outfile                        Output file URI
> 
> In this case the input files were outside the SGs.  I could rsync into there myself, but then doesn't the copyfile operation seem unnecessary?  ISTR that I tried that some time ago, hoping to cut out  a copying step, and that failed too.
> 
> John
> 
> _______________________________________________
Does mythutil take a --verbose that might give additional messages as to what is going on?
It wouldn't seem to be permissions given that at least part of a file is transferred. And failing SG disks would seem quite implausible given it is happening on two different SG with (I assume) no prior problems.