Tracker and MediaPlayer don't recognize filetype without extension

[Kev]

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.

[diver]

Could you attach one of such files?

[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.

[Kev]

Generic file (.mp4)

[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?

[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.

[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.

[phoudoin]

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

[X512]

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

[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.)

[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.

[Kev]

So...shouldn't it work?

[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.

[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?

[pulkomandy]

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