Record trigger not responding w MPG
 

I used the NF on a job as a backup recorder. Since I had to film all day I decided to use mpg SD recording to be sure that I had enough memory on the flashcards. I used the embedded timecode trigger for starting the recording. The first one or two takes were ok but later on I discovered that the NF was not recording. I did some tests and every time after a reboot the recorder only starts the first few times. After that it just gives no recording indication. I decided to change to MXF recording as in this mode it seemed to trigger well. I had no time to look through the files yet.
Probably something to do with mxf not embedding time code and the new function which controls "older timecode" not to trigger the cam.
As so, there should be an additional parameter in the video/system menu giving you the choice to 'listen' to older time code or not... Or just leave this off when in mpg mode.
I tried the beta version.

Dear Ron,

I am alerting our engineers about your report.

I had something happen last evening along the same line - I wasn't going to report it because I couldn't consistently reproduce it. I was testing out the ability of the NF not to record when using the last clip review on the EX1 (I have it set for the entire clip). Indeed the NF did not record but when the camera returned to camera mode and I tried to record a clip the NF did not start recording. As I say, this only happened twice. I rebooted the NF and couldn't reproduce it although there was a 1-2 second delay between pushing the record button on the camera and the NF showing "RECORD" mode (is that normal - haven't really paid attention to this before ?).

I was shooting MXF@ 100mbps 1080 30p and the NF was set to record on embedded timecode. I was also using the latest firmware (V. 1.20) for the EX1. I also had the NF set with buffer "on". The NF has the new Beta firmware.

Addendum - had the camera set up this evening and I was able to reproduce the same behavior - it was sporadic and intermittent - at times the NF would not record at all (unless rebooted) after using record review on the EX1 and at other times it would. There was also the starting of recording being delayed by 1-4 seconds which was intermittent. I tried turning the buffer on and off and it did not affect this behavior - and no, I didn't start recording too early - I always waited until "Stopping" was not displayed and the green light was displayed on the NF. I hope this is not a bug in the new Sony EX1 firmware and it's interaction with the NF. It is late so I am not taking the next step - reverting back to the "production" NF firmware until tomorrow.

2nd Addendum - ok couldn't wait until a.m. switched back to 1.1.154 and problem resolved - of course the NF records the "record review" from the camera but there is no delay in starting recording on the NF when the camera's record button is pushed. Looks like I will skip the Beta for my upcoming spring break vacation - never had a single problem with the 1.1.154 firmware. Since this is the first time (unless I am mistaken) that this behavior has been reported, I wonder if many users just don't observe if there is a delay with the NF starting to record with the Beta firmware?

Audio corrupt as well
 

I looked through the mxf files I recorded. But there is something horribly wrong with the audio. On the left channel I have a full level/peaking hum. The audio was ok with the previous mpg clips, the next clip (3 minutes later after power reboot) as an mxf is corrupted in audio.
It stays that way throughout the whole day, also after moments i know i did a power down and up.
The backups are useless, luck that the cam recorded fine as usual... I better go back to version 1.1.178

Ron - don't you mean version 1.1.154?

Dear Ron,

For production use, we recommend 1.1.154.

Dear Berry,

I will alert our engineers to your findings.

yeah, sorry, 154 it is
any idea what could have happened with the audio?

Dear Ron,

I believe this to be a problem with our Public Beta, 1.5.31.

We will have a release with this corrected soon.

Dan - do you happen to know if your software engineers were able to reproduce the delay in the starting of recording of the Nano (after the camera record button is pressed) and if they were able to document no recording at all after "clip review" was activated and then the record button (on the camera) pressed to start another recording?

Which CF cards are you using, Barry?

Sandisk Extreme III 32 GB and Photofast 64 GB - freshly formatted (in the Nano with the new Beta Software). I am now back to the "approved" firmware and have had no issues.

The PhotoFast cards seem to be the common denominator...

Please try and establish whether your problems occur with both the PhotoFast and Sandisk, Barry :)

I am getting the camera and gear ready for our spring break vacation so will retest when I get home today. I am almost certain I tested with both cards with the beta software. I know, for a fact, that there is no delay in starting to record or failure to record (after clip review) with the Photofast with the old software (1.1.154)

Thanks Barry.

Too many unknown variables to draw a conclusion, except that my severe problems with 2x32GB PhotoFast cards started when I first upgraded to the newest Public Beta.

Before that (i.e. with the official 1.1.154 firmware), my nanoFlash/PhotoFast combo was working perfectly.

Considering what Dan has reported about the PhotoFast cards "losing the programming, internally, of its controller chip", this could have been somehow triggered or accelerated with the Beta features of the nanoFlash (see here: http://www.dvinfo.net/forum/converge...ash-cards.html).

At least this is what I'm seeing now here: after a full month of fighting with intermittent errors with my PhotoFast cards, I've been torture-testing a Sandisk Extreme card for a second day now, without a single glitch!

Wow - at $ 300 a pop I would hate to end up with 2 cards that are non-functional - unless something is improved in the new beta or the final firmware I will be stuck with 1.1.154 henceforth. Since my cards are 64 GB should that make a difference?

Dear Barry,

You will not be stuck with 1.1.154.

We are addressing the SlotDpc:0003 error.

Our next release will have special improvements in our firmware to eliminate this problem.

We have been trying to track down a reason why this was occuring with some cards and some nanoFlashes.

Our breakthrough occurred on Wednesday where we were able to duplicate this in our lab. We were able to pointpoint the problem.

We have added code to our next Public Beta firmware to resolve this issue.

We are delaying the release of the second Public Beta a few days to thoroughly test this change and a few other related changes in the way that we handle CompactFlash cards.


So, some, but not all of the SlotDPC:0003 errors can be corrected by this firmware update.

Other problems, such as a card that is unable to communicate with anything, such as the nanoFlash, a PC or a Mac, will not be helped by our new code.


Also, if there is a hardware problem, such as a broken solder joint in one of the CompactFlash card slots, then the firmware update will not help. In this case, a card may work in Slot 2, but not Slot 1.

Dan

Thanks for the response.

Does the "SlotDpc:0003 error" also involve the 1-4 second delay when pressing the camera record button before the Nanoflash starts to record and also the failure to record the next clip at all (unless rebooted) after the "record review" feature is activated on the camera?

Have these problems been able to be reporoduced in the lab for the new beta?

Dear Barry,

I do not know if the SlotDpc:0003 error has anything to do with the 1 to 4 second delay.
I am sorry, but I am not up-to-date on that condition.

But, please remember that we do not start recording, if you are using the timecode trigger, until the timecode advances.

If you are using the Public Beta 1.5.31 and triggering on Incrementing Timecode, if we receive a high timecode value, then recieve a lower timecode value, we will not record until the timecode is a higher value, or the nanoFlash is power cycled.

In the next release, this will be a menu option, with the default being the way we did it originally, "If the timecode moves, we start recording." (if you have the Tigger set to Timecode.

The menu option will be for those that want to review in camera and not have the nanoFlash start recording.

Dan - I have watched the timecode values displayed on the Nanoflash - with the 1.1.154 firmware there is absolutely no delay when the camera record button is pushed (triggering on embedded timecode). With the beta firmware, I did take note of the timecode value at the end of recording a shot and the timecode advanced to a higher level when the camera started to record but the Nano took 1-4 seconds before it "kicked in" and started recording.

Same way with the record review (with the beta) - once I had reviewed the last shot (I have the camera set for reviewing the entire clip and not just a few seconds) - the same timecode would be on the Nano as prior to reviewing the clip (it did not change since it did not record the clip over again). Then, when I started the camera recording again, the Nano did not record at all - just sat there with the timecode advancing in the window but no recording.

Why don't you retry after turning off the prebuffer and choosing 1080/59.97i as a test.

When I do this, it starts recording after a clip review, and does not take several seconds to begin either.

I have my PMW350K timecode set to "preset" and "R-Run." I believe the EX1 has same or similar nomenclature.

For the test, I would also suggest you uncheck the box for "drop frame."

The above is just to see if you can get it working again with the beta firmware, then one by one add back in the features until you can identify what's causing the hangup.

Tom- Thanks for the input - I did try it with prebuffer off for both the record review and just regular camera recording and the delays were still there. My camera is already set for "preset" and "record run". I also fiddled around with DF and NDF settings which made no difference (I assume they refer to Dropped Frame and Non-Dropped Frame). I did try a couple of other settings which included 1080i and it made no difference.

I wish I had the explanation then, because on the surface, this is illogical. If we're using the same firmware and settings with a different result, the explanation would seem to point to a hardware difference, perhaps board revision, cabling, difference in the flash memory, or camera. The common thread is we both have the beta software. Sorry I can't be any more help except to share findings.

Have a different BNC cable to try?

Again - I appreciate your input but am leaving for a cruise next Saturday and don't want to take a chance on any beta software "gotchas" while I am shooting video - even if the revised beta comes out there may be some new problems (like audio sync) that won't be recognized until people have thoroughly tested it out. When I get back, I plan on putting any new Beta on the Nano because I do like the feature of not recording on "record review". With the present firmware it is only a minor annoyance and easily corrected by deleting the clips after they are transfered to hard drive backup.

Actually, I have 3 BNC cables of varying lengths but didn't try all of them - when I went from the beta back to the 1.1.154 version I did not physically touch the camera (only removed and inserted CF cards in the Nano which is mounted very firmly on one of Olof Ekbergh's brackets) and when the old firmware was reinstalled the Nano worked perfectly. While tracking down the problem I did try undoing and retightening the BNC cable ends (I have a special screwdriver-like tightener for the part that goes into the camera) but it did not make any difference.

Understood. Good luck on the cruise. Remember to put the cam inside a large plastic bag, and warm it up on the balcony before shooting with it outside. If it goes straight from your air conditioned cabin to the high humidity outside (in warm climate), that condensate will fog inside the lens, everywhere...takes a while to dry out.

Balcony? Ha, ha! Try inside cabin - I count myself lucky to be going on a cruise at all - Obamacare hit those of us in Cardiology Jan 1 with Draconian cuts to reimbursement amounting to 40-50 % reduction in income (has nothing to do with pending "Health Reform"). Anyway to get back on topic - I will probably leave the camera in it's Think Tank bag and bring that with me on deck for awhile before exposing it to the heat and humidity of the Carribbean.

Dear Barry,

I will be discussing this with our engineers.

Any problems that might be caused by the Public Beta check the timecode for a higher value, if this is actually the cause, will be corrected by the next firmware.

We intended to put out the new firmware this past week.

However, we were seriously investigating the report SlotDpc:0003 errors that some were reporting.

We were able to duplicate the problem on Thursday, then fix it on Friday, and will be incorported into the next Public Beta this weekend. As soon as the new release passes our tests, we will be releasing it.

Dear Barry,

May I suggest that you use our QT or MXF mode instead of MPG mode?

MPG mode is really designed for minimal editing and does not have the quality options of QT or MXF modes.

If one is just recording an business presentation (or other events), where one has to create a simple DVD or Blu-ray with a minimal amount of work.

Please feel free to call or email me personally.

Cue Play does not seem to be working for me. With the Nanoflash connected via HDMI to an HDTV monitor, I had about 13 clips. It played through them all fine. Then I entered a value into cue play, and I think it did start there and play the first time (maybe), but thereafter if I entered a timecode for cue play somewhere into the 4th clip, it just always went back and started at the beginning of the first clip.

I also noticed something odd, if I scrolled through the playlist of clips, when I got to clip number 5 and number 6, it showed no value for the timecode, 00:00:00:00 for both clips. Most or all of the other clips had the correct timecode shown for them. As soon as I pressed PLAY, it did play properly and it did show the correct timecode, but not when just viewing the clip title by scrolling through the playlist.

Maybe I'm doing something wrong. It sure works great in all the important respects for me.

(This is with the public beta)

Dear Tom,

May I assume that you were using Internal Timecode?
(HDMI does not support timecode, it is not in the HDMI spec.)

We will look into this.

Dan,
I use the internal embedded timecode that increments when the camera record button is pressed, recorded to the Nanoflash over the SDI.

Yes, playback was over HDMI to the monitor. Is this what you mean?

In other words, not recorded with HDMI, just played back over HDMI.

Dan - I think you may have me confused with someone else's post unless I did a typo in one of my posts - I have never used any other mode other than MXF (@ 100mbps and 1080 30p) since I bought the Nano - you are right - using mpg defeats the whole purpose of having the Nano.

Not necessarily. As explained in another thread, one of the reasons I got my nF was to record the output of the graphics card of my computer for software tutorials. For that MPG is usually perfectly sufficient.

Dear Barry,

Yes, this was my mistake, sorry.

Ron was the original poster who mentioned using using MPG insteat of QT or MXF.

MPG has its uses, but it is not 4:2:2.

Dear Tom,

I just wanted to point out the if you were using HDMI, you would need to change Timecode to Internal in order to get timecode recorded.

If Timecode was set to Embedded, and you were using HDMI as the input, then you would probably get "00:00:00:00" timecode.