Closed by Peter D'Hoye (petur)
Sunday, 14 September 2008, 16:26 GMT Reason for closing: Out of DateAdditional comments about closing: no longer reproducable - might have been
a local config issue,.... who knows...

Why I use the Triggered recording?
I did not find a easier way to record the radio unattended: I have a radio connected to a power supply digital weekly timer, so, when the radio is powered the Archos starts to record, and it stops when the radio is powered off.

-Why I use the timesplit?
I daily record the radio (program length about 80 min).
Then I put this record into a CD-RW for listening it into my car.
As it is hard to navigate into a CD with a unique track 80 min length, I prefer to set timesplit into Archos. This function is also useful as it stamps the start date&TIME for every file. So the player of my car shows me the start TIME of the record and I can check the track I am listening on the LCD of the player.

I recorder as described for a long time.
All worked well with, for instance, 200800202 release of Archos Rockbox.
With new releases there is some bug that randomly performs spurious splits making some recording files with only less than 1 sec length.
This is a problem, as the CD recording standard voids CD burnings of tracks with lengths less than 4 secs.

Yesterday I loaded again the old release 200800202 and all works well.

That release had a bug (solved for the new releases): after the stop of the recording, the peak meter is no longer re-enabled: to get it re-enabled I must re-boot Archos.

For my purposes this is not a big problem, but I would prefer to find a way to solv it, and so I started to report it into Flyspray.

P.S. do you know the reason why in new releases a lower lomit on Start&Stop Trigger thresholds has been inserted? -40dB seems too aloud for me.

Dominik, the config file was created with the release that on my equipment works fine: the 2008-02-02 r16198M. I still have the download file on my PC, its name is "rockbox-recorder-20080202.zip" (perhaps I inserted the date during the save).

If you want I can sent you the file.

But the problem arises not with this old release, but with, for instance, "rockbox 20080816 18291.zip". I used the old Radio3Mondo.cfg file to record with this firmware release, and the result are some spurious 1 sec spilts.

I made some tests and I found a interesting relationship between the event "Unwanted random 1 sec split" and the config settings.

Shall start from the first event.

In one of my last Comments I reported the bug also with the r16198M-080202.
In the past I used this release many many times to record my preferite programs from radio, without any problem. Then I loaded the newer r16500M-080303, again without any problems. By this release I also saved the General settings into the disc with filename "Rob.cfg".

Well, several days ago I tried the new r18291-080815 release and, as reported, I experimented several "Unwanted random 1 sec split".

So I reloaded the old r16198M-080202 release and made some test recordings; at first the bug was not present, but then I experimented the bug also with this release.

So I thought: the cause of the bug could be something else apart the software. Some config settings could cause the bug.

Now, I made some experiments:

I made 5 recordings lasting each one about 1h and a half with the r18291-080815 release.
Just before the recording I loaded the Rob.cfg general setting config file by the menu:

Well, EVERY recording worked FINE!, without any "Unwanted random 1 sec split".

Then I decided to immediately report this result, and to attach the Rob.cfg file for your inspection.

I will continue the tests, and I will report the results. The next tests will be made with a config file saved by the new r18291-080815 release: actually this release saves a very different pattern .cfg file and every time I used this .cfg file I experimented the bug, no matter the firmware release used.

Dear sirs, I tried to replicate the problem several times but with no evidence.

Now the problem does not arise at all, no matter the release I use.
This behavior started after I disconnected and re-connected the batteries.
I made it bacause I suspected that some parameter value were not read from the cfg file, but kept the last value (I do not exactly know how the firmware manages the parameter values, I do not know when it reads the parameters from the cfg file).