iPod first generation install?

[yapper]

Based on results obtained from http://www.chipmunk.nl/klantenservice/applemodel.html, both bidmead and Dindojul have the same model:
Name: iPod (First generation)
Model: M8513 iPod 5GB Generation=1
Family name: M8541
Factory: U2 (Taiwan)

If anyone has a 1G iPod that DOES work with current builds, it would be interesting to see their model information.

[bidmead]

Meanwhile it seems that we need to remove the headline claim that RB runs on 1G devices.  Or at least qualify it.  Accurate info on this is important to RB's street cred.

--
Chris

[Llorean]

Considering Rockbox is unreleased, and this is just a bug, I'm not sure that qualifies it for removal. The Nano had a considerable bug that made it almost unusable for many people for quite some time too, and like that, surely this will be fixed.

[yapper]

Or at least qualify it.

[Chronon]

There was similar noise when some of the nanos were experiencing a problem.  I can see the merit in doing so.  I do not know the nature of any speculative effects of continuing to describe the nano as supported during that period.

[Llorean]

Simply put: All builds are development builds, all "users" are actually "testers." Encouraging people not to use the latest build (or track down the specific build where the problem was introduced) works against the purpose of actually getting the problem fixed.

Basically, the point can be argued both ways. Bugs are business as usual in built-from-SVN software, and hopefully the people actually interested in this build will see fit to investigate / fix the problem soon enough anyway. As always we depend on people with the hardware to work on it, in general.

A player is "supported" if "all the work necessary to make it play music and be generally usable" is done. Buggy builds don't make the build unsupported, they just mean SVN head is buggy. A warning system might be suitable, but people can always just keep their old builds backed up when updating (and should) and if a user doesn't have an old build, they can roll back.

And, *everybody* experiencing this bug should be looking in the tracker anyway (to report it if a bug report doesn't already exist), so when they encounter it, they can add to the information.

I really don't see a specific benefit to qualifying it, but can certainly see why people might have the point of view "users should be told in advance." But we have the tracker for known bugs as it is, anyone interested in existing problems can go there, search for bugs affecting iPod 1st generation (assuming that's added to the list of targets on it) and see every outstanding issue that affects that specific player. Any other form of notification will just as easily be missed by the lay user anyway. I mean look how many people click past the large bold text mentioning forum guidelines will be enforced, or how many didn't even notice the check box next to the field they entered their email address in, offering to hide it. A user is well capable of clicking past anything, but you can't really say the information isn't already available to anyone who actually cares enough to look.

[Chronon]

Of course I understand those points.  And I think those who have already been exposed to Rockbox probably will appreciate this.  The demographic that seems to be under consideration seems to be those users who don't know about Rockbox and think that when they download a current build they will be getting  a working product due to it being "supported" as per the front page.  

If someone wanted to provide a note about this issue an appropriate place might be on the TargetStatus wiki page  -- which is linked from the front page.  Does that sound reasonable?

[Llorean]

I believe that page would be the *perfect* place to note outstanding bugs that make the player impossible to use. I'd rather as few bugs as possible end up on this page, so restricting it to ones that prevent use of the player entirely and consistently (and hopefully by placing it there you accept responsibility for removing it when it's fixed, the page really needs to stay up to date if this is going to be done).

[bidmead]

I didn't mean to start a war here.  :-)  But let me point out a couple of things:

1) The RB front page claims "It runs on a wide range of players....  Apple 1st through 5.5 generation iPod..."  The experience in this thread suggests that this at least needs qualifying in the case of 1Gen.

2) Users as "testers" is OK by me, except that without scroll-wheel function there's frankly nothing to test.

It seems to me a no-brainer that for the good of RB's rep, and in the interest of not demotivating potential RB users, the place to say "It runs, except that you can't use it" is on the front page (or at least on an easy link from the front page clearly labelled "But check this first...").

Technically this bug may be trivial, but from the POV of the 1G end-user it's a show-stopper.

 --
Chris

[Llorean]

What "end-user" exactly? There's no release version for the iPod 1G. And it does run on it, it's just buggy right now. You're downloading a bleeding edge, automatically generated build from source that is being actively developed.

Do you honestly expect someone to read through every bug report, and as ports become more or less usable update the status constantly on the front page? That could nearly be a full time job, on its own. Why not just use the clearly named wiki page?

Edit: Trying to get a general disclaimer added to the current build page to reflect some of this.
Edit2: If the first generation iPod build never worked, it should clearly have never made the "supported" list and should be removed. My point only applies to if this is an introduced bug in a previously working build. Reports suggest that some 1Gs (the one our only developer with one has, for example) work fine, and the target *should* be supported, it's just "supported bug buggy." We provide support for people asking install questions, and we accept bug reports on it and attempt to resolve them.

