[smb] could not open file from LAN

[Soukyuu]

Using current git master, smbclient is installed on my archlinux x64 box and I can access the files via KDE's interface. When passing an "smb://server/path/file.mkv" file to mpv, it shows:

Playing: smb://server/path/file.mkv
Using netbios name SOUKYUU.
Using workgroup WORKGROUP.
[smb] could not open file from LAN: "smb://server/path/file.mkv" 
Failed to open smb://server/path/file.mkv

I have also tried using username@server syntax (as KDE uses it), but same behavior. How can I fix that, except for mounting the folder as a cifs mount each time? Shouldn't it prompt for a password somehow if it needs one?

[ghost]

I really have no clue how smb:// and libsmbclient work or are supposed to work, nor do I have a samba setup, and I don't know of anyone who contributes code to mpv and does. So I'm completely in the dark here.

Does any other software which uses libsmbclient work? Does KDE have its own Samba support?

Shouldn't it prompt for a password somehow if it needs one?

There's no code for such a thing.

[Soukyuu]

I think that KDE uses a KIO slave to access it. I just found this, and it mentions using smb://user:password@server/path/file

This works, but now I'm kind of stuck with how to get that passed by double-clicking on a file in dolphin instead of simple user@server it uses. Maybe it expects the program to prompt the user for a password?

I think I will have to look into things more before continuing here.

[kevmitch]

The syntax that works for me (connecting to a windows 7 share) is.

mpv smb://USER:PASSWORD@SERVER/SHARE/file.mkv

if the share has anonymous (guest) access enabled, then the following should work

mpv smb://guest:@SERVER/SHARE/file.mkv

(note the ":" preceding the empty password)

[kevmitch]

Sorry, I missed that what I just said had essentially already been said.

Anyway, it's weird that KDE passes a smb:// url to an application at all. Most applications can't handle smb directly. What happens when you try to open files with other applications that don't have native smb support?

I would have thought that KDE mounted the smb share somewhere and referred applications to that (which I believe is what gnome does).

[Soukyuu]

What happens when you try to open files with other applications that don't have native smb support?

Deadbeef for example also gets an smb:// url, which it can't parse and gives you a "file not found".

I would have thought that KDE mounted the smb share somewhere and referred applications to that (which I believe is what gnome does).

From what I see, it expects the programs to be able to use the KIO slaves to stream the file. KDE applications use them, for example GwenView can access images on shares like that without problems. Thing is, KDE applications are no console applications, so maybe a KDE GUI for mpv could handle that more gracefully. I don't see how you could make a console application handle that, but I'm by far no expert.

There is also the kioclient exec smb:// method, which would copy the file to your local storage and then execute the default program and pass the cached file to it. Maybe mounting it as cifs is really the least painful way to get it working.

[ghost]

Actually, the mpv.desktop file tells kde that it can understand smb://.

[ghost]

Btw., if someone is trying to make sense out of libsmbclient and it refuses to do so, ideally we could use this lib: https://github.com/videolabs/libdsm/ (but it's not "done" yet)

[Soukyuu]

I'm just wondering here, but why is the whole process transparent on windows? I can open all network files just fine over there and they are not "mounted", it simply accepts the \server\path\file.mkv even though it's the same password protected share.

[kevmitch]

I'm just wondering here, but why is the whole process transparent on windows? I can open all network files just fine over there and they are not "mounted", it simply accepts the \server\path\file.mkv even though it's the same password protected share.

Windows effectively does mount the share to the special "\SERVER\share\" path.

[Soukyuu]

That would make sense, but if you open a command prompt, it mounts the share as a network drive Z:\, so I wonder if \SERVER\share\ counts as a mount path. Otherwise, why would it have to mount it again on Z:\?

[kevmitch]

it's just a user interface distinction. You can also access \SERVER\share on the command prompt

[ghost]

So what is the status of this? I'll just close it.

[Soukyuu]

The status is "invalid" I guess, there is nothing you can really do for password protected shares if the DE is not passing your the password.

[qmega]

Try this: https://gist.github.com/qmega/5825ce96abb06b8cf567

It looks up smb login info from kwallet and puts it into the urls before calling mpv. Requires Python KDE bindings and PyQt4 (though it'd be trivial to use 5).

It's a terrible solution and really sloppy. It probably won't work if you have more than one account for a server in kwallet, it'll probably break if there's an @ in your password, it'll almost certainly break if you specify a username manually in dolphin or whatever (though I could easily fix that), and it's generally all around terrible. But it works for me in the basic case. It's more of a proof of concept than anything else, really.

I only tested with smb, but it might work with others if you add them to SUPPORTED_SCHEMES.

As a side note, it looks like smb:// isn't getting cache auto-enabled anymore?! Don't have time to look into it at the moment.

[kevmitch]

As a side note, it looks like smb:// isn't getting cache auto-enabled anymore?! Don't have time to look into it at the moment.

it was disabled because I found it to actually have worse performance when mpv still used a tiny cache by default. Now that the default cache is larger, I should enable it again.

@wm4 I should set stream->streaming and stream->allow_caching to true?

[ghost]

Sure, if you think that's the right thing. Note that allow_caching is true by default.

[HubKing]

It seems that MPV does not want to support anything Gnome-specific, but since Gnome is the default desktop, and SMB is the default file share method for major Linux distributions like Ubutu, I think it would benefit users greatly if MPV supported this feature, even if the method would be Gnome-specific.

I mean, a file's location should be transparent to the user; whether the file is on an SMB share or on a local disk, users would expect drag-and-dropping works, just like on Windows. On Windows, not a single app fails to open a file on an SMB share like this.

Celluloid, "A simple GTK+ frontend for mpv ", correctly plays the file, if you drag-and-drop a file on an SMB share, unlike MPV, so it should not be that difficult to support this. I wish MPV would do what Celluloid does, so that it would not crash when users drag-and-drop an SMB share file, which should be very common, because not many people would store large video files on a local computer these days.

[qmega]

On Windows, not a single app fails to open a file on an SMB share like this.

Windows mounts SMB shares and applications access them like local filesystems, AFAIK. You can mount SMB shares on Linux-based systems too -- mount -t cifs or its fstab equivalent -- and you ought to get transparent access from any program, similar to Windows. mpv in particular should even auto-enable cache when it detects it's playing a file on a remote mount.

Gnome and KDE use their own IO frameworks instead of mounts, and while there are benefits to that approach, compatibility suffers. Perhaps it's reasonable for a GTK app to implement Gnome's protocol or a Qt app to implement KDE's, but for core mpv to support either would be a large additional dependency. I believe this project has pretty firmly decided not to venture into desktop application territory with the core program and that position isn't likely to change. Projects like Celluloid that you mentioned exist for that purpose.

I could imagine there's room for some sort of more generic wrapper application that e.g. proxies desktop environment IO frameworks using a FUSE mount and passes altered paths to unaware wrapped commands... (but to be clear, that would have nothing to do with the mpv project)

[commi]

This would be fixed with #8731 but isnt yet. Kde nowadays passes a local file path to mpv if mpv says it want 'files' and not 'urls' in same cases.