I must be running a pre May 5th version; renamed the offending files to h264 and boxed them to readable mp4s successfully. I can add the renaming into my conversion batch file so it's all one operation. I'll try the new version (with backups) which should make the renaming unnecessary.btidey wrote:Changing Boxing mode should be the same from either browser control or raspimjpeg and seems to work for me. I can chnage in the browser, run a file and change it back again and end up with an h264 file. There was a 'feature' that unboxed files could still get labelled as .mp4 even though they weren't. That has been changed in recent versions after 5th May.johng wrote: Many thanks for your help. I think you're right. It's running on one of those BT extender things which is the only way that I can get ethernet outside the house and it had started to run really slowly (ping round trip approx 600ms). Have rebooted everything and now back running at good speed, almost the same as direct ethernet connection.
Having said which, I've left it running this morning saving to the SD card per default to get a comparison and I'll put it onto the windows share later. Will look through logs to get an example of boxing overflow.
I also tried turning off boxing by changing MP4 Boxing Mode to false via the browser. It continued to produce MP4 files rather than h264 but the files were unreadable (Windows media viewer, Quicktime and VLC viewer all rejected them). If I change MPBox4 in raspimjpeg to False does this do the same thing or will I get h264 files (which I can then bulk convert)? Presumably this would also kill the iframe errors?
Thanks again, Johng
One little trick that might be possible to help in situations like this is to use the macro facility to run a script after capture end commands. This can be done in the scheduler. This way you could always capture locally and then copy with the macro to its final destination.
Good idea with the macro trick but probably beyond my competence and would need a bit of research at my end so I'll stick with boxing later on the shared disk.
On the inframe issue, I saved to the SD card all this morning including background boxing and all is clean with no iframe errors. I transferred back to the windows share this evening with boxing turned off and I am getting iframe errors in the log. (Curious; I thought they were connected with the boxing).
So it does look as if, in my case, it's a timing issue caused by the network delay. I am trying to get my head round what happens but presumably it's
1. write h264 to shared drive
2. either keep a copy in memory at the pi or read a copy back to pi
3. box at pi
4. write boxed mp4 to shared drive
5. delete h264 on shared drive.
I gather the new version has additional debugging info logged; I can produce iframe errors at will so if logs would be useful, let me know. I could do with boxing enabled and disabled.
I won't be able to update to the new version until late this evening as I'm currently copying today's mp4s from the SD card (I don't have access to it as it's in a nestbox).