search

filebot / filebot-docker

Docker build files for FileBot
https://hub.docker.com/r/rednoah/filebot/
Apache License 2.0
55 stars 18 forks source link

Filebot xpra doesn't take files #9

Closed xeviff closed 2 years ago

xeviff commented 2 years ago

From inside the docker I created a file (so it has write permissions), I readed the content of file (so it has execution permissions). Here is the proof: image

But when I select a movie file in the Load > Select Files window: image

The file is not loaded image

I found this log in the console: Aug 29, 2021 11:05:22 AM net.filebot.ui.transfer.FileTransferable getFilesFromTransferable WARNING: GVFS: file:///hack3_pelis/ð%C2%9F¤%C2%96Filebot/1/Belleza%20eterna%20(Eternal%20Beauty)%20(2020)%20%5BWEB-DL%201080p%20X265%2010bits%5D. => java.io.FileNotFoundException: /hack3_pelis/ð<0x9F>¤<0x96>Filebot/1/Belleza eterna (Eternal Beauty) (2020) [WEB-DL 1080p X265 10bits].

rednoah commented 2 years ago

WARNING: GVFS: ... error messages can only happen during drag-n-drop or copy-n-paste. Not sure how to do that with xpra in the first place since you can't open a File Manager window in the first place.

This error message is possibly misleading. You'll want to play around with it. Delete the log. Try again. See if you can consistently generate this log entry every time you select a file.

Notably, even the GTK File Dialog seems to have trouble displaying some of these characters. That could be a clue.

rednoah commented 2 years ago

Also, the error message is technically correct, since the file path (seemingly cut off at the end for unknown reasons) does indeed not exist:

file:///hack3_pelis/ð%C2%9F¤%C2%96Filebot/1/Belleza%20eterna%20(Eternal%20Beauty)%20(2020)%20%5BWEB-DL%201080p%20X265%2010bits%5D.
/hack3_pelis/ð<0x9F>¤<0x96>Filebot/1/Belleza eterna (Eternal Beauty) (2020) [WEB-DL 1080p X265 10bits].
rednoah commented 2 years ago

I've been able to reproduce the issue with different File Dialog implementations using the following sample file path:

/volume1/😺/😺.groovy

A. GTK File Dialog via JavaFX (-Dnet.filebot.UserFiles.fileChooser=JavaFX)

/volume1/ð<0x9F><0x98>º/ð<0x9F><0x98>º.

B. GTK File Dialog via Java AWT (-Dnet.filebot.UserFiles.fileChooser=AWT)

volume1/ð/ð<0x9F><0x98>º.gro

C. Java Swing JFileChooser (-Dnet.filebot.UserFiles.fileChooser=Swing)

/volume1/😺/😺.groovy

JavaFX and AWT both being broken, but in different ways, is rather interesting.

Setting JAVA_OPTS to -Dnet.filebot.UserFiles.fileChooser=Swing can be used to work around the problem. However, making this default is not ideal since the GTK File Dialog UI is significantly better.

rednoah commented 2 years ago

The underlying issue may have been fixed with JavaFX 17: https://bugs.openjdk.java.net/browse/JDK-8210199

However, Ubuntu 20.04 packages OpenJFX 11.0.6 at this point in time. A future update will hopefully resolve the issue.

xeviff commented 2 years ago

cool! you found the problem cause and possible solutions.

It semms the way that can make it work right now is the JAVA_OPTS trick... I tried and now it is taking the files! Thanks

xeviff commented 2 years ago

Well, I think I celebrate the victory very quick. The files are taken, but I can't work with them This validation allways fail when the files are inside a path with special characters image

I copied the same files into another folder (withour special characters) and it works... Dammit, I dedicated many hours decorating the folder texts :(

rednoah commented 2 years ago

IDK, but it's very possible that libmediainfo doesn't play well with esoteric file paths like that.