VFAT: too skinny for me.

 A note I should add.

VFAT can't handle files over 4GB: format USB datasticks with ext2fs.

I built this video player as shown, on a Raspberry Pi running Debian Linux.  The OS and the software (a simple shell script) are stored on the built-in flash RAM on the Pi, but the intention was always that the videos would be stored on a USB data stick (one or more) which could be easily swapped in and out.

So I set about ripping all the desired movies to digital form, which I did "in parallel" as I was also building the hardware and writing the software (since ripping the movies happens only at 1x regular speed, coming from a VHS player, it took many hours across several nights, to rip the 20-or-30 favourite movies which we wanted to have available on this system).

Then, I tried to copy the resulting digital video files (.mpg format) over to my data stick.  Whoops!  Files too big, can't store.  WTF???  The problem was happening when the file was larger than 4GB (which a lot of the videos were -- and are, generally).  At least, not 2GB!  I.e., unsigned 32-bit integer seems to be the problem.  The USB stick was formatted with Microsoft's VFAT filesystem, the usual default.  Hmmm, I thought we were past this 32-bit nonsense, but guess not.  Don't a lot of people who buy USB sticks with many tens or hundreds of GB storage, want to store videos of reasonable resolution and play length?  OK... so I went over to Linux and tried reformatting the drive, using mkfs, in VFAT format but setting all the "enable larger filesize" type options I could find in the manpage.  Isn't VFAT actually more or less synonymous with NTFS these days?  There's no "vfat64"...

Well anyway, even with trying my best, I couldn't seem to create a VFAT filesystem which could handle files over 4GB.  So, I took the "easy" way out: I formatted as ext2fs.  I.e., native Linux filesystem format.  Which of course, had no problem with the filesizes.  And of course, the Pi has no trouble mounting this.  The problem, of course, is that I had wanted to be able to load files onto these data sticks from any OS, be it Windows or MacOS as well as Linux, and the easy way to ensure that is to use VFAT.  So, I've had to give up this desirable design objective; the USB sticks require a Linux host system to load the data from.  Or, of course, the Raspberry Pi can be connected to the LAN, and then files can be transferred without taking the USB stick out of the machine (using scp).

But, thought I'd better warn anyone out there trying to replicate my results; not sure I mentioned before that the USB sticks should be formatted ext2fs (or other 64-bit-respecting format of your choice).  If anyone knows of a way I could have used VFAT here, i.e., which options to mkfs did I miss, please let me know and I'll update this post.




Comments

Post a Comment

Popular posts from this blog

obtaining the content

Just FYI, in case you, like me, are trying to build a digital system to play videos originally ripped from VHS tapes.  Many of these tapes are recorded with "copy protection", known by the brand name "Macrovision".  This system involves putting out-of-spec signal levels into the vertical blanking interval of the video signal.  Somehow, old-school VHS players -- even if they don't "know about" the copy protection -- are still able to play these tapes, but if you try to copy the signal through the patch cables to another recorder (such as an AV-to-USB converter cable), the irregular sync signals either cause the video to be unusably erratic, or in many cases, the capture software recognizes the Macrovision and refuses to record it (even though it displays it on the screen!). The solution is to pass the video signal through something which breaks down the signal and re-constitutes it, with freshly-created sync pulses.  I'd have thought this would be t...
Read more

photos

Image
  booting Debian... I built a plywood "chassis" (bottom and back panels), with finished pine front panel.  Black steel top cover is scavenged from some old piece of audio or video equipment. Here you can see the poplar reinforcement beam I had to fit into the metal cover, so that it would carry the weight of a big monitor on top without bending excessively. Each button presses one of the microswitches, which ground the GPIO lines which are otherwise pulled high to 3.3v, using the 2.2k resistors visible in the foreground. The boards holding the red & blue LEDs can be seen at the top, spaced in between the three button assemblies.  The LEDs shine upon the paper liners, which are visible from the front through the wide gaps around each button shape.  This forms a gradient of diffuse purple light, coming through the cracks. You can see the folded sheet-aluminum heatsink which is superglued to the top of Pi CPU chip.  Not exactly "up to code", but gets rid of the...
Read more