Video recording bug
Closed this issue · 21 comments
I was using this the first time today and it was amazing. However, I found a small problem when recording videos today.
I finished a 2:xx 7x7 solve and pressed CtrlR to view and save the video. The video did not load. Instead of trying again, I started the timer after scrambling, and no further videos were able to be viewed or saved, despite the camera stiil turned on.
There is probably an issue somewhere with the code starting and stopping the timer regarding video recording.
Also, can you add a video autosave feature?
Nice time! To confirm, the video recorder was working fine before the 7x7 solve, but then didn't show the video and then wouldn't show any other videos. What operating system are you using (so I can help pinpoint the issue)
Basically after the solve the video stayed as the previous one. One more aolve and it was blank.
I'm using Ubuntu 16.04
It appears the final video file may become too large and won't save properly. It looks like this depends on how much memory you have. With 16GB of memory, I could save a video larger than 4 minutes. Try closing some other programs if you intend to have longer solves. Sorry for the inconvenience but there doesn't appear to be a simple solution for this issue.
That seems weird. My computer has 12G RAM and the saved file is only 50M or so.
I'll see about adding a debug log to find the bug.
Happened again just now, but future videos are recorded this time. I think the reason for the error is actually corrupt video files.
I appears the issue is with this function (screenshot), which recursively calls itself until it takes up to much stack memory. There was an update to RecordRTC that fixed the issue and I have carried over that fix. However videos now take a bit longer to process before being displayed so I will add an indicator for that. This should resolve the issue.
So any plans on adding an autosave feature?
Yes! That's a great suggestion and I'll be adding it shortly.
Just an additional comment on the autosave, this is the filehame convention I use to keep all solves in order:
eventname date(yymmdd) clocktime(hhmm) solvetime(xxx.xxx)
The current format I have is Event SessionName RecordNo so a file would look like 3x3x3 2017-5-31 2 for the second solve in a session. RecordNo could be replaced with the current time though. What do you think?
This issue should be resolved now. Videos take a bit longer to process so an indicator is shown on the preview button. The autosave functionality is also available.
I thought about using the current time instead because solves can be deleted and mess up the numbering
Actually the using session name is a bad idea too. The default session names contain the / character, causing the save to fail. Otherwise the feature is working properly.
The next version uses an updated version of node-js which has format YYYY-MM-DD by default but if people used old sessions or had a / in there name then there would be issues. Any / could be replaced with - when saving which would solve the issue. It becomes much easier to find the correct recording if the event and session names are listed. I think using the current time would be a good idea instead of the record number.
After tesing the feature a bit, I found several issues with saving the videos. These problems can happen when the cuber restarts the timer by accident before the rendering is complete. The normal way to solve this would be to use a thread, but I'm not sure if that is possible in js. Maybe adding a confirmation dialog for discarding the recording can help. Adding that confirmation on exit wouldn't be a bad idea either.
You can use an async library, but the recorder would be interrupted regardless. A better option would be to add a warning dialog if the user attempts to start a solve while it is still rendering. This wouldn't appear very often as the rendering will usually be done by the time the user finishes scrambling their puzzle , but if the timer is started again unintentionally, this will help.
By setting up a new recorder each time, the old one can finish rendering and a new recorder can record the next solve independently. So there is no interruption required. This change has been made.
I got two more crashes. One was on a PB :(.
The error was that the recorder.blob property cannot be read due to a 404 error.
I did 30 3x3 solves and had no troubles. Were they longer solves, about what length? Do you know the output resolution? Some information about what happened before would be useful.
I changed the code to record at 640x480 with 30fps. The first crash was on a 2:17 and the second one 2:30. On the 2:30, the development console showed that the blob size was around 56M. Just got yet another crash. The crash appears to have made all future videos to fail as well.
I set my resolution to 640x480 and I could record for 10 minutes and the 111MB file saved fine. Do you have all the current changes in 1.0.2, including adjustments to the RecordRTC file?