Confirm Long File Name Bug in Player Object

[Sivakatirswami]

On Jun 23, 2005, at 12:38 PM, Scott Rossi wrote:

> If you want to deliver a media player now, the only way around this  
> is to
> have your app duplicate the user's media somewhere on their drive,  
> rename
> it, and then make sure to delete the duplicate when you're done.   
> For a few
> files, one by one, this might be OK, but I question whether this is  
> a valid
> workaround for potentially dozens of multi-megabyte files.

Exactly my precise predicament "potentially dozens of multi-megabyte  
files."

How about in the range of 2000! (I'm not kidding, we have a huge  
audio library archival project in process...)

My "Audio Transcriber.rev" is deployed now to about 15 people on  
remote locations around the world, this app downloads files from our  
server on the LAN in Hawaii, transcripts are done locally, these are  
sent back here with a POST to a CGI on our server here and later,  
when ready for public, transfered to our distribution web server in  
Connecticutt. Meanwhile I have inhouse apps in the works that will  
catalog and make all these sound files and their  
transcriptsaccessible. I set a new standard here for file names where

[2-ltr abbreviation for the author-speaker]_[international-date the  
talk is given]_[some unique subjectwords].mp3

e.g. we record Scott Rossi describing his work flow for software  
development, the file is named

sr_2005-06-05_RevConWorkFlowPresentation.mp3

and the XML transcript becomes

sr_2005-07-23_RevConWorkFlowPresentation.xml

because I got fed up with an earlier model we developed for reasons  
long ago for reasons I won't get into here: based on paths

past/2005/July/July_23_05/sounclip.mp3 where a data base was an  
absolute requirement to make any sense out of these files. The new  
model, which may also have a database for query work, is more  
accessible... we need our editors to be able to simply go to the  
server on the LAN and make some sense out of what they see from the  
Finder...

My whole functional spec was envisioned with the expectation that the  
long file name issue, was no longer an issue. A mistake on my part...  
a little hacking in the early stages can be really critical to the  
development path. I think you can see the kind of nightmare I'm  
headed for... Right, sure it's not a blocker, we can still "develop"  
but if x Number of hours are used to implement a workaround, instead  
of making progress, in my book, as a production manager for  
publications that must get out the door on real time schedules,  
that's a blocker...

Sivakatirswami