Wednesday, May 3. 2006More on the VFAT rewrite
The VFAT rewrite continues apace (it may get renamed for 1.4 final). Many functions have now been implemented, and far from scaring me, I now feel quite comfortable with the code I've written. Just goes to show how taking a fresh perspective can really make a difference. It should be working much better than the previous incarnation of the plugin once it's done, and hopefully folks using 1.4 final will be happy with it.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Good luck on the rename! I've been racking my brains trying to think if something generic that's not too technical sounding.
Generic USB Media Device is about the best I can do 
Unfortunately, this plugin is not solely limited to USB drives, as my testing with it is being done on a VFAT partition on my hard drive. Even worse, it should work with pretty much any filesystem.
"Generic Device" may even be the best name, in the end.
It's been renamed to "Generic Audio Player." Mass Storage Device would I think send the wrong impression that the plugin is to be used with storage devices and not audio devices, even if they export a UMS interface.
An option (with checkbox in the dialog) to rename files with illegal characters ("&","?", weird utf-characters...) would be very nice.
At the moment out of lazyness i just don't transfer files like "Up, Bustle & Out - ¡Aqui no ma!.mp3". And thanks for your work - amaRocks! (even more with the vfat-plugin, which let's me feed my crappy mp3-player much more conveniently)
Jolin, thanks for your kind words.
I'm not sure what you mean about renaming files with illegal characters, as this should (and as far as I can tell, does) happen automatically when you transfer files to the VFAT device in amaroK. Have you actually tried doing it?
Mmmh, it definitly didn't for me. But I didn't tried looking at logs or searching for the source of the problem. Now - as i know it should do better - i will, but i'm not at home in the moment.
I have the files on an utf-gentoo-reiserfs computer, and use a nexia CF-card-player. I connect via card-reader and i always (since 2 years) had to rename the files manually. I will definitly investigate further as soon i'm home, as this really is a bit annoying.
That's curious, as I've had people send me tracks that contain non-VFAT-compatible characters, and they correctly get converted upon transferring. Are you sure your filesystem on your CF card is vfat? If the filesystem is not actually vfat, some renaming checks are skipped (since the plugin is a generic one that can work with pretty much any mounted filesystem...in fact, it's been renamed to "Generic Audio Player").
Yes, it's FAT32.
Yesterday i re-partitioned & formated the card, because i suspected the "format" option of the mp3-player could be the culprit. So it's definitly vfat - and still the same problems. Other things i tried so far: messing around with the different mount-options (utf8, io-charset, codepages...), locales and looked in the kernel for helpfull options. Googling i can't find a lot. Most people have pretty basic problems and can't mount. The one's with character-problems just end telling they solved it with renaming the files. Seems that various projects do filtering of the files themselves (mtools, vdr). Mount options seem the way to go, but whatever i use, it's always the same. Looking further into it. p.s.: the "&" is no problem, in fact it even did a "¡" (which is a rotated "!" and not an "i" - difference is not easy to see i just realise), bad are ? and : (probably also < > / \ | " and * as http://osdev.berlios.de/osd-fs.html#overview says)
Interesting you're having those issues. I do know for sure that utf8 is not supported on VFAT devices. Do you have any other vfat devices around that you can test with and see if it's just a problem with that CF card?
Just tried an usb-stick (FAT32 too). Same problem.
Simple test: cp "test?.txt" /media/sdb1/ cp: cannot create regular file `/media/sdb1/test?.txt': Invalid argument Still i don't have any clue which component should take care of the translation. I'm not really experienced with charset/local/utf/vfat-thing (but i'm getting slowly). So i can't really comment on the vfat-utf-option. But there is one. An excerpt from the manpage of mount: Mount options for vfat utf8 UTF8 is the filesystem safe 8-bit encoding of Unicode that is used by the console. It can be be enabled for the filesystem with this option. If `uni_xlate' gets set, UTF8 gets disabled.
Now i did:
touch vfatfile dd if=/dev/zero of=vfatfile bs=1k count=1200 mkfs.vfat vfatfile mount -o loop -t vfat vfatfile /mnt/test/ With this loopfile mounted, i'm experiencing the same problem, so it shouldn't be faulty hardware.
Windows uses UTF8 for vfat filesystems. So it should eventually work with amarok, too, but I think it's more an issue of the linux distribution to properly handle vfat filesystems (i.e. use proper mount options).
Amarok however should not try to get rid of "weird utf characters" but instead make sure to convert them to the character encoding valid for the target filesystem. By the way, the "industry standard" name for players using USB and plain file copy to transfer the music is "Mass Storage Class", not VFAT. So if you want people to understand what your plugin is doing you should consider renaming it to something like "Mass Storage Class player support"...
Although Widows uses utf8 for vfat filesystems it doesn't mean that random music players will handle them well. Generally this isn't a problem anyways as tags are unchanged, and you're copying from your computer to the portable device, and not back the other way afterwards.
In Linux filenames are treated as a null-terminated string of bytes, with a specified path separator character ('/'). So what encoding is valid is...well, anything, since it's not interpreting filenames as characters. This is not true across all operating systems, however, or even across implementations of drivers. So this is not portable behavior just because Windows and Linux do it. Maybe an option will be added at some point to not automatically translate. Also, the industry standard name for that class of devices is "Mass Storage Class" maybe, but the much more common terms people would recognize would be "Mass Storage Device" or "USB Mass Storage" (UMS). Regardless, we want to remind users that the focus is on audio players, not random hard drives or flash drives, so as has been mentioned in the comments to this post already, and in another post, it's been renamed to "Generic Audio Player." It makes more sense to name it that than "Mass Storage Class."
You mean, a "vfat filesystem" plugin? I'm curious, why can't amarok just use kernel's vfat? (HAL & friends can mount and setup permissions of devices and send events to make this work seamlessly in linux)
I think you misunderstand the reason for the plugin -- I didn't write a vfat filesystem driver. What the plugin does (in fact, what all of the device plugins do, which currently are vfat/generic, ifp, and ipod) is provide an implementation of various functions for the respective devices. For ifp for instance, when amaroK wants to copy a track you've queued up to the device, it must use the functions provided by libifp to interface with the device to copy the track. On an iPod, it uses the interface provided by libgpod so that the iPod's database is kept updated. And on VFAT devices, it just does a plain old KIO copy. The plugins are not implementations of filesystem drivers, they just implement amaroK's API for the different types of devices.
|
Amarok LinksCalendarQuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
