On 2009-05-04 at 21:20:51 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: > Rene Gollent <anevilyak@xxxxxxxxx> wrote: > > On Mon, May 4, 2009 at 12:12 PM, Fredrik Modèen <fredrik@xxxxxxxxx> > > wrote: > > > I don't think MediaPlayer should open a file that it can't handle. > > > What if > > > it is a really big file and when it has finally finished reading your > > > file > > > you get an error. I don't have a better idée though. > > It's not that simple. We can't know if we can/can't handle a file > > without first reading its container headers to find out the codecs used > > within it. Only then can we check if we have the necessary codecs > > or not. The problem being talked about here is rejecting them based off > > the BEOS:TYPE attribute without even looking at the file data at all, > > which is almost certainly not correct. > > We could at least limit the allowed supertypes to application, video, and > audio, I would guess. We may not get around some additional logic before adding files to a playlist. If I drop a folder, I don't want it to add album art or .m3u playlists which may be contained in the same folder. At least I don't want to get a warning when those files are added regardless and then bubble up in the playlist later. I think we talked about the OGG MIME type problem before, and if my memory isn't failing me, it's now legal to use audio and video super type for OGG. In this specific routine that we are talking about, I don't want to run expensive detection of the file. It's used when adding possibly huge amounts of files at once. So whatever we come up with as a solution, it needs to be blazingly fast and still handle filtering out unwanted files from a bunch of dropped files or when adding folders to a playlist recursively. Maybe adding them to the playlist with a tag that other files have been added in the same operation and that nagging about a particular file being unsupported should be supressed could work. Best regards, -Stephan