Support and General Use > Recording
BUG? RB freezing when entering Recording Screen while music is not stopped
jhMikeS:
You should be able to hold the on switch for 1 second and 8 seconds later it should be forced off. You might have to do it twice as the 8 second timeout is stopped on the first press in order to give rb all the time it needs to shut down gracefully.
jhMikeS:
So you have a backlight that is responding to the hold key? I ask since I usually use the lack of backlight activity as an indicator of a hard freeze which means the hardware has completely locked or halted. If the backlight remains active in any way (hold key or timeout), it's probably a threading issue.
I should say too that I've had my H120 freeze on recording when a backlight fade starts. Don't know if there's any common issue. I will look into this further in about five minutes.
jhMikeS:
Ok, was playing music, entered the screen, no lock. When to the recording menu via the recording screen...noticed that the source option is no longer displayed...started to select menu items and it locked. Backlight was still operating however so the lock was likely software. Two 1s power key presses invoked the emergency shutoff as expected.
jhMikeS:
Ok, will keep reporting observations as I make them be prepared for a litany of posts. :)
1) If I enter the recording screen when music is playing, I get a lock when trying to leave it with any souce selected but FMRadio. Usually the peakmeters are not operating even if the screen continues to accept input. This indicates that DMA is not being started for recording properly. The UI thread must still be working though or selecting volume and such would not be possible.
2) If I enter the recording screen without music playing, no locks occur.
3) Having a voice file present actually seem to stop the lockup (usually it's the other way around with this sort of trouble)
I can do this pretty much every time it seems. This never would have passed my tests since it all worked before committing the recording revisions and voice/no voice was a big issue in debugging. I do not know why x5 picked up so many ticks while I was forced out for awhile.
On Nov 27 and 28 I added some changes that deal with stopping music when the audio buffer is requested or else corruption would result at times. On Dec 05 I committed an opto out change for the H120 which should have no x5 effects. On Dec 06, I made some revisions to DMA handling for the raw pcm portion. One change there lead to DMA stopping prematurely but the cause was identified and fixed quickly.
I think I know what to look at given all that. My x5 was not available for testing by Dec and it seems it has timings different from other players. None of this should be timing dependent so race conditions come to mind (no suprise in the playback.c mess).
jhMikeS:
I'm guessing at this point that the encoder loading never returns for some reason. Since the screen is visible the recording thread initialization has passed through obtaining the buffer. The UI thread is let go just before loading the encoder but will be blocked if the recording thread never returned from setting the recording options when it tries to tell the recording thread to uninitialize recording since the recording thread is busy waiting for the encoder.
That's my best theory and will confirm with some logf debugging and splash screens. Then I'll get to formulating a solution.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version