Automated recording times possible with H320?

[cbr12]

I have recently noticed that the countdown timer is a little bit slow. For example, when I record a 1 hour segment each day at 6 o'clock with a record repeat set every 1 day the next recording will be approximately 13-14 minutes later then what I intended. For the first day it will  record from 6:00-7:00, the next day it will record 6:13-7:13, the next day 6:26-7:26 and so on. Is there any way the timer can be calibrated to be more precise?

[Mmmm]

Oh bugger.... really?
Does this also happen if you only use the countdown timer over 1 day? ie not the repeat timer? It'd be good if we knew exactly which one was causing the problem (as both functions are used with the repeat timer).

[Mmmm]

I've been running the timer for nearly 3 hours by itself and so far it seems to be keeping good time. your figures suggest it should lose about 0.5 seconds every minute I think, so I should have noticed something after 3 hours....
I'll leave it longer but this suggests it is purely the repeat timer code. I'll have a look at that some time..
It's a bit odd though because the repeat timer code is only executed once per cycle which means that 13 minutes are chopped off in one go... weird...It must be something fairly obvious then... hmmmmm....

[cbr12]

I dont think the timer is chopping it by 13 minutes in one cycle. It is a gradual process because the timer (at least on my Irivers) is not insync with with my watch. I just tried a 30 minute countdown trial and the Iriver timer was 18 seconds slower than my watch (This was not the record repeat timer). If you do the math that would account for about 14 minutes in a 24 hour period. I get the same results for the H120 and H320. Keep me updated if you figure anything else out or want me to try any other tests.

[bascule]

So is the RTC on your player at fault? That's what it sounds like, although I imagine that would be exteremely unusual...

[pixelma]

I understood the following statement...

The patch should work fine on any of the recording capable targets!

...as "it doesn't rely on the RTC but on the user timer" - so it should be independent from the RTC. Maybe I'm wrong here but otherwise this patch wouldn't work fine on (stock) H1x0s and OndioFMs (which would be of interest to me ).

[Mmmm]

Yes, the timer doesnt use the RTC at all. It has it's own tick task that should decrease the count by 1 every HZ ticks (ie every second). I haven't had time to look at it yet though to see why it is losing time as I've just started a new job and everything is a bit of a whirlwind about me!
I'll get around to it when things calm down a bit though..

[cbr12]

I may have narrowed down the problem a bit with the countdown timer. I checked the file names which are time stamped to see exactly how much of delay there was between days. With the record repeat set for 1 day and a split time of 4 hours I found that the recording started exactly 12 minutes later on the next day. The recordings were exactly 4 hours, therefore the 12 minutes were lost while counting down from 20 hours. Even though I hate math, I converted everything to seconds and tried figure it out from there. 20 hours = 72,000 seconds and 12 minutes = 720 seconds. If you divide 72,000/720 you get exactly 100. Im not sure how the timer was coded, but it seems that it is 1 second off for every 100 seconds.  

I found a temporary solution to work around this, you just have to change your record repeat time to adjust for the slow timer. For example, in this case instead of setting the record repeat to 1 day you could just change it to 23 hours and 48 minutes. Then it would repeat the recording every day at the same time. I hope this helps someone, but for those who dont like to do math it would be great to see the timer fixed if its not too difficult.

[Mmmm]

I've made an updated patchwhich may fix the above problem.... (it seems exact on a 2 minute timer anyway) Obviously a test with a longer timer will tell us if it has made any difference: the patch is on the tracker and here's the H1xx binary:

rockbox.iriver.H1xx

[cbr12]

Thanks, Ill give the new patch a try. Do you have a binary for the H300 too? I could test that out as well.

[Mmmm]

Ok, Here you go...

rockbox.iriver.H3xx

It should be the case that if it works on one of the targets , then it should work on them all (as long as it compiles) as it uses the same code regardless. But I suppose you can never be too careful eh?

[cbr12]

I tried the new binaries and I got the same results. The countdown timer is still 1/100 sec slow.

[cbr12]

When I replaced the rockbox.iriver file with the new binary from the link posted above I get "encoder failure" and "disk is full" messages on the recording screen. Did I not replace the file correctly? Anyone else have this problem?

[Mmmm]

Damn, so the error's still there...how did you test it if you can't get the binaries to work?

It's strange there is this error though, it's as if the actual units are running slightly slower than they should or the value for the number of cpu ticks per second for the I rivers is slightly wrong - but that can't be right or there'd be all sorts of problems all over the place - It must be something in my code but I really can't see what...

For now I'll try a hack to minus 1/100 sec from each second on the coldfire targets...
It would be interesting to know if there is the same error on the archos recorders to see whether it is target specific or not.

[Mmmm]

Try this.... just H1xx to start with...
I've just skimmed 1/100 of a second from each second. On a quick test with a 2 minute timer it seemed less accurate to me but it's hard to tell with as short a time as that.... Hope that fixes it.

rockbox.iriver.H1xx