My music collection vs. FAT

[burz]

Has anyone thought of the usecase where a person with song files that accurately reflect the music title in the filename tries to copy those files to the Rockbox-mandated FAT filesystem?

I read the RB-iPod FAQ about transferring, but it doesn't address filename pitfalls.

[Llorean]

Yes, and a common response to that use case is "files can be renamed, we have no interest in supporting multiple filesystems."

[burz]

OK. And I take it there is no suggested or preferred method for renaming on offer for, say, Ubuntu?

I think this brief experiment with RB is coming to an end. I share some of my fiancee's music collection which I am not allowed to rename, so copying files will be necessary. Might as well convert all of the ogg to m4a in an iPod staging area and use the native ipod firmware.

Incidentally, your RBU installer is badly broken on OSX 10.5 but I don't have the time to describe it...

[Llorean]

The native iPod firmware's going to require renaming of the files too. If you're willing to go through that, why not just use Rockbox's database? Then you can see the original, unmodified track names, in effect the same as the apple firmware, without having to transcode and lose audio quality?

As to our installer being broken, I'm glad to see that you're willing to take thousands of hours of other peoples' work and not even put in five minutes to type up an error description and bug report yourself to help improve it.

[burz]

The native iPod firmware's going to require renaming of the files too.

What a coincidence: The iPod has an accompanying app that will do the renaming for me!

And if you were that concerned about losing audio quality, you would have a... um... 'solution' or migration path in place for a user with FOSS formated music files ripped and stored on a FOSS software stack sometime in recent history (post 2001, using non-FAT filesystem on PC). iPod-iTunes took care of their own users on their proprietary software stack.

As to our installer being broken, I'm glad to see that you're willing to take thousands of hours of other peoples' work...

Taking it? I thought I was leaving it.

And that time investment issue is a two way street: I'm sitting here with my one little life and have spent nearly 18hrs just getting RB onto a dead common Gen.5 ipod, first with Ubuntu then with OS X. I dare you to multiply that kind of time wastage by the number of people trying out this version of your product.

Here's the scoop: As soon as the utility finishes with the bootloader install, the device is re-mounted improperly and what was /Volumes/IPOD becomes /Volumes/IPOD (empty mountpoint dir) + /Volumes/IPOD 1 (remounted filesystem) and the .rockbox stuff gets copied into the moribund /Volumes/IPOD directory. This is on an iBook G4 1.2Ghz with the latest Leopard update and very little added outside of some Mozilla and VPN stuff.