Basically "supported" means "we expect you to be able to play music on it, and want you to tell us if something interferes with that." Basically, supported does mean *you* should have a reasonable expectation of being able to get music to work. In this case, music doesn't work, but it really is "just a bug" in an in-development software. These things crop up often, and it's somewhat unreasonable to say the front page should contain the constant status of how usable any given target is. For example, recently some (or all, I'm not sure) of the PP5002 builds all had a <50% chance of working, depending on somewhat random factors, but we had no way of knowing consistently which ones users could use without someone testing every build to verify. It's just too large of a task, and something much better suited for the wiki.

Edit, the final: Just to attempt to clarify my point. There are something like 36+ variants of hardware and/or unique install processes. To attempt to keep an up to date usability status documenting any significant bugs would be significantly difficult. This becomes more difficult because sometimes these bugs last a matter of hours, sometimes weeks, and only a few people can modify the front page. These people don't have all the players, and may not even be aware of the problems some players experience. As well, some reported problems that seem very significant only affect specific hardware variants, or even are the result of hardware faults tolerated by the OF but not accounted for by Rockbox yet. So the persons posting this have to have enough reports to verify. Then they have to remove the warnings in a very timely manner when the problems gone, so that further misinformation isn't spread. Wouldn't a better solution be more clarity for the user as to what to expect (ie: It should work, but don't *expect* it to work)? This way people will never assume "there's no warning for my build, it's surely working", nor will they mistakenly see an old warning and think it's still applicable because the person in charge of the page isn't aware it needs removal.

Note: all of this reflects personal opinion, and not project policy, just to clarify.

[bidmead]

What "end-user" exactly?

Projects like RB work, IME, because they attract two kinds of people.  Hackers who like to get stuck in up to the elbows, and end-users who are just happy to appreciate the functionality, and show their appreciation by reporting back on bugs, and perhaps features they'd like to see.  Both types are essential to a healthy project.

--
Chris

[Llorean]

So, we should educate the end users as to what to expect in general. In this unique case, it turns out the port isn't actually complete (due to unknown hardware), and it will likely be removed. But it's somewhat unreasonable to expect the front page to be updated every time a showstopper bug shows up. As I tried to say, these bugs happen often as there's no release version, and often a showstopper will exist, last for a day or two, then be stamped out, without knowledge of it even coming up among those with access to the front page.

[dunno]

The word on the street is "use rockbox, its cool, uses file tree browsing, and you can play games, etc... "joe soap" is not interested in bug hunting he wants plug and play, this is where RB current development philosophy is at odds with "joe soaps" expectations, as there is no release for any post Archos target and no warning of a broken build, not having some means of flagging or notifying users that current SVN is broken for a player is frustrating for "joe soap" and bad for RB credibility.
Because developers assume that the most a build will broken for is a day or two, for the 1G the builds have been broken for a long time due to stated bug, with no developer noticing the bug, where does that leave "joe soap", is he/she supposed to read the logs and mailing list just to determine what the status of SVN is, so that he can load a working build to his/her player ?.  I would suggest you put a big disclaimer somewhere appropriate stating that "unreleased" Rockbox is for folks that are interested in helping developers find bugs, casual users are to expect bugs, and if a current build is "broken/buggy" then wait a day or two before trying a newer current build, (although in the case of the 1G a day or two's grace wouldn't have fixed the bug).

[bidmead]

@dunno: I'd be inclined to discount Joe Soap (by your definition) in this current context.  If he's not interested in bug hunting, he doesn't contribute to the effort, and so is not part of the health of the project as I've described it.  That's not to dismiss him altogether -- if he can pick up something he finds useful, good luck to him.   But I don't think developers should spend too much time worrying about him.

I do think they should spare a lot of thought, though, for the end-user who is prepared to give good feedback.  What matters is the code, and the code needs those end-users -- eyeballs, with mouths attached for feedback.  Anything that misleads, confuses or paralyses those end-users needs attention from the developers every bit as much, if not more, than the code itself.

--
Chris

[linuxstb]

Going back to the problem, it would be useful if 1G owners could do the following:

1) Hold the PLAY button whilst booting (this will cause the Rockbox bootloader to try and load an ipodlinux kernel, which should fail).

2) You should see some info messages on the screen - the third line should be something like:

IPOD version: 0x00010001

(with the last digit being 0, 1 or 2).

3) Post that number on the Flyspray task for this bug (or here, if you're not registered on Flyspray, but Flyspray would be better), along with a statement saying if your scrollwheel works or not:

http://www.rockbox.org/tracker/task/8745

Thanks.