[CLOSED] Symbolic link

[DigitalBox]

I’m trying to open a symbolic link where the source is an audio file located on my NAS (non BFS).

I have the below error message:

Same when opening the file with the Tracker:

However launching the command below is working fine, meaning the link is valid : MediaPlayer /boot/home/Staircase.flac

I’m trying to identify which part of the system consider the file as “invalid” making it impossible to open via MediaPlayer (except with the above command). Any idea ?

I’ve tried to patch SniffIfGeneric() from Tracker/FSUtils.cpp, in order to handle symbolic link on non-BFS file but without any success.

[nephele]

The destination is beeing considered not a media file, that is without a mimetype that starts with audio/ or video/

I’m actually having a similar problem with opus funnily enough.

In your case try checking if a flac mime entry exists, and if the rule is correct.

[Starcrasher]

I think that there’s no sniffing on external media.
I’d check what happens if the link is pointing to a file on the same disk.
After that, with a different disk but still locally mounted.
And finally with disk mounted via network.
Each time, trying first on a bfs partition then on a non bfs partition.
It should tell you where it hangs.

[madmax]

@DigitalBox

I’m trying to identify which part of the system consider the file as “invalid” making it impossible to open via MediaPlayer (except with the above command).

The message comes from MediaPlayer itself. If I remember correctly, it checks that the file you ask it to open has an audio or video MIME supertype. That check may only include the attribute or sniffing in BFS volumes.

[axeld]

Are you using fuse_smb? Is the file system writable?

Since it probably does not support attributes, I’m not sure if the usual mechanism works as it should. IIRC, some file systems use a simple file extension to type attribute mapping.

So I guess your idea to look into Tracker to see what it does, and if it could be fixed is the way to go.

[DigitalBox]

Ok I thought it was an issue with the Tracker, but I think you are right : this limitation seems to come from MediaPlayer (to confirm)

Drag and drop of an audio symlink not on a BFS : MediaPlayer didn’t recognize it

Same with VLC media player : it’s OK

So I will investigate now MediaPlayer sources to understand where this restriction is to change it.

[DigitalBox]

Finally I have identified the problem.

The program for this test :

#include <Entry.h>
#include <Path.h>
#include <NodeInfo.h>
#include <File.h>
#include <stdio.h>

int main(int argc, char** argv) {
    if (argc < 2) {
        printf("Usage: %s <symlink_path>\n", argv[0]);
        return 1;
    }

    const char* path = argv[1];
    BEntry entry(path, true);  // traverse = true

    printf("InitCheck() = %d\n", entry.InitCheck());
    printf("Exists() = %d\n", entry.Exists());
    printf("IsFile() = %d\n", entry.IsFile());
    printf("IsDirectory() = %d\n", entry.IsDirectory());

    if (entry.IsFile()) {
        BFile file(&entry, B_READ_ONLY);
        BNodeInfo info(&file);
        char mime[B_MIME_TYPE_LENGTH];
        if (info.GetType(mime) == B_OK) {
            printf("MIME type = %s\n", mime);
        } else {
            printf("Could not get MIME type\n");
        }
    }

    return 0;
}

It means the BNodeInfo.GetType() is missing a “fallback” method when the original audio file is not on a BFS volume.

I’ve tried to patch BNodeInfo.GetType() without any success.

Any idea how to resolve that ?

My current issue is that I’m trying to use GuessMimeType and the starting point is BNode fNode (easy to do from BEntry but not from BNode from my current undestanding).

[PulkoMandy]

@DigitalBox

It means the BNodeInfo.GetType() is missing a “fallback” method when the original audio file is not on a BFS volume.

I’ve tried to patch BNodeInfo.GetType() without any success.

BNodeInfo.GetType returns the right thing: there is no type information for that file yet.

It’s up to the application to handle that case and use the MIME sniffer to try to identify the file in that case. Or maybe the filesystem can do some faking of it based on file extensions (we do this for FAT and NTFS for example, but not yet for NFS).