Also, the link to the Linux64 download is wrong (points to wrong release, which also isn't even recognized by tar). Links to documentation within the utility try to grab from a web address that doesn't exist. And the utility doesn't say what to do next after the install finishes (eject drive, reset, what??).

I suggest you make a script or module in the RB Utility to perform copying and renaming of files for the user. Another possible path could be to creating a hierarchy of renamed file links to the actual music.

[Llorean]

Are you volunteering to create this script?

You seem to forget - it's a community project. You're pretty much the first person to really complain about the filename issue. Clearly it's not a major concern. And it sounds like you have no interest in fixing it - neither did anyone else who may have encountered it, so it's readily apparent how much those of you with this problem actually care about it.

As to the sound quality issue? If you don't mind, I couldn't care less. I was just suggesting a way you could get around filename concerns without the need to transcode.

As to the various RBUtil issues you've mentioned? We've had thousands of people install on iPod Videos without those issues. So, maybe you could let us know about anything unique in your environment or setup that may have contributed to these problems.

I mean, seriously, 18 hours? Why didn't you come and ask for help after 1? I've installed Rockbox on an iPod Video on Ubuntu myself without issue, and it was as simple as point, click, wait for a build to download, done. Problems like you've described are the aberration, not the norm, and proper bug reports from people who actually care enough to try to contribute and reproduce the problem are the only way they get fixed.

We can't fix issues if we don't have someone experiencing the problem to provide actual feedback.

[burz]

Oh please, even your basic download and doc links are busted. Am I supposed to believe that you've been testing each release on a virgin system? Just because someone got it to install 3 months ago doesn't mean last week's 'tiny' increment of a release will work at all.

And yes, I know about volunteering. I've done it several times before. But you are sitting there with more roadblocks for novice users strewn about than a 10-car pileup. Now, I can surmount all of them with enough time and research, but at that point I think about suggesting the product to my friends and family and realize they are totally excluded by this environment.

And that's also why you may not have heard of this filename complaint before... your project has perhaps become self-selecting toward people with admin skills. If you are skeptical about that, just look at how automatically (even forcefully) you just tried to pull an end-user into the role of volunteer coder. You want a script from me? What am I contributing it to?? Yet another FOSS project with no documented requirements and use cases (poor methodology) and a half-broken front doorstep.

...and that confusion over roles.

I'm writing all this because I care very much about the FOSS concept, but get a bit nonplussed when I try a product and the userbase is implied in a cowardly manner to be skilled technicians and computer enthusiasts (instead of, say, general music enthusiasts).

[saratoga]

Oh please, even your basic download and doc links are busted.

They work fine for me.  Perhaps you have some issues with your hardware?  It would explain why you can't run the installer.

Am I supposed to believe that you've been testing each release on a virgin system? Just because someone got it to install 3 months ago doesn't mean last week's 'tiny' increment of a release will work at all.

Actually, releases don't change, so if it installed 3 months ago, I would expect it to install now, baring some bugs introduced by your linux distro since then.

I've done it several times before. But you are sitting there with more roadblocks for novice users strewn about than a 10-car pileup. Now, I can surmount all of them with enough time and research, but at that point I think about suggesting the product to my friends and family and realize they are totally excluded by this environment.

Nonsense.  We have very good documentation and easy to use install tools.

And that's also why you may not have heard of this filename complaint before... your project has perhaps become self-selecting toward people with admin skills.

Wouldn't that increase the likelihood of people complaining?  Presumably people without admin skills aren't the ones pushing the limits of their file system.

If you are skeptical about that, just look at how automatically (even forcefully) you just tried to pull an end-user into the role of volunteer coder.

Of course!  We're a volunteer project!  The whole idea is to expand the project by getting more end users to volunteer.  Surely you're familiar with how volunteer projects work?

You want a script from me? What am I contributing it to?? Yet another FOSS project with no documented requirements and use cases (poor methodology) and a half-broken front doorstep.

Actually we have very well documented code, a wiki, detailed manuals, and of course these forums. 

...and that confusion over roles.

I think you're a little confused.

I'm writing all this because I care very much about the FOSS concept,

Thats the only reason you're writing it?  really?

but get a bit nonplussed when I try a product and the userbase is implied in a cowardly manner to be skilled technicians and computer enthusiasts (instead of, say, general music enthusiasts).

First of all, I think that implication was yours.

Second of all, I don't think an implication can really be cowardly. 

But more importantly, you're complaining that software for hacking hardware is aimed at enthusiasts?   Have you considered what kind of people become enthusiastic about hacking hardware?   Many are enthusiasts!

[Llorean]

Could you tell me which documentation links are broken, exactly?

If I click "Manual" on the left side of this page, then click on any of the PDFs, they seem to work for me.

If I download RBUtil right now, it autodetects the three different players of mine I tried it with, and installs on them.

Maybe you could try being specific rather than saying "everything is broken" and expecting someone to be interested in your complete lack of details.

Maybe your ISP is having DNS issues, because all the links work for me. Please, if they're all so broken, post some of the broken links for the rest of us to see?

The install process, for the vast majority of our users, is "download rbutil, let it autodetect your player, click full install." You may not believe yours is a unique case, but believe me, it is.

If you don't want to help, fine. It's pretty clear you posted here just to whine, since so far you haven't given a single detail that's actually useful for tracking down a bug, you've just made over the top claims about basically nothing working, claimed you spent 18 hours on something that tens of thousands of users have accomplished before, and basically made a nuisance of yourself.

If you really care about FOSS, post some bug reports and posts in sections of the forums they actually belong in describing what *actually* happened, without the generalizations, so people can track down specific problems and improve things.

But if you want to just complain some more, without providing any useful information, save me the effort from having to clean up after you and just don't bother posting in the first place.

We welcome useful feedback, even if negative, but just saying "it doesn't work for me" and not providing any sort of details doesn't help anyone, and calling us names doesn't help your case in the slightest. It's pretty clear for everyone to see you've lost your temper over an issue that could've been handled reasonably.

[bluebrother]

I'm writing all this because I care very much about the FOSS concept, but get a bit nonplussed when I try a product

Rockbox is not a product. Period. Neither is Rockbox Utility.
Let me repeat it again: Rockbox is not a product.

The native iPod firmware's going to require renaming of the files too.

What a coincidence: The iPod has an accompanying app that will do the renaming for me!

Fine, but what's the point? Use another application that does the renaming. Or even use Itunes.
As for Linux, amarok for example has a "FAT-safe filenames" option when renaming files. You really think there aren't applications around that do such a renaming already?

I think this brief experiment with RB is coming to an end. I share some of my fiancee's music collection which I am not allowed to rename, so copying files will be necessary.

Putting files on the Ipod does require copying anyway, so what's the point? Or do you seriously want to move the files, loosing any backup on the PC?

I suggest you make a script or module in the RB Utility to perform copying and renaming of files for the user.

I suggest you making yourself familiar with the goals of that tool. Then you'll realize why we do not add a "copying and renaming" "module" in Rockbox Utility and why we don't want it. I also suggest you looking around on the web if there are any applications around that already do what you want. Maybe already existing applications are a reason to not duplicate the work in Rockbox Utility but concentrate on its main purpose: easy and end user proof installation?
If you care about OSS as you said you already know where to look so I don't need to give you pointer.

[burz]

I won't dignify the stereotypical and almost comic kneejerk evasions in those responses (yeah, must be my hardware!!), so I'll stick with nuts and bolts:

In RB Util click on the Manual tab, then select PDF Version and click Download. It will respond with "downloading file .pdf; Download error: received HTTP error 404"

I.e. a broken link.

That same goes for the HTML version.

The app doesn't even let you begin these Manual retrieval steps until you have a correctly working ipod connected and mounted on the computer, which seems odd since the Manual might be needed to get the ipod functioning after a failed attempt.

At http://www.rockbox.org/twiki/bin/view/Main/RockboxUtility#Download
the fourth link points to the wrong version which is in a different archive format than the others.

On renaming, you shouldn't leave the user hanging on this issue without bringing it up in the docs and making some effective suggestions. I would have looked into Amarok as a solution but I got duped into thinking KDE 4.2 was OK and the Amarok that came with it erased my 1.x database (with song comment fields) and won't connect to an iPod under Ubuntu (since at least December).

Finally, you have a real issue with relying on Windows to fix inconsistencies in the filesystem. Fsck.vfat or similar should be employed to do this work automatically for the user.

[Llorean]

We're looking into the manual link issue. The normal links to it still work, though, just apparently the "download" link is broken, and not for everyone. It may be an issue with the download servers, or something else entirely. Nobody had reported this to us before, and it worked at some point in the past.

That isn't the "wrong" version of RBUtil. 1.2 is the latest 64-bit version we have. Unfortunately, this is another place where we depend on volunteers - someone has to compile it and test it. We haven't found someone to do that for RBUtil on 64-bit Linux since 1.2, so we don't have a newer version.

Getting music *onto* your player has nothing to do with Rockbox, so the renaming issue isn't exactly something we deal with. We don't write music management software. We don't write filesystems. These are all basic issues for the host computer to deal with, and the software installed on it.

As to "relying on windows to fix inconsistencies in the filesystem" - what exactly do you mean by this? We don't *create* the inconsistencies. It's not our fault if, in our experience, Windows' filesystem check finds more problems and fixes them better than fsck.vfat. If you have problems with it not finding filesystem issues you're experiencing, report bugs to the fsck.vfat maintainers.

Seriously, maybe you should start by taking a step backward, calming down, and asking some questions. It seems many of your complaints aren't about Rockbox itself, but about various tools on your computer not doing their own job right.

[cool_walking_]

Finally, you have a real issue with relying on Windows to fix inconsistencies in the filesystem. Fsck.vfat or similar should be employed to do this work automatically for the user.

There comes a point where in trying to be too user-friendly, you become destructive.  I think automatically invoking a filesystem checker crosses this line.  I can't find it now, but I once read something about a compiler that tried to guess what you meant when it found an error in the source code, so you ended up with a compiled program that did god-knows-what.

[saratoga]

I won't dignify the stereotypical and almost comic kneejerk evasions in those responses (yeah, must be my hardware!!),

Woah slow down here.  You're missing a few things.  You said the download link was broken, when you meant to say "download button in rbutil".  Since the download link worked fine, the most obvious conclusion is that something was wrong with your connection.

You're right that this is a kneejerk response, but it is so because its the logical conclusion.  Of course it wasn't the answer you wanted, but since you didn't ask the right question, thats not surprising. 

[bluebrother]

In RB Util click on the Manual tab, then select PDF Version and click Download. It will respond with "downloading file .pdf; Download error: received HTTP error 404"

I.e. a broken link.

Wrong conclusion.
The issue is a setting value read incorrectly, thus the download link getting constructed improperly -- in some cases. Seems your player is one of those that trigger the issue. You might be interested to head that this issue has been fixed a while ago already, but as it wasn't reported before not noticed as such.

The app doesn't even let you begin these Manual retrieval steps until you have a correctly working ipod connected and mounted on the computer, which seems odd since the Manual might be needed to get the ipod functioning after a failed attempt.

What's so wrong about this? Until you have chosen the correct player (which is needed to identify the manual you need) and provided a mountpoint (which is used for placing the downloaded file) it simply won't work. How to get read the manual if you don't want to / can't / fail to select the correct player and mountpoint? That's rather easy:
- start Rockbox Utility.
- cancel the configuration dialog.
- go to the "Manual" tab. You'll now see the tab read "Select a device for a link to the correct manual.", followed by a "Manual Overview" link. That link directs you to the manual overview page (surprising as the title says so, isn't it?). You can select the correct manual from that website, view it, download it, and so on.

