Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Recording
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Medium
  • Priority Very Low
  • Reported Version
  • Due in Version Version 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by jansa - 2006-05-22
Last edited by Peter D'Hoye - 2007-08-05

FS#5412 - Recording overwrites iriver fw settings

Equipment: H320; iriver fw 1.29 korean; rockbox Version 060521
Have recorded via line-in a 2:27:38 hours file (WAV). Played correctly under rockbox (immediately) after recording. Next reboot of player under iriver fw just played right channel. A check revealed overwritten settings in the iriver “sound”-menu: balance was set to right, screen display (balance digital indicator, beep indicators, …) were scrambled. Everything could be “repaired” by manual re-entering correct values so that afterwards file played correctly also under iriver fw and everything (at least) looks ok again, though some discomfort has been left. (What else (more serious things) might have gone wrong?). (not tested a 2nd time)

Closed by  Peter D'Hoye
2007-08-05 00:37
Reason for closing:  Later
Additional comments about closing:  

haven't seen this in a loooong time, If it ever happens again, reopen…..

Peter D'Hoye commented on 2006-05-22 13:47

This is a duplicate of http://www.rockbox.org/tracker/task/5253

If recording causes this we're on track to figure out the cause…

Peter D'Hoye commented on 2006-05-22 20:21

Hmmm… just recorded a bit but this didn't corrupt them…

jansa commented on 2006-05-23 07:33

Made 3 further recordings of various length: 30 min, 45 min, 70 min. Error could be reproduced, but I don't see any dependance on the length. 30 min and 70 min was ok. 45 min produced the same corruption in sound menu. By the way, I want to note, that I never had this phenomenon before although I have been using Rockbox and Iriver fw alternatively since Nov 05, but I have never used the recording function before. That's the reason why I thought recording caused the problems. What I further realized is the different YEAR setting in iriver and rockbox (Rockbox is 1 year behind!), but I guess this is a different matter and has probably nothing to do with the reported corruption. Shall check it separately.

Dominik Riebeling commented on 2006-05-23 07:37

The different year setting is intended. Maybe someone should this point out somewhere in the wiki (and maybe the manual).

Peter D'Hoye commented on 2006-05-24 20:14

Well intended in a way. The problem is that the iriver implementation for the rtc-chip is wrong. The year off is the best we can do ;)

Peter D'Hoye commented on 2006-05-24 21:04

Tried a 45 minutes recording - no corruption.

this will be a hard one to solve :(

Peter D'Hoye commented on 2006-05-27 18:37

comment from duplicate closed task:

See also http://www.misticriver.net/showthread.php?t=40829

When booting into the h300 iriver firmware, its settings can get messed up. Reported so far:
- illegal/wrong contrast setting
- illegal/wrong brightness setting
- changed/reset language setting

In the case of contrast, it was set to a value the iriver firmware couldn't handle and caused it to behave wrong until a normal value was reached.

I was under the impression that iriver firmware stored its settings in the eeprom. Either we are messing with that or they store them elsewhere

jansa commented on 2006-06-08 10:02

I have updated to version 060531 and did not experience any of the previously described errors after recording (of 2h 45m and 1h 55m sessions). First I thought the erroneous code (or whatever) had been corrected just by chance; later I realized that the iriver radio could not be entered any more, even not after reboot (pressing reset button) - I had to start a firmware (pseudo)upgrade (reloading the already previously used firmware version). After the second recording radio worked correctly, but I had additional station presets at nonsense frequencies: 247.65, 294.65, 556.48, and 113.6 Mhz. I believe the error had nothing to do with the length of the recording, just the probability of erroneous behaviour might be higher if recording time is longer. In the meantime I was even not sure whether the above described erroneous behaviour had been caused by the recording function, as I did not detected the strange behaviour immediately after the recording session but hours later (in both cases, at the longer and the shorter session). What I did in between was checking the recording quality (i.e. forwinding, rewinding, playing, nothing else). Therefore, I checked separately extensive winding in all possible directions, but without any negative consequence. The only problem I found was a confused time counter after long forwind on MP3 files (e.g. forwind to 2h 43m of the 2h 45m file, i.e. 2 min before the end of the track: at the end of the track the counter was in advance by 21 sec, i.e. counter counted beyond the actual and correctly displayed track length). But I am sure that this is a different story and has nothing to do with the recording problems.

Dominik Riebeling commented on 2007-07-08 12:24

can anyone still confirm this problem?

Michael Sevakis commented on 2007-07-09 05:37

Maybe related in some way to: http://www.rockbox.org/tracker/5852

??

Peter D'Hoye commented on 2007-07-09 19:41

nah… the settings are stored in EEPROM accessible over i2c only…

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing