Under Linux, doesn't produce output for some files

[ScrewThisNoise]

Using 22.03, the app fails to give output for files, with no clear reason as to why. Under windows using the MediaInfo CLI it reads the files quite fine.

Ex: mediainfo /mnt/multimedia/ANIME/Series\ \[SUB\]/Why\ the\ Hell\ Are\ You\ Here\,\ Teacher\!？\ \[14413\]/NandeE/Koko_ni_Sensei_ga\!？_-_08_\[Hi10\]_\(_www_HEVC\)_\[99D08CAC\].mkv

Produces no output on linux, meanwhile, loading the same file produces actual records in CLI

This is just a random file, got like 14000 files that behave the same way.

[kieranjol]

Maybe I don’t fully understand what is happening here, but this looks like the expected GUI output on all operating systems? By default it just gives you a summary. Have you tried switching to a different view like tree, text or html and you’ll see the same output as in the CLI?

[JeromeMartinez]

Empty output usually means that the file is not reachable by MediaInfo. Question marks may be a problem, but I tested on a local file on Linux and it is fine. How is it if you do:

cp /mnt/multimedia/ANIME/Series\ \[SUB\]/Why\ the\ Hell\ Are\ You\ Here\,\ Teacher\!？\ \[14413\]/NandeE/Koko_ni_Sensei_ga\!？_-_08_\[Hi10\]_\(_www_HEVC\)_\[99D08CAC\].mkv ./
mediainfo Koko_ni_Sensei_ga\!？_-_08_\[Hi10\]_\(_www_HEVC\)_\[99D08CAC\].mkv

On my side I tested :

jerome@Jerome:~/test$ mkdir Series\ \[SUB\]
jerome@Jerome:~/test$ mkdir Series\ \[SUB\]/Why\ the\ Hell\ Are\ You\ Here\,\ Teacher\!？\ \[14413\]
jerome@Jerome:~/test$ mkdir Series\ \[SUB\]/Why\ the\ Hell\ Are\ You\ Here\,\ Teacher\!？\ \[14413\]/NandeE
jerome@Jerome:~/test$ touch Series\ \[SUB\]/Why\ the\ Hell\ Are\ You\ Here\,\ Teacher\!？\ \[14413\]/NandeE/Koko_ni_Sensei_ga\!？_-_08_\[Hi10\]_\(_www_HEVC\)_\[99D08CAC\].mkv
jerome@Jerome:~/test$ mediainfo Series\ \[SUB\]/Why\ the\ Hell\ Are\ You\ Here\,\ Teacher\!？\ \[14413\]/NandeE/Koko_ni_Sensei_ga\!？_-_08_\[Hi10\]_\(_www_HEVC\)_\[99D08CAC\].mkv
General
Complete name                            : Series [SUB]/Why the Hell Are You Here, Teacher!？ [14413]/NandeE/Koko_ni_Sensei_ga!？_-_08_[Hi10]_(_www_HEVC)_[99D08CAC].mkv
File size                                : 0.00 Byte

So file name seems correctly handled.

[ScrewThisNoise]

That's weird, I had tried it on several files in the same folder, with very similar names (same name, different ep number) and found some to be working. Moving the file that doesn't work to another folder, it works fine though. I'll try changing the naming scheme and see if that changes things, removing the use of japanese question mark and stuff like that to workaround the use of the normal questionmark being an illegal char, as well as testing more files. I'll get back here after some testing

[ScrewThisNoise]

Turns out if I remove special characters I had in the title and folder The whole tree is replaceing ':' to '-', '?' to '？', '/' to '⁄', '/' to '⁄', '"' to '`'. Changing all of those to _ makes it work on linux. Super strange that, with those in place, it works just fine on windows using the GUI version (not tested cli on windows) though...

there shouldn't be much difference in how media info deals with these two paths, should there?