[DigitalBox]

Ok so it’s a patch on MediaPlayer.

I will look at it thanks!

[PulkoMandy]

Maybe MediaPlayer could skip that step entirely, and instead just try to create a BMediaFile from the file and see if that works?

It’s going to do that anyways, so I’m not sure what the MIME type check is useful for.

[Lrrr]

@PulkoMandy

I’m not sure what the MIME type check is useful for

I glanced at the code the other day. I’m not sure, but I believe it’s trying to determine whether the file is a playlist or a media file.

[DigitalBox]

I confirm the code is trying to determine:

• If it’s an audio file (that’s where the symlink on non BFS is failing)
• If it’s something else : there’s no comment in the code, so maybe it could be in case the file is a playlist ?

	} else if (entry.IsFile()) {
		BString mimeString = _MIMEString(&ref);
		if (_IsMediaFile(mimeString)) {
			PlaylistItem* item = new (std::nothrow) FilePlaylistItem(ref);
			if (!_ExtraMediaExists(playlist, ref)) {
				_BindExtraMedia(item);
				if (item != NULL && !playlist->AddItem(item))
					delete item;
			} else
				delete item;
		} else
			printf("MIME Type = %s\n", mimeString.String());
	}

Maybe a better approach would be :

• If the file is a playlist (or if hypothesis is wrong, remove this test)
• Else whatever the file, add it to the playlist : it that case symlink on non BFS should work

[DigitalBox]

Ok removing the test “_IsMediaFile(mimeString)” resolves the issue

And in case of a bad media file the below error is displayed:

I put this topic as closed, and let’s move now to gerrit for the next step:p

Thanks for the direction to follow!

[nephele]

Your issue is already adressed on gerrit, that is the minetype not beeing set.

Please provide feedback to it: https://review.haiku-os.org/c/haiku/+/9683

[DigitalBox]

I don’t think this is the same issue: the link you have shared is about Tracker source code, whereas the issue I’ve raised is MediaPlayer related.

[nephele]

The issue is that the file is not correctly identified. Yes, the popup is wrong: however MediaPlayer should still get the mimetype correctly, otherwise there is no way that you can “just” click the file and have MediaPlayer open. Identifying the file when the FS doesn’t support it is what the review I send is about, to avoid having to implement fallbacks im every filesystem that does not have extended attributes

[Lrrr]

@DigitalBox

removing the test “_IsMediaFile(mimeString)” resolves the issue

I wonder if this will cause problems when opening playlist files.

You might be able to add workaround by testing the value of BVolume::KnowsMime() and then skip or alter the _IsMediaFile() check if the BVolume doesn’t have attributes or mime types.

[DigitalBox]

Ok but on my system, when double click on the flac audio file on NFS, it is opening MediaPlayer correctly (and playing the audio)

The scenario which was not working for me is when I open the symlink (on BFS) corresponding to this audio file.

If the issue is to be fixed earlier, it means the below code must be fixed (NodeInfo to retrieve the correct MimeType?) :

/*static*/ BString
Playlist::_MIMEString(const entry_ref* ref)
{
	BFile file(ref, B_READ_ONLY);
	BNodeInfo nodeInfo(&file);
	char mimeString[B_MIME_TYPE_LENGTH];
	if (nodeInfo.GetType(mimeString) != B_OK) {
		BMimeType type;
		if (BMimeType::GuessMimeType(ref, &type) != B_OK)
			return BString();

		strlcpy(mimeString, type.Type(), B_MIME_TYPE_LENGTH);
		nodeInfo.SetType(type.Type());
	}
	return BString(mimeString);
}

I don’t have the full picture, but that’s my current understanding.

[nephele]

If this only for the symlink then the bug isn’t in MediaPlayer though?

MediaPlayer not seeing a correct mimetype is a bug in any case.

[DigitalBox]

Indeed, I will check that, and also any other feedback during the PR review.

EDIT: tested and no issue with playlist files