MIME types not recognised on NTFS - cant play music / video from NTFS partition

[streak]

since few rev's [ and on hrev36511 ] i cant play any media files (mp3 / avi / other) from NTFS. Even dragging / dropping files onto media player not starting it..

The same copied media files on BFS works [media player starts playing it ].

[korli]

This could have started with hrev36178 and hrev36296 from François. Though this problematic fs support should also detected by the registrar and not rely on attributes on this case.

[streak]

Seems every file from NTFS [mounted as read/write] cannot be opened/started. Mime detection fails with media files aswell as with simple like -> *.txt

[streak]

Tested on official A2

[kvdman]

I can confirm this problem.

[streak]

Still occurs in hrev37017 [ r1a2 nightly ]

[streak]

still present in hrev37693

[khallebal]

hi shouldn't this ticket get a higher priority?,just a suggestion as this bug is quite ennoying and renders the support for the ntfs useless.

[diver]

Also there have been several releases of ntfs-3g ​http://www.tuxera.com/community/release-history

[diver]

BTW, one could try to get an image of Haiku prior hrev36178 and get ntfs driver from there until this bug is fixed.

[stippi]

If incomplete attribute support in the NTFS fs add-on is the problem, then it sounds like the actual problem may be in Tracker. Maybe it invokes the manual MIME-type detection not in all situations when it should. Ups, just saw korli already mentioned this in the first comment.

[stippi]

Better yet: Tracker should simply sniff any MIME-type of a file that it displays. On BFS volumes, you get unrecognized files - until you drag them, or even until you select them and open a menu. Pretty useless IMHO, it might as well figure out the type right away. And when there is an error setting the type attribute (which I presume will be the case on NTFS), then it should fall-back to fake the type like on a non attribute capable FS.

[tangobravo]

Replying to stippi:

Better yet: Tracker should simply sniff any MIME-type of a file that it displays.

Agreed. I suppose there were performance reasons to think about back in the 90s, but this behaviour is one of the very few areas where Haiku feels dated to me (compared to the rest of the OS, which is "live", fast, and responsive).

[khallebal]

i totally agree with tangobravo i don't think the prob is in the ntfs driver,but in the tracker,as i remember having this same prob back in the beos days.

[anevilyak]

It's not quite that simple, the problem is Tracker just relies on the mime sniffer updating the BEOS:MIME attribute on the file, it doesn't sniff it out as it goes. Since other filesystems (i.e. NTFS) won't have that attribute, it won't be able to read the type from it that way. iirc on R5 the built-in NTFS driver was hardcoded to present a fake mime attribute for specific file extensions (i.e. .mp3) for Tracker to work with.

[streak]

Can some portions of the source be reverted to previous release, then? [MIME detecting on NTFS was working in R1A1, for example ]

[mmu_man]

Replying to streak:

Can some portions of the source be reverted to previous release, then? [MIME detecting on NTFS was working in R1A1, for example ]

No it was not working. It was hardcoded by an internal (and incomplete) extension to mime table.

At least this should be moved to a mime fs overlay, instead of being duplicated in each fs.

Though attributes should be correctly saved to NTFS named streams so there must be some problems.

[korli]

Fixed in hrev38324.

[mmu_man]

Oh thanks for that one :-)