You are not logged in.
I've recently fallen down a rabbit hole that started with my favored file manager, mc, which has been giving me problems with playing most mp3 files when I highlight them and hit the return key. Instead of invoking my favored media player mpv, it now wants to open many of them using vlc. Honestly, mc has been giving me a lot of complaints recently about config files needing to be updated because of changes being made as the program is developed. It seems to me the relevant change in the case of the problematic mp3 files is that, rather than relying on its own native configuration files for determining what utilities to invoke when opening files (i.e., by highlighting those files and hitting the enter key) as it had done in the past, mc evidently now relies on xdg-utils for determining which utility to use.
If my analysis of the issues is on point, the problem I'm facing has to do with mimetypes. Tests so far indicate that the files that always result in vlc being invoked are mp3 files that, for whatever reason, have mimetype application/octet-stream. The few that open using mpv--my desired media player--have mimetype audio/mpeg.
2 resolutions that occurred to me are: 1) modify the mimetype of the offending files from application/octet-stream to audio/mpeg; or 2) tweaking xdg-utils somehow to cause it to open the application/octet-stream mp3s with the desired application. I so far have not discovered a way to modify the mimetype. I also have been unable to think of a way to cause xdg-utils to cause those files to open with my preferred application, mainly because the mimetype application/octet-stream seems so generic: it seems to me it could cause a lot of additional problems were I to configure the system to open all application/octet-stream mimetype files with mpv.
A third possible resoltuion might be to just remove xdg-utils, thus forcing mc to rely on its native config files like it used to. I don't know how reasonable that would be for my set-up: I don't use a DE but rather have a WM (JWM) that I've configured to mimic the old gonme2 interface, and I prefer to do quite a lot of my computing from the command line. So it seems that xdg-utils may be something I could do without, although I must admit that my grasp of what it is and does is rather limited. So removing it from the system might actually have some undesirable consequences I've not conisdered.
As the case may be, any input on the situation I've described and suggestions for possible resolutions would be appreciated. I've had a look at some of the Arch wiki entries on xdg-utils, xdg-open and the like, and have tried a few minor modifications such as xdg-mime default mpv.desktop audio/mpeg. But the problem of mc invoking vlc when attempting to play many of my mp3s persists. Thanks.
Last edited by jamtat (2024-08-31 07:44:44)
Offline
mc has an internal list of view/open actions, /etc/mc/mc.ext.ini, which you can copy into ~/.config/mc and adjust to your likings.
Afaict it doesn't even use xdg-open anywhere.
Edit: since the copy completely replaces the master in /etc you need to pay attention to updates - once a decade or so the syntax gets an incompatible change
Last edited by seth (2024-08-30 14:43:12)
Offline
Thanks for your input Seth. Here's what I've found on investigating your advice.
Looking at /etc/mc/mc.ext.ini I see the following bit of text related to mp3's:
[mp3]
Shell=.mp3
ShellIgnoreCase=true
Open=/usr/lib/mc/ext.d/sound.sh open mp3
View=%view{ascii} /usr/lib/mc/ext.d/sound.sh view mp3
The content of the shell script sound.sh referenced in that stanza looks like this:
#!/bin/sh
# $1 - action
# $2 - type of file
action=$1
filetype=$2
[ -n "${MC_XDG_OPEN}" ] || MC_XDG_OPEN="xdg-open"
do_view_action() {
filetype=$1
case "${filetype}" in
common)
mediainfo "${MC_EXT_FILENAME}"
;;
mp3)
mpg123 -vtn1 "${MC_EXT_FILENAME}" 2>&1 | \
sed -n '/^Title/,/^Comment/p;/^MPEG/,/^Audio/p'
;;
ogg)
ogginfo "${MC_EXT_FILENAME}"
;;
opus)
opusinfo "${MC_EXT_FILENAME}"
;;
wma)
mplayer -quiet -slave -frames 0 -vo null -ao null -identify "${MC_EXT_FILENAME}" 2>/dev/null | \
tail +13 || file "${MC_EXT_FILENAME}"
;;
*)
cat "${MC_EXT_FILENAME}"
;;
esac
}
do_open_action() {
filetype=$1
case "${filetype}" in
common)
if [ -n "$DISPLAY" ]; then
(audacious "${MC_EXT_FILENAME}" >/dev/null 2>&1 &)
else
play "${MC_EXT_FILENAME}"
fi
;;
mod)
mikmod "${MC_EXT_FILENAME}"
#tracker "${MC_EXT_FILENAME}"
;;
wav22)
vplay -s 22 "${MC_EXT_FILENAME}"
;;
mp3)
if [ -n "$DISPLAY" ]; then
(audacious "${MC_EXT_FILENAME}" >/dev/null 2>&1 &)
else
mpg123 "${MC_EXT_FILENAME}"
fi
;;
ogg)
if [ -n "$DISPLAY" ]; then
(audacious "${MC_EXT_FILENAME}" >/dev/null 2>&1 &)
else
ogg123 "${MC_EXT_FILENAME}"
fi
;;
opus)
if [ -n "$DISPLAY" ]; then
(audacious "${MC_EXT_FILENAME}" >/dev/null 2>&1 &)
else
play "${MC_EXT_FILENAME}"
fi
;;
midi)
timidity "${MC_EXT_FILENAME}"
;;
wma)
mplayer -vo null "${MC_EXT_FILENAME}"
;;
playlist)
if [ -n "$DISPLAY" ]; then
(audacious -p "${MC_EXT_FILENAME}" >/dev/null 2>&1 &)
else
mplayer -vo null -playlist "${MC_EXT_FILENAME}"
fi
;;
*)
;;
esac
}
case "${action}" in
view)
do_view_action "${filetype}"
;;
open)
("${MC_XDG_OPEN}" "${MC_EXT_FILENAME}" >/dev/null 2>&1) || \
do_open_action "${filetype}"
;;
*)
;;
esac
My bash scripting and parsing skills are pretty rudimentary so I'm unable to comprehend a lot of the logic contained in that script, but it does appear to me that xdg-open is being called. Would you disagree? If so, any enlightenment you (or others) may care to provide would be most appreciated.
PS I've tried replacing the line
Open=/usr/lib/mc/ext.d/sound.sh open mp3
with
Open=/usr/bin/mpv open mp3
in the file ~/.config/mc/mc.ext.ini but the system still wants to open mp3 files with mimetype application/octet-stream with vlc
Last edited by jamtat (2024-08-31 06:33:13)
Offline
The default settings still end up xdg-open if present, I meant to point out that you don't have to put up with that in this context.
You can query and alter the default assignments: https://wiki.archlinux.org/title/Xdg-utils#xdg-mime
xdg-mime query default audio/mp3
xdg-mime query default 'audio/*'
You cannot apply the syntax for the sound.sh script to mpv, try
Open=mpv %f
and you'll probably have to restart mc to apply the changes - certainly if you only just now added ~/.config/mc/mc.ext.ini
Offline
You cannot apply the syntax for the sound.sh script to mpv, try
Open=mpv %f
and you'll probably have to restart mc to apply the changes - certainly if you only just now added ~/.config/mc/mc.ext.ini
It works! It works! Thank you so much for that suggestion. I'm heartened to know it's that simple but at the same time left wondering why I was unable to resolve this on my own, even after a fair amount of searching and experimenting. Oh well . . .
The default settings still end up xdg-open if present, I meant to point out that you don't have to put up with that in this context.
You can query and alter the default assignments: https://wiki.archlinux.org/title/Xdg-utils#xdg-mime
xdg-mime query default audio/mp3 xdg-mime query default 'audio/*'
Yeah, I looked at the wiki. The query for audio/mp3 showed mpv.desktop, so all looked in order there. The query for application/octet-stream shows userapp-vlc-QODEVW.desktop, which just made it clear to me that xdg-open was operative when trying to open those mp3s that have somehow been tagged with mimetype application/octet-stream. But having taken your suggestion to replace the line Open=/usr/lib/mc/ext.d/sound.sh open mp3 with Open=mpv %f in the file ~/config/mc/mc.ext.ini, I'm no longer having the issue of mc invoking vlc on mp3 files with mimetype application/octet-stream; they all now seem to open fine with mpv, as I've wanted.
Offline
Here's a follow-up that makes this situation even stranger. I went, using mc file manager, to play an mp3 today and vlc got invoked again. I tried several other mp3's and all resulted in the invocation of vlc. I decided to inspect ~/config/mc/mc.ext.ini to see whether my changes made yesterday had perhaps gotten owerwritten or something: no, the changes I made to that file in hopes of causing mpv to be invoked when I try to open/play and mp3 were just as they had been yesterday. I decided to once again try opening/playing an mp3 under mc and, lo and behold, all mp3 's I tried opening/playing after having inspected mc.ext.ini resulted in mpv getting invoked.
So, what kind of weird thing could be going on here? Is xdg-utils overriding mc.ext.ini until such time as that file is accessed? Is it reinitializing itself or something? I'm stumped by what I'm seeing. Perhaps some wiser minds here can understand why I'm seeing this sort of behavior.
PS Maybe I should remove the [RESOLVED] tag I put in the subject line of this thread yesterday after I thought Seth's suggestion had solved my issue? If mc goes back each day to invoking vlc when I try to open mp3's until I open and look at mc.ext.ini, the issue isn't really resolved after all.
Last edited by jamtat (2024-09-01 12:17:50)
Offline
Is xdg-utils overriding mc.ext.ini
No. And I don't think that "looking at it" has any meaningful impact here.
mc doesn't keep the config open, so there's no chance to see what it has parsed after the fact.
You can however (if this happens again) edit the extension config from the F9 menu
Did you re-use the same mc PID for the unsuccesful and succesful invocation? How did you start the mc instance(s) (automatically, interactive shell, some desktop icon - same for all instances)?
Assuming you've not been using an older mc instance that had not parsed the custom mc.ext.ini I suspect this is down to the specific files, notably their suffixes - were they upcased or maybe .m4a rather than .mp3? (There's another entry for a whole slew of audio formats that are matched w/ a regexp.
The next best (far fetched) explanation I could come up w/ is
a) some dotfile syncing, ie. you're getting/mounting ~/.config from somewhere else and started mc before that.
OR
b) the particular instance of mc had some bogus XDG_CONFIG_HOME exported to it
Offline
Thanks. These are some really cogent observations. I'd forgotten that yesterday, when I went to test whether the modifications to mc.ext.ini had been successful in causing mc to invoke mpv rather than vlc when opening mp3s, I'd started a new instance of mc. However when I tried opening an mp3 today, I'd used an mc instance that had been already open prior to modifying mc.ext.ini. So that could well explain why, in that instance, vlc was still being invoked when opening an mp3. But it was also in that same previously-opened instance that I then inspected to content of mc.ext.ini to see whether my modifications had persisted, after which inspection, mc did invoke mpv when trying to open an mp3. So it could well be that opening and closing mc.ext.ini within that instance had caused it to register the changes I'd made in mc.ext.ini, correct? That seems to me like it could be a legitimate explanation for the strange behavior I witnessed today.
Last edited by jamtat (2024-09-01 19:46:54)
Offline
So it could well be that opening and closing mc.ext.ini within that instance had caused it to register the changes I'd made in mc.ext.ini, correct?
I don't know the actual code but would highly expect mc to reparse the config when it's certainly aware of pot. modifications.
Not so much to inotify-watch it (mc probably predates inotify by a decade or so
My best advise would be to just keep an eye on it, but I'd be surprised if changing the ini doesn't actually enforce the mpv invocation.
Offline