Rockbox

Can you try with the latest version, too, I fixed a small bug very recently....

I had a serious look at the code changes and can't find any reason. As I do not have an archos, I will have to try to reproduce on my h300...

Why do you also have timesplit set? Looks like a configuration error....

report to be closed in 1 week if OP does not respond

Here is the explanations requested.

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.


Best regards.

Roberto.

yes, but a timesplit setting of 5 seconds is just silly, no? That was the config error I was pointing at.

Trigger is being checked all the time, timesplit only every 5 seconds. So it looks easy to get these weird results you get

It seems that the split time is impossible to set at 5 secs... yet was is set to 5 min: look at the file names list I attached.

Please consider that the config file was downloaded from Archos, I never modified it. If you find the tag:

timesplit: 00:05

in my mind it should have been created from Archos and it should mean 5 min (this fact accordings to the split files created: each one is 5 min from each other).

Have I misunderstood something? Perhaps we have some misunderstanding one each other...

It seems that the split time is impossible to set at 5 secs... yet was is set to 5 min: look at the file names list I attached.

Please consider that the config file was downloaded from Archos, I never modified it. If you find the tag:

timesplit: 00:05

in my mind it should have been created from Archos and it should mean 5 min (this fact accordings to the split files created: each one is 5 min from each other).

Have I misunderstood something? Perhaps we have some misunderstanding one each other...

How was the used build created? From the svn version info in the config file it looks like it was build from modified sources, so I doubt this is an official binary.

Ah, the format is hours:minutes, I thought it was minutes:seconds. Sorry.

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.

If you think it could be useful, I can send also this pack.

Best regards.

Dear sirs, unfortunately the problem has yesterday happened also with the old release 2008-02-02.

Now I want to better investigate: I will try several settings to try to discover some relationship between settings and bug.

I will need several days.... be patient.

Best regards.

Hi to all.

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:

Settings/Manage Settings/Browse .cfg files/<select "Rob.cfg" and press the Play button>: answer from Archos:[Settings Loaded]

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.

For your convenience I attach also this file "config.cfg".

Best regards.

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).

Now all works fine and I propose you to close this task.