Support and General Use > Audio Playback, Database and Playlists

My music collection vs. FAT

<< < (3/4) > >>

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_:

--- Quote from: burz on June 10, 2009, 05:21:03 PM ---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.
--- End quote ---
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:

--- Quote from: burz on June 10, 2009, 05:21:03 PM ---I won't dignify the stereotypical and almost comic kneejerk evasions in those responses (yeah, must be my hardware!!),

--- End quote ---

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:

--- Quote from: burz on June 10, 2009, 05:21:03 PM ---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.
--- End quote ---
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.


--- Quote ---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.
--- End quote ---
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.


--- Quote ---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.
--- End quote ---
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.


--- Quote ---On renaming, you shouldn't leave the user hanging on this issue without bringing it up in the docs and making some effective suggestions.
--- End quote ---
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.


--- Quote ---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.
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page