/mnt/multimedia/ANIME/Series [SUB]/Why the Hell Are You Here, Teacher!？ [14413]/Nande_Koko_ni_Sensei_ga!？_-_08_[Hi10]_(_www_HEVC)_[99D08CAC].mkv P:\ANIME\Series [SUB]\Why the Hell Are You Here, Teacher!？ [14413]\Nande_Koko_ni_Sensei_ga!？_-_08_[Hi10]_(_www_HEVC)_[99D08CAC].mkv

One would believe it would be fine for both OSes...

Also weird if Linux can't read it, since both ShokoAnime and Plex seems to read it just fine where it's at...

[JeromeMartinez]

on windows using the GUI version (not tested cli on windows)

It is better to use the same interface (so CLI) everywhere for better comparison.

Moving the file that doesn't work to another folder, it works fine though.

Weird, because the special chars are still there...

here shouldn't be much difference in how media info deals with these two paths, should there?

The "format" is different (/ vs ), the mount method is different. But weird that on Linux it works in a local dir and not in "/mnt", it should be neutral there. What is the mounting method on Linux?

We'll try to reproduce the issue.

[ScrewThisNoise]

It is a docker container, so it's mounted through the docker config

[ScrewThisNoise]

Did a quick test on windows as well for completionist sake, as expected, it works just the same with CLI as with GUI

[EugeneSakun]

Not sure if that's the same issue or not, but mediainfo v22.03 (running on Ubuntu 20.04, installed using snap) doesn't see files in /tmp/ directory. However, mediainfo v19.09 (installed using apt-get) works fine. Should I create a separate issue for that?

[g-maxime]

@EugeneSakun mediainfo's snap can only access non-hidden files from user directory.

There's not direct ways to access /tmp from snapcraft applications.

[chrisjohnson00]

I've the (same) similar issue.

• I'm running in a Docker container, v21.09
• The file has an accented e in the file name
• When I rename the file to use all non-accented characters, mediainfo outputs correct information

app@ba3a0b205835:/$mediaiinfo -f --Output=JSON /encode_in/Pokémon\ -\ S03E16\ -\ For\ Cryin\'\ Out\ Loud\!\ WEBDL-1080p.mp4 
{
"creatingLibrary": {
"name": "MediaInfoLib",
"version": "21.09",
"url": "https://mediaarea.net/MediaInfo"
},
"media": null
}

Renamed file output:

app@ba3a0b205835:/$ mediainfo -f --Output=JSON /encode_in/Pokemon.mp4 
{
"creatingLibrary": {
"name": "MediaInfoLib",
"version": "21.09",
"url": "https://mediaarea.net/MediaInfo"
},
"media": {
"@ref": "/encode_in/Pokemon.mp4",
"track": [
{
...

[g-maxime]

What is the locale output inside the container?

[chrisjohnson00]

What is the locale output inside the container?

I'm using ubuntu:22.04 as the base container, which has:

app@3bb6ac163a5c:/$ locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

[g-maxime]

I'm able to reproduce this bug with LC_ALL=C before mediainfo command. Will setting the locale inside the container to en_US.UTF-8 or matching it with the host system locale solve the problem?

[chrisjohnson00]

Perfect, thanks!!

I added this to my container:

# Set the locale
RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -y locales && \
    sed -i -e 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen && \
    dpkg-reconfigure --frontend=noninteractive locales && \
    update-locale LANG=en_US.UTF-8 && \
    rm -rf /var/lib/apt/lists/*

ENV LANG en_US.UTF-8

Which results in locale responding with:

app@39b4b7c8cf05:/$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

And mediainfo gets the correct information:

app@39b4b7c8cf05:/$ mediainfo -f --Output=JSON /input/Pokémon\ -\ S03E16\ -\ For\ Cryin\'\ Out\ Loud\!\ WEBDL-1080p.mp4 
{
"creatingLibrary": {
"name": "MediaInfoLib",
"version": "21.09",
"url": "https://mediaarea.net/MediaInfo"
},
"media": {
"@ref": "/input/Pokémon - S03E16 - For Cryin' Out Loud! WEBDL-1080p.mp4",
"track": [
{
...