At http://www.rockbox.org/twiki/bin/view/Main/RockboxUtility#Download
the fourth link points to the wrong version which is in a different archive format than the others.

As Llorean already said: the link is correct. You are wrong. Now is it a kneejerk response to tell that a link is wrong if the binary it points to isn't the latest version available? I'd say no. Also, what's the problem that it uses a different archive format than the others? The guy who made it simply used a different format. Users using a GUI extractor shouldn't have any problems as those tools should handle this difference without further notice. Command line users should be familiar enough with common archive formats to handle that themselves. At least there's nothing wrong with using a different format -- it's still a common format.

On renaming, you shouldn't leave the user hanging on this issue without bringing it up in the docs and making some effective suggestions.

Maybe it's worth an entry in the FAQ (though this isn't a frequently asked question) or the documentation. Still users who actually do have those sort of problems are usually computer-savy enough to know what to do about it. And if not, they still can ask in our support channels, like here in the forums. It isn't a Rockbox issue at all.

Finally, you have a real issue with relying on Windows to fix inconsistencies in the filesystem. Fsck.vfat or similar should be employed to do this work automatically for the user.

Why? It's a bad bad bad idea for several reasons:
- if we include fsck.vfat it might get outdated quickly. Having an outdated tool might cause more trouble than it helps.
- it requires additional testing. Testing Rockbox Utility is already problematic enough as several installation methods (especially the bootloaders) require the real hardware to work properly. You assume every developer working on it has all the supported players around?
- it won't work on Windows at all
- from my personal experience: chkdsk /f is more reliable than fsck.vfat. I know what I'm talking about, I wrote a FAT driver a few years ago and during development had to check and fix my test drive frequently. chkdsk did work better. And I'm saying that as a linux developer.
- trying to get too smart is a bad idea.
- filesystem errors aren't that frequent that one needs to fix them on a regular basis.