Opened 6 years ago

Closed 5 years ago

#9621 closed bug (fixed)

Tracker and MediaPlayer don't recognize filetype without extension

Reported by: Kev Owned by: nobody
Priority: normal Milestone: R1
Component: Applications Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

In the BeOS days, one of the cool features was that the system knew what a file was without an extension. As such, I have many files around without extensions. If I try to open one of these on hrev45407, MediaPlayer says it's not a known type, and Tracker's Identify command does not change the file icon. I rename the file with '.mp4', and MediaPlayer plays it fine, and its icon changes in Tracker. After that I can even rename it back to having no extension, and it still works.

Attachments (1)

Generation Reverse (4.0 MB) - added by Kev 6 years ago.
Generic file (.mp4)

Change History (14)

comment:1 Changed 6 years ago by diver

Could you attach one of such files?

comment:2 Changed 6 years ago by axeld

Haiku has the same mechanism to handle files as BeOS. However, the so called sniffer rules (to detect file formats without an extension) might differ. If you have files that aren't detected yet, it would be interesting if the corresponding file types already have a sniffer rule, and if, why it doesn't work for your files.

In any case, the detected type is stored in an attribute, and won't be removed after you rename the file. You will encounter the same issue, though once you put those files to a file system that does not support attributes.

Changed 6 years ago by Kev

Attachment: Generation Reverse added

Generic file (.mp4)

comment:3 Changed 6 years ago by Kev

That makes sense.

BTW even after renaming, drag-n-drop onto MediaPlayer still fails. It's the double-click, which causes a Tracker "Identify"--which you can do instead of double-clicking--that fixes it. But still, I think MediaPlayer should be able to play it without Tracker having identified it first, no?

comment:4 Changed 6 years ago by phoudoin

Our MPEG sniffer rule is broken, because it was just checking the first byte was a 'G', which was turned any text document starting with a G letter into a video media ;-)

Until we enhanced our sniffer parser to support a repeat pattern (here, checking a 'G' every 188 bytes for the first 100 times can assert at >90% that's a MPEG file...), we rely only on the extension suffix.

It's why when you suffix your files they are *only then* identified as video ones. Which leads to a ticket to improve our sniffer rule pattern grammar... I just can't find it.

Last edited 6 years ago by phoudoin (previous) (diff)

comment:5 in reply to:  3 Changed 6 years ago by phoudoin

Replying to Kev:

That makes sense.

BTW even after renaming, drag-n-drop onto MediaPlayer still fails. It's the double-click, which causes a Tracker "Identify"--which you can do instead of double-clicking--that fixes it. But still, I think MediaPlayer should be able to play it without Tracker having identified it first, no?

I quite agree here, I also think that Media Player being expose to files coming from anywhere should try to force an type identify and not just relying on the current type, if any, before rejecting it because it's not a audio/* or video/* ones.

comment:6 Changed 6 years ago by phoudoin

This ticker is related to #9193, which was a sequel of #7935, BTW.

Last edited 6 years ago by phoudoin (previous) (diff)

comment:7 Changed 6 years ago by X512

On what file system do you store this file? File recognition work only in BFS because it can store MIME types in attributes.

comment:8 in reply to:  7 Changed 6 years ago by Kev

Replying to X512:

On what file system do you store this file? File recognition work only in BFS because it can store MIME types in attributes.

BFS, for sure. I don't currently have any other FSes on my desktop. If you mean how I had it in BeOS and then brought it to Haiku without it ever having been identified, it's possible there was an in-between time where I had it on another FS or zipped or something (although I thought ZIPs kept attributes.)

comment:9 in reply to:  7 Changed 6 years ago by phoudoin

Replying to X512:

On what file system do you store this file? File recognition work only in BFS because it can store MIME types in attributes.

File type persistancy is indeed dependant on attributes, but Tracker for instance does file type identification even on FS that can't keep it persistant, which allow at least match with apps supporting that type. For instance, #7935 was about wrongly typed text files stored on a NTFS volume.

Last edited 6 years ago by phoudoin (previous) (diff)

comment:10 Changed 6 years ago by Kev

So...shouldn't it work?

comment:11 Changed 5 years ago by Kev

Still getting this on MP4s on BeFS volumes on hrev46756. It can get in the way because I usually mount my media volume read-only (following the warning that Haiku is still alpha...) so I have to copy files to the desktop and rename them before I can use them.

comment:12 in reply to:  6 Changed 5 years ago by Kev

Replying to phoudoin:

This ticker is related to #9193, which was a sequel of #7935, BTW.

Will the recommendations in #9193 be implemented, to make more flexible sniffer rules?

comment:13 Changed 5 years ago by pulkomandy

Resolution: fixed
Status: newclosed

Added a sniffing rule for mp4 in hrev48418. Works fine for the attached file, please let me know if you need more files sniffed.

Note: See TracTickets for help on using tickets.