WARNING: current CVS recording code not stable [ NOW FIXED! ]

[petur]

Mike, I get a bit worried when I read

http://taperssection.com/index.php/topic,83004.msg1117129.html#msg1117129 and
http://taperssection.com/index.php/topic,84121.msg1117466.html#msg1117466

It seems like the person who recently had a warning displayed on his display was using a svn version of 7 March 2007, not the REP..... (confirmation pending)

So far all _my_ recordings have been fine.

[jhMikeS]

Petur: Was going to mention before you ran out of IRC that I do know of trouble spots in the scheduler itself...I suppose I shouldn't delay repairs there and I'll give each bit of the threading a thorough exam. It's likely the cause of the blocking violations and perhaps this one as well.

[perjak]

I can only join jhMikeS: update....

Done yesterday!

Stability was verified for that in the field and in buffer checks.

What can I do to test? Just record and listen closely afterwards? Are there any messages on the screen if troubles occur?

How can I check buffer?

Thanks for all your struggle  8-)

Per in Denmark

[jhMikeS]

Warning: 0x00000001 -> PCM buffer overflow
Warning: 0x00000002 -> Encoder buffer overflow
Warning: 0x00000003 -> Both of those

Flashed over the time display.

[jhMikeS]

petur: also, I myself am confusing the two warnings...when I'm just not awake yet.   Well, no matter, Semayat had an encoder buffer overflow which could still be caused by that. Both iRivers have backlight fading? This has caused the scheduler to get borked on my H120 recording and must be due to the known scheduler issue. Well, I'm on that one since a solid base for everything must be in place since corrupting the scheduler with IRQ posts can kill threads permanently. That would also explain the inability to shut down since pcmrec must work for shutdown to proceed.

[petur]

Petur: Was going to mention before you ran out of IRC that I do know of trouble spots in the scheduler itself...I suppose I shouldn't delay repairs there and I'll give each bit of the threading a thorough exam. It's likely the cause of the blocking violations and perhaps this one as well.

Ah... ok... and sorry for running away just like that, things are getting a bit hectic at work...

Both iRivers have backlight fading? This has caused the scheduler to get borked on my H120 recording and must be due to the known scheduler issue.

of the irivers, only the h1x0 has fading, the h3x0 uses a different type of backlight control that has less steps.

[perjak]

Warning: 0x00000001 -> PCM buffer overflow
Warning: 0x00000002 -> Encoder buffer overflow
Warning: 0x00000003 -> Both of those

Flashed over the time display.

For some seconds or will warning(s) be visible when the show is over and I take the iRiver out of my pocket? I usually do stealth recordings and when gain is set I park the iRiver in my pocket.

I only check it again if soundlevel at venue increases dangerously  

Per in Denmark

[jhMikeS]

The warnings stick until:

1) You leave the recording screen
2) You press stop and then start a new recording.

[jhMikeS]

Petur, here's an old flyspray task you might be interested in that strongly suggests the corruption on full disk is not a part of the recording code at all and is not new.

Reported 9 days before the introduction of codec based recording:

265 days old: Running out of space corrupts recorded file
http://www.rockbox.org/tracker/5852

[petur]

Petur, here's an old flyspray task you might be interested in that strongly suggests the corruption on full disk is not a part of the recording code at all and is not new.

Reported 9 days before the introduction of codec based recording:

265 days old: Running out of space corrupts recorded file
http://www.rockbox.org/tracker/5852

Thanks... I'll try to find some time to dive into that code (but most of coming week is already booked by real life)