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

[John Pilkington]

On 28/12/13 21:16, Mark Perkins wrote:
>
>> 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.

Yes: should have tried that. This is with -v most.  It got further this 
time, and it looks to me like a read problem before the 'couldn't write' 
message.  The *** are mine.  And I meant adequate space in each of 2 
folders on different spindles within the default SG.

2013-12-28 23:09:14.759859 I  MythSocket(1f159a0:18): write -> 18 49 
   QUERY_FILETRANSFER 81[]:[]WRITE_BLOCK[]:[]2097152
2013-12-28 23:09:14.775100 I  MythSocket(1f159a0:18): read  <- 18 7 
   2097152
2013-12-28 23:09:14.790999 I  MythSocket(1f159a0:18): write -> 18 49 
   QUERY_FILETRANSFER 81[]:[]WRITE_BLOCK[]:[]2097152
2013-12-28 23:09:14.801092 I  MythSocket(1f159a0:18): read  <- 18 7 
   2097152
2013-12-28 23:09:14.813075 I  MythSocket(1f159a0:18): write -> 18 49 
   QUERY_FILETRANSFER 81[]:[]WRITE_BLOCK[]:[]2097152
2013-12-28 23:09:14.823507 I  MythSocket(1f159a0:18): read  <- 18 7 
   2097152
2013-12-28 23:09:14.839466 I  MythSocket(1f159a0:18): write -> 18 49 
   QUERY_FILETRANSFER 81[]:[]WRITE_BLOCK[]:[]2097152
2013-12-28 23:09:15.051279 I  MythSocket(1f159a0:18): read  <- 18 1 
   0                                                         *****
2013-12-28 23:09:15.051315 E  ERROR, couldn't write at offset 1023410176
2013-12-28 23:09:15.051323 I  Wrote 1023410176 bytes total
2013-12-28 23:09:15.051328 I  Waiting for write buffer to flush
2013-12-28 23:09:15.051492 I  MythSocket(1f159a0:18): write -> 18 30 
   QUERY_FILETRANSFER 81[]:[]DONE
2013-12-28 23:09:15.054854 I  MythSocket(1f159a0:18): read  <- 18 2       OK
2013-12-28 23:09:15.054900 I  (0x1efaba0)::DecrRef() -> 0
2013-12-28 23:09:15.054917 I  MythSocket(1efab90:20): MythSocket dtor : 
cb 0x0
2013-12-28 23:09:15.058482 I  (0x1f159b0)::DecrRef() -> 0
2013-12-28 23:09:15.058497 I  MythSocket(1f159a0:18): MythSocket dtor : 
cb 0x0