Bazarr doesn't recognize subtitles on disk - Raspberry PI and Docker

[fygonzalo]

Bazarr doesn't recognize existing subtitles on disk, even the ones downloaded by itself. I am running Bazarr 0.7.5 from a docker image from linuxserver, on a Raspberry PI with Raspbian 9.9 (stretch)

This is the log:

02/06/2019 01:09:49|DEBUG   |root                            |BAZARR started subtitles indexing for this file: /movies/MyMovie/MyMovie.mkv|
02/06/2019 01:09:49|DEBUG   |subliminal_patch.core           |external subs: scanning path /movies/MyMovie/MyMovie.mkv|
02/06/2019 01:09:49|DEBUG   |subliminal_patch.core           |Found subtitles {}|
02/06/2019 01:09:49|DEBUG   |subliminal_patch.core           |external subs: found {}|
02/06/2019 01:09:49|DEBUG   |root                            |BAZARR storing those languages to DB: []|
02/06/2019 01:09:49|DEBUG   |root                            |BAZARR ended subtitles indexing for this file: /movies/MyMovie/MyMovie.mkv|

The movie and its subtitles are visible whithin the docker container:

root@f1b3f20dd365:/movies/MyMovie# ls -la
total 10994788
drwxr-xr-x  2 abc users        4096 Jun  2 00:49  .
drwxr-xr-x 48 abc users        4096 Jun  3 08:52  ..
-rwxr-xr-x  1 abc users       87753 Jun  2 01:02 'MyMovie.en.srt'
-rwxr-xr-x  1 abc users       82098 Jun  2 17:03 'MyMovie.es.srt'
-rwxr-xr-x  1 abc users 11258470614 May 28 14:01 'MyMovie.mkv'

I edited the movie name to avoid troubles.

I guess this problem is related to issue #334. The problem comes from the usage of scandir python module when searching for external subtitles. Specifically, this line: https://github.com/morpheus65535/bazarr/blob/bed98832ed2a5b596265712bb3c0ac77d28ed264/libs/subliminal_patch/core.py#L577

When running scandir within the container, in the same folder listed above, it returns:

root@c48399b4952c:/app/bazarr/libs# python
Python 2.7.16 (default, May  6 2019, 19:35:24) 
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import scandir
>>> list(scandir.scandir("/movies/MyMovie/"))
[<PosixDirEntry: '\x0c'>, <PosixDirEntry: '$'>, <PosixDirEntry: ','>, <PosixDirEntry: '7'>, <PosixDirEntry: '\x7f'>]

So is obvious why it doesn't find any subtitle.

Forcing the usage of scandir.scandir_generic returns a valid result:

>>> list(scandir.scandir_generic("/movies/MyMovie/"))
[<GenericDirEntry: 'MyMovie.en.srt'>, <GenericDirEntry: 'MyMovie.es.srt'>, <GenericDirEntry: 'MyMovie.mkv'>]

If I run scandir on the same folder, but outside docker container, it works as expected, so I guess there is a problem with scandir and the docker container.

To fix this issue I forced the use of scandir_generic adding scandir_generic=True to this line https://github.com/morpheus65535/bazarr/blob/bed98832ed2a5b596265712bb3c0ac77d28ed264/libs/subliminal_patch/core.py#L652

Now bazarr works as expected, identifying all existing subtitles. Obviously this isn't the best fix because would force everyone to use scandir_generic, and according to scandir source code, this is the least prefereable implementation.

I don't know if there is something wrong with docker and scandir library, and if they can fix it. I guess the easier way to fix this would be allowing the user to select if wants to force the usage of scandir_generic, in cases when there are problems identifiying subtitles.

[morpheus65535]

@pannal you can take a look at that one?

[pannal]

Yeah, that's weird. Apparently scandir somehow expects other results from the underlying filesystem.

Not using scandir can be an option. Doesn't bazarr also provide a ready to use docker image? Does that happen there as well?

[morpheus65535]

That's definitely not an issue that we have faced with LSIO Bazarr image.

[fygonzalo]

That's definitely not an issue that we have faced with LSIO Bazarr image.

Keep in mind this problem happens on armhf image linuxserver/bazarr:arm32v7-latest. I found other related issues without resolution: #393 and #399. First one (393) solved installing bazarr on host instead of using docker. Second one still has the issue.

Also I am not saying that bazarr image is the problem, maybe scandir library has problem running on any docker container on armhf or is a configuration problem.

[morpheus65535]

You are right, I sometimes forget that we have docker images for other architecture than x86.

[pannal]

Well, there's an easy fix for this: detect docker and disable scandir if needed.

I can implement that pretty quickly. The bigger thing to solve is how to detect/prevent the issue, as scandir is a much better idea than listdir for big directories.

[morpheus65535]

The problem isn’t present in x86 images so just detecting Docker is not the solution. We have to validate the architecture. I’ll test on my Pi tonight if the problem is present when running from sources.

[pannal]

Exactly. Detecting docker and a quick scandir test on a library to check for the funky characters above should be fine.

[morpheus65535]

I can confirm that using Raspbian 9 and Python 2.7.13 it's working like it should when I run it from the source (not using Docker image). It sound like there is something wrong with armhf docker image. I'll talk to them and report back.

[CHBMB]

@morpheus65535 Can you test using Docker on the Pi?

[morpheus65535]

@CHBMB I don't have docker running on a RPi.

@FYGonzalo Can you try the new build?

[fygonzalo]

@morpheus65535 Yes, no problem. I'll report back when done.

[CHBMB]

The new build hasn't been merged to master.....

[morpheus65535]

Si he should test development tag?

[CHBMB]

No, it's still being built on CI, and then there will be a build in our lspipepr/bazarr repo.

Should be able to get the exact tag from the CI report but pretty sure latest on that repo will be it.

[CHBMB]

@FYGonzalo lspipepr/bazarr:arm32v7-v0.7.5.1-pkg-7197a3a5-pr-25

[CHBMB]

@morpheus65535 OK, I'm not a Python guy. Just testing the x64 build

root@da2a4b3e16b8:/# pip freeze
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
app-version==1.0.1
asn1crypto==0.24.0
bcrypt==3.1.6
certifi==2019.3.9
cffi==1.12.3
chardet==3.0.4
Cheetah==2.4.4
configparser==3.7.4
cryptography==2.7
enum34==1.1.6
gevent==1.4.0
greenlet==0.4.15
idna==2.8
ipaddress==1.0.22
lxml==4.3.0
Markdown==3.1.1
ndg-httpsclient==0.5.1
notify==0.3.1
paramiko==2.5.0
Pillow==6.0.0
psutil==5.6.2
pyasn1==0.4.5
pycparser==2.19
PyNaCl==1.3.0
pyOpenSSL==19.0.0
requests==2.22.0
six==1.12.0
urllib3==1.25.3
validate-email==1.3
virtualenv==16.6.0

I can't see the scandir package here? Is that expected?

If I then do

pip install scandir

I get

root@da2a4b3e16b8:/# pip install scandir
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Collecting scandir
  Downloading https://files.pythonhosted.org/packages/df/f5/9c052db7bd54d0cbf1bc0bb6554362bba1012d03e5888950a4f5c5dadc4e/scandir-1.10.0.tar.gz
Installing collected packages: scandir
  Running setup.py install for scandir ... done
Successfully installed scandir-1.10.0

Then check my python packages again

root@da2a4b3e16b8:/# pip freeze
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
app-version==1.0.1
asn1crypto==0.24.0
bcrypt==3.1.6
certifi==2019.3.9
cffi==1.12.3
chardet==3.0.4
Cheetah==2.4.4
configparser==3.7.4
cryptography==2.7
enum34==1.1.6
gevent==1.4.0
greenlet==0.4.15
idna==2.8
ipaddress==1.0.22
lxml==4.3.0
Markdown==3.1.1
ndg-httpsclient==0.5.1
notify==0.3.1
paramiko==2.5.0
Pillow==6.0.0
psutil==5.6.2
pyasn1==0.4.5
pycparser==2.19
PyNaCl==1.3.0
pyOpenSSL==19.0.0
requests==2.22.0
scandir==1.10.0
six==1.12.0
urllib3==1.25.3
validate-email==1.3
virtualenv==16.6.0

Is that expected? 'Cos I'm confused.....

Is it worth @FYGonzalo trying to install it with

pip install scandir

is my question? Does bundling the scandir lib in your application mean it's x64 only? vs being installed at docker build time which would pull the correct arch?

[morpheus65535]

Scandir 1.06 is included in Bazarr libs directory. It’s pure Python code and isn’t compiled so it’s suppose to be agnostic of architecture.

@Pannal should we upgrade to scandir 1.10?

[fygonzalo]

Tried that docker image, no luck, the problem persist, scandir returns unexpected values.

Also tried removing all scandir files from /app/bazarr/libs/ and installing scandir from pip but the problem is still there.

[morpheus65535]

Thank you. I was going to suggest to do this exact same test so we've skip an additional back and forth. :-)

@pannal could you please implement what you suggested earlier? Test for scandir return and if it doesn't make sense, fall back to listdir?

[thelamer]

I believe the core problem is the you stash some bins in your git repo. On x86 they work for ffprobe and unrar but not on arm variants. Can anyone in this thread test this build?

lspipepr/bazarr:arm32v7-latest

Keep in mind you can spinup and test arm stuff on x86 like this:

docker run --rm --privileged multiarch/qemu-user-static:register --reset
docker run --rm -it -p 6767:6767 lspipepr/bazarr:arm32v7-latest bash

We bake in qemu bins specifically for this purpose. I have never used this application so I am not sure I can properly test this issue.

This should eliminate any differences between the arm and x86 env.

[morpheus65535]

@thelamer I can try your build but, like I said before, if I install the same way you do in your image but directly on my RPi running Raspbian 9, it works like a charm.

Regarding those executable, if we don't have them for the desired architecture, we don't use them. In fact, those executable are not event used to detect external subtitles (.srt).

I will test your image once kids are into bed but can you tell me what changes you've made?

[thelamer]

Rebased to our base image instead of a full python base. Install off of your requirements.txt and install the following deps:

ffmpeg
libxml2
libxslt
python2
unrar
unzip

As far as environment differences have you thought about stuff like overlay2 vs aufs for the docker storage driver? It messes with stuff like inotify not sure the hard deps scandir needs.

[morpheus65535]

Ok thanks for the support btw. :-)

No I've not matched that part. I've made an installation from source as documented on our wiki.

I'll report back in an hour or so.

[pannal]

This seems to me like an fs layer issue. I can circumvent that by detecting and fixing it by not using scandir, but that's a bandaid and not a fix.

Either scandir has wrong expectations regarding the fs layer, it behaves wrongly in certain situations, or the fs layer exposes itself wrongly. Either way, I'm on vacation, so this will take some time.

You can help by testing those points, though.

[morpheus65535]

@thelamer I can confirm that the issue is still present with this new image: external subs: found {}

[thelamer]

Just to make sure I have not regressed anything

lspipepr/bazarr:amd64-latest

Works fine correct ?

[morpheus65535]

I confirm, it detect external subtitles without any issue using this image.

[treecamp]

i am having the same issue on my Synology DS216+ (intel) with docker, tried linuxserver/bazarr:latest and linuxserver/bazarr:development.

[morpheus65535]

@thelamer Anything else you can do on your side or we should just patch scandir?

[pannal]

@coenboomkamp you didn't try lspipepr/bazarr:amd64-latest though, right?

[thelamer]

@coenboomkamp if you are getting this error on x86 you are outside of the scope of this issue and likely just have permissions problems with your mount, please hop on our discord for support https://discord.gg/YWrKVTn .

@morpheus65535 no there is nothing more we can do from a system perspective, the images are identical , we do need to move to this new image though so I will get the team to merge the pending changes.

[morpheus65535]

@thelamer I understand. Thank you!

@pannal I suppose we have to implement a sanity check on scandir return and fallback to something else if ti doesn't make sense. Could you take a look at this when you get back from vacations? Thanks!

[treecamp]

@pannal I did try the lspipepr image yesterday, not sure which version though, i'm running the image from @hotio now, that seems to work now.

[pannal]

@coenboomkamp please try latest develop.

[treecamp]

Thanks @pannal so is that :latest or :develop?

[morpheus65535]

linuxsevrer/morpheus:development which have been updated 5 hours ago.

[klebercabral]

linuxsevrer/morpheus:development which have been updated 5 hours ago.

fixed for #399 linuxserver/bazarr:arm32v7-development

[fygonzalo]

Yep, seems to be fixed now using linuxserver/bazarr:arm32v7-development. Thanks.

[morpheus65535]

Fine! I'll close this one has it seems to be fixed. Thanks to all!

[mvanbaak]

I have this exact same issue on FreeBSD.

$ uname -a
FreeBSD multimedia-torrenting 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC  amd64
$ python --version
Python 3.7.6

Using bazarr version 0.8.4.1

The 'fun' part is, there are directories that actually work! I'm now trying to get some more info etc and will open a new bug.