[Richard O]

Thanks – I’ll try them shortly
regards
Richard

[Richard O]

Hello there
I’m doing both straight HD version and downconverts. There is a latency with the downconvert, but a +1 frame offset in the device settings takes care of that – but I still then get the 2/3 success rate! And its exactly the same when I go straight HD – I don’t have to put an offset in then, but I still get a 2/3 ish success rate.
thanks for your interest!
Richard.

[Richard O]

Aha – thanks for the quick reply. I’m off for a thorough trashing now.
all the best
Richard.

[Richard O]

Hi Bob

The supplier’s solution was to send new cables and terminator and driver software. This has made no difference! Thought you’d be interested to see their response regarding the ‘spiking’ data rates on the Kona drive:

“With regards to the diskwhack test, it is only the write/read figures on the
main window that should be taken in account, as the graph will show those
kinds of results with any drive or free space. The main screen shows the
read/write to be above 200MB/s, which is fine for HD & indicated no problem
with the drive.”

I’m not sure how that logic works, because surely any point the drive dips below 100mb/sec, it is unable to feed HD at the full frame rate? That seems to make sense to me.

They also suggested that my free disk space may be an issue – i’m down to about 5%. I’m trying to free up some more now, and see if it helps.

all the best
Richard.

[Richard O]

Thanks again. I’ve arranged for another RAID to be loaned to us, so I can copy all of the media across and then format and check the original array. I’ll make sure they look at the cache and firmware issues.
regards
Richard

[Richard O]

Hi Bob

Thank you very much for this advice. I have now run the test and looked at the graph, and your suspicions are correct. The read speed sits at around 280, and the write at around 225, but there are around a dozen big spikes on both read and write where it drops down to under 75. I ran the test twice and got similar (but not identical) results.

I think this sound like the cause of my woes.

In your experience, is this problem solved only by reformatting? I have heard that defragging of SCSI arrays is a dodgy affair. I can’t afford to lose this media, of which there’s about 2.1TB. I flagged this problem up to the supplier of the hardware back in February, and then in May, airing my suspicions that it may be a drive problem. They never advised me to run this test though (they did advise that I trash my preferences. Then that I defrag. Then, a week later, that I definitely DO NOT defrag! It was at this point I began to lose faith in them….).

So, thanks for your advice so far – its better than I’ve got from the supplier! Any further recommendations will be very gratefully received.
regards
Richard.

[Richard O]

Thanks for your reply.

I’m getting the pops on the external display. If I use the razor blade to cut either side of the dissolve, I still get the pop, because it is the rendering of the dissolve that changes the colour/luminance. So there remains a noticable change at the point that the dissolves start and end. For now I’m just going to keep using the mysterious workaround of changing all dissolve clips to ‘alpha type – straight’, and rendering the whole clip.

regards
Richard.

[Richard O]

Thanks for your posts on this topic. The external waveform monitor was, of course, very enlightening. Seems that the chroma is fine but the luma is ‘buzzing’ – bubbling over the legal levels at top and bottom. Interestingly, this happened when Final Cut was removed from the equation and I was viewing the Kona’s own test patterns. Crucially, this problem only occurs when the native format is 1080i and it is downconverting to 625 standard def. If it is standard def throughout, with no downconversion, the luma is all stable and lovely.

The extremely friendly tech guy at Aja in California reckons on it being a hardware fault on the card itself, so a new one is on its way now. I’ll let you know how it goes!