Faulty playback on Ipod Nano 4Gb 1st Gen

[webjockey]

Well, I solved the data abort problem witha system restore and fresh reinstall (I keep a Rockbox_Dump on my computer from when it was worknig fine, so that its easier to reinstall, but that didn't fix it, so  I unextracted everything anew and put it back on my computer after a system restore of the iPod)
I don't know, but, has anyone with the problem tried restoring their iPod, and then putting the music on, and then putting Launcher 2 (If you use it) and putting rockbox on the very last? Thats how I did it the first time, with my Rockbox_Dump, it worked fine, its just that now, when the only difference seems to be the order (and the lack of a Linux Partition) it has started to glitch.

So I am back to square 1 ...

[Chronon]

Well, I reverted to an earlier build to see if this player behaves similarly to tvg's.  I am currently running r13989 without any trouble.  All files play back smoothly with no hiccups.

[webjockey]

See, thats interesting, because, I left my iPod for about 6hours, completely shut off, started it up again, and everything is running smoothly... No hiccups what-so-ever in any song.....

[tvg]

By this time it's impossible to get lastworking version - ~~13990 - it is out of site.

May be it can be useful to roll-back the improvement, which led to such a unstable behavior? For a while, until the problem will be solved.

[Llorean]

Rockbox is not released. It would be best for people to continue working on it, instead of continually asking for versions that "work" so they can pretend like the problem doesn't exist. This problem WILL NOT get fixed if nobody who has the problem figures out exactly what the problem is, and if all of you keep wanting to go back to 13990, and simply pretend like the problem doesn't exist, it will be much, much, much longer until it is fixed, if ever.

[Chronon]

Users who experience problems represent a feedback mechanism for the developers.  If they don't get feedback then it can take much longer to identify what changes to make.  

In that spirit, I'll keep testing new builds.  However, this nano is slated to become a gift for someone in a couple of weeks.  So, I only have a small amount of time left for testing.

[tvg]

But noone now is notified that the last working build for his player could be 13990. And even if so, nobody can download it, as I assume.

And the very few can really improve the code, others can only use.

[mikelx215]

I agree. For the end user, the current builds could mislead someone into thinking that Rockbox is a buggy, unusable and unusable application. And if they were using a 1st gen nano that wasn't playing nice with the new Rockbox, they'd be right.

For the end user, who is code illiterate, several things need to happen. (This would be even more important if there will not be a fix in the near future.)

1: Since this is a serious bug (makes music unplayable, among other things) that appears to affect a sizable amount of your audience (including myself), there should be a notification somewhere on the main page or the build download page. When I updated Rockbox I had no way of knowing why it was constantly jumping to the next song.

2: As a temporary fix, a latest 'stable' build should be in the download section. For dumb end users who can't code, like myself, it'd be great if we could still use Rockbox while the current build is being fixed by the amazing and talented people who know what they're doing.

3: If you are unable to put an older binary (or the test 1 which works great) in the downloads, could I suggest a way to underclock Rockbox in the Settings menu? If possible, users with the bug could still use Rockbox, while providing feedback on the current build and still contribute to fixing the higher clockspeed problems.

Rockbox is a fine firmware replacement. I like it better than the iPod OS, if I didn't I wouldn't be using it.

[GodEater]

But again you're assuming that Rockbox is a released product, which it's not.

Anyone using it is a tester, whether they like it or not.

[mikelx215]

How much testing can an end user do if the daily builds don't work for them? Not a lot.

When will the bug be fixed? From the looks of things it won't be anytime soon. How many people won't become contributing members of the Rockbox community, thinking Rockbox is a buggy unusable firmware replacement?

This is a pretty serious bug, as it breaks on of the main functions of Rockbox. Just a small notification could inform so many people.

If needed, someone could host a mirror of 'test 1'.

[GodEater]

They can test each current build as it's released, and report on whether the problem has been fixed or not. That's how.

[Chronon]

Well, that doesn't seem entirely realistic, GodEater.  Probably they'll update periodically and report if the problem gets fixed.  This thread and the flyspray task would quickly get bloated if those of us with this problem reported this for each firmware revision.

I would advise keeping a backup of a firmware revision in which playback works.  Then update periodically to test.  If a new build works report it here and in this flyspray task.  In the event that it doesn't work you may revert back to the backup that does to enjoy your music.

We want to continue to test new builds so that we can provide feedback if any changes in the source fix what we are experiencing.  But it's totally understandable that people don't want to languish with an unusable DAP until the problem is resolved.

-------------
edit:
As a note, playback is still broken in recent revisions (e.g. r14627).  I'm reverting to a working build to listen to music.  I'll try again with a build tomorrow

[Llorean]

In response to "How much testing can users do if the daily builds don't work for them?"
1) Users aren't supposed to use the daily anyway, they're supposed to use the current.
2) If the current doesn't work, not a lot. If they test a 600 revision old version, though, the testing doesn't mean anything, so it's useless to use for them to use that version either.

I understand that users don't want to have an unusable DAP until it's fixed, but the bug won't fix itself. If users choose to ignore it because "I can't do anything" it may very be a long time. I don't see very many people asking "What can I do to help?" or coming into the IRC channel, or saying "I've been learning about X in an attempt to help" but instead saying "I don't care if the bug gets fixed any time soon, I just want to play music."

[mikelx215]

If I could code, I'd help with the coding. I haven't learned the skills required to help in that capacity. Maybe I'll contribute to the Themes.

The 'I don't care if the bug gets fixed any time soon, I just want to play music.' is a legitimate response. People are going to spend time setting up Rockbox, only to find that it's broken. That's going to really suck for the people who are new to Rockbox and haven't yet joined the forums.

As someone who can't directly contribute to the code, I feel that it would be nice if a stable build were to be provided when the code gets buggy. It took way too much digging to find the last working revision. It would be helpful if access to older stable binaries were available.

PS: I'm not complaining, I'm suggesting something that I feel should be done in the meantime.

In response to "How much testing can users do if the daily builds don't work for them?"
1) Users aren't supposed to use the daily anyway, they're supposed to use the current.

You knew what I meant.  

[Llorean]

Again though, how does having users use a working version help move toward fixing the bug at all?

None of their testing means anything (it's days, weeks, months out of date) and it encourages them to NOT work on the problem.

I've said this several times: This problem does NOT happen on any developer Nanos, so it is highly likely that someone experiencing the problem will have to do a decent amount of work on this. This means that you should be saying "How can I learn to help" rather than "Please give me a build that works."