POSTBUCKET - where random posts in unrelated topics go

[iAmKoinu]

Hi there! Loving the program, just wanted to know if you planned on making this code customizable? I don't keep my episodes in the "SxE" format, and while i do know that I can just easily rename it to my liking with the preset I already have, it would be really nice to be able to convert absolute to my preferred naming scheme in one go!

Thanks for all your hard work!

[rednoah]

Yes, should be pretty straight forward. What's not working? Where are you stuck?

e.g. convert Absolute to SxE in one go using your format:

Code: Select all

filebot -rename "One Piece 501.avi" --db TheTVDB --order Absolute --format "{n}.{y}.{order.airdate.s00e00}.#{absolute}.{t}.[{airdate}]" -non-strict

[KRONZO]

could you please add luksusfaelden to luksusfælden (luxury trap(english)) it's impossible to match it always choose luksusfellen witch is the swedish or norwiegian version

Code: Select all

Luksusfaelden.S21E06.DANiSH.720p.HDTV.x264-DiViSiON/
luksusfaelden.s21e06.720p-division

[rednoah]

Added custom alias for The Luxury Trap ➔ Luksusfælden to make things work out the box for this particular use case in the future.

[KRONZO]

thank you for that. any chance you could add for luksusfælden so this would work to "luksusfaelden" that is the normal danish release name but i think that's what throwing filebot of

[rednoah]

The Luxury Trap is the primary English title, so it should always work. Luksusfaelden probably already works because it's the official Danish title.

[KRONZO]

but the problem is, it is not the official title the official title is luksusfælden but it is released as luksusfaelden.

if i rename the files to luksusfælden it will match it correctly, but luksusfaelden match wrong everytime

[rednoah]

Ah. I see. It's the other way around then.

[Lantizia]

Hey, long time user here (just bought a lifetime license - although have donated before and also was a part of the patreon thing until it went no where)...

Just installed via APT and noticed a few odd quirks...

You're probably best not telling people to use --install-suggests. Mostly because a) 'recommends' would be a better fit and b) using --install-suggests is recursive, so you end up with a whole Web server (in my case apache2) being installed just because you installed FileBot ...

Code: Select all

lantizia@loki:~/Downloads$ aptitude why apache2
i   filebot           Suggests   ffmpeg                                
i A ffmpeg            Suggests   ffmpeg-doc                            
i A ffmpeg-doc        Depends    libjs-jquery                          
i A libjs-jquery      Recommends javascript-common                     
i A javascript-common Suggests   apache2 (>= 2.4.6~) | lighttpd | httpd

Also in your last post to this thread you said the JRE is built in, if that is the case - why is it on the suggests list? (which is currently... openjdk-10-jre openjfx mediainfo libchromaprint-tools)

Perhaps a better apt-get line would be simply...

Code: Select all

sudo apt-get -y install openjfx mediainfo libchromaprint-tools filebot

Or instead make openjfx, mediainfo and libchromaprint-tools to be 'recommends' instead. Most desktop users are used to extra stuff being pulled in via recommends, whilst server administrators (I do this on my Debian boxes) turn off automatically installing recommends as a matter of course.

Thanks for all the hard work

Steven

p.s. more info on Debian policy for using suggests/recommends can be found here... https://www.debian.org/doc/debian-polic ... re-depends

[vincen]

Still have again the problem of access at local files Installed it with deb package using the script suggested but Filebot is unable to access any local files of the system :(

[rednoah]

You're probably best not telling people to use --install-suggests. Mostly because a) 'recommends' would be a better fit and b) using --install-suggests is recursive, so you end up with a whole Web server (in my case apache2) being installed just because you installed FileBot ...

Well, that definitely sucks...

Also in your last post to this thread you said the JRE is built in, if that is the case - why is it on the suggests list? (which is currently... openjdk-10-jre

Due to the changes in JDK 11 (i.e. no more Oracle JRE with JavaFX built-in) there's no point to do this on Linux in the future. Is there a working OpenJFX 11 package in the Debian repository already?

Perhaps a better apt-get line would be simply...

Code: Select all

sudo apt-get -y install openjfx mediainfo libchromaprint-tools filebot

Or instead make openjfx, mediainfo and libchromaprint-tools to be 'recommends' instead. Most desktop users are used to extra stuff being pulled in via recommends, whilst server administrators (I do this on my Debian boxes) turn off automatically installing recommends as a matter of course.

Quite possibly. If Recommends is indeed pulled automatically on Desktop Linux machines, then it makes sense to do:

Code: Select all

Depends: <stuff required for the CLI>
Recommends: <stuff required for the GUI only>

Does that sound reasonable?

[Lantizia]

If I think I understand you correct, both Debian and Ubuntu have openjfx as it's own package...

http://packages.debian.org/openjfx (which is OpenJFX v8 in Debian 9 - the latest stable version, but it'll be v11 in the next version of Debian)
http://packages.ubuntu.com/openjfx (again it is v8 in Ubuntu 18.04 - the latest long term version that I use, but its v11 in Ubuntu 18.10 and it'll be v11 in 19.04)

I wouldn't be able to say one way or the other how this affects FileBot as I'm not too familiar with the JFX bit.

Your "DEBIAN/control" file in the package could simply change this one line...

Code: Select all

Suggests: openjdk-10-jre, openjfx, xdg-utils, ffmpeg, mediainfo, libchromaprint-tools

For...

Code: Select all

Recommends: openjdk-10-jre, openjfx, xdg-utils, ffmpeg, mediainfo, libchromaprint-tools

I wouldn't specify any "Depends: " unless any of those packages are critical for the core functionality of FileBot to operate normally.
If 100% of those additional packages are optional, then they need to be "Recommends: "

This is fine as *all* Debian-derived distributions I've ever encountered (BOTH servers and desktops) all install recommended packages by default.

It's only certain server-admins (like me) that manually make it system-wide policy not to install recommends on server - just so that we can see what they'd be and choose to install them after if needed to lower the security footprint of the server.

If you do make the above change, remember that in your deb.sh file you can change...

Code: Select all

sudo apt-get install filebot --install-suggests

To simply be...

Code: Select all

sudo apt-get install filebot

As for the idea about CLI usage vs GUI usage. Most packages I've seen usually have a 'filebot-cli' and a 'filebot' (or filebot-gtk, filebot-ui, etc...). Essentially the 2nd package (the ui one) makes 'filebot-cli' a dependency of itself. That might be one possible thought?

But depends vs recommends vs suggests - this hasn't really got anything to do with purpose such as cli vs gui

[rednoah]

FileBot 4.8.5 is now in BETA and a new Debian package is available for testing here:
https://get.filebot.net/filebot/FileBot_4.8.5/

Feedback is welcome.

The new Debian package is now platform-independent and can work an any architecture, but that means that all native code is handled via APT dependencies, i.e. OpenJDK 11 and OpenJFX 11 is now required.

You may need the latest version of Ubuntu, since older LTS releases will give you OpenJFX 8 and not OpenJFX 11 if you do apt install openjfx.

[Lantizia]

Not tested this package yet - but after reading what you've wrote... this sounds like a step backwards!

Nobody in their right mind runs a non-LTS version of Ubuntu unless they're prepared to deal with the unforeseen consequences of something that...
a) only got knocked up because it happened to be either the month of April or October in a year - and not because it was actually ready or properly tested.
b) only gets support for 9 months.

It's more like a preview release in my mind - not really like bi-annual Windows 10 update... as with a non-LTS Ubuntu *every* package version changes breaking the ability to use many 3rd party bits of software which are not ready for it.

Most people (like me) who use Ubuntu in a production environment (personally for me that is definitely my place of work, but also at home as I don't want to be fixing bugs all day) will use whatever the latest LTS is (usually about 4 months after it came out to let the dust settle) and in the case of 18.04 it'll be supported until April 2023 - but most will switch to 20.04 at around August 2020 (4 months after the release of 20.04).

Please don't make this only usable on (in my opinion) non-stable Ubuntu versions only - and especially on Debian 10 only, as that thing is definitely not stable!

[rednoah]

Maybe you can try it and see if there's any particular issue on 16.04 LTS or 18.04 LTS. Since I still only use Recommends the package will should install just fine on any system, allowing you to satisfy dependencies manually as needed.

AFAIK, only OpenJFX is a problem, but that's not even required at all if you're only interested in the CLI tools, and easy to install (i.e. copy files) manually if needed and that I could help automate via shell scripts.

If Java 11 is an issue, then we could consider sticking to Java 8 (which makes JavaFX work out of the box on 18.04 but not work on anything newer) but the portable tar is already there to cover people that need backwards compatibility.

Anyway, I'm open to suggestions here, especially considering that GUI users and CLI users might very likely be running on different environments.

[Lantizia]

So now on a fresh Ubuntu 18.04 install (tested in a VM) - if you just download the .deb file and open/double-click it normally (letting GDebi install it graphically) you'll end up with filebot failing to load with...

/usr/bin/filebot: 14: /usr/bin/filebot: java: not found

If you use 'sudo apt -y install ./FileBot_4.8.5.deb' then you'll get...

Error: LinkageError occurred while loading main class net.filebot.Main
java.lang.UnsupportedClassVersionError: net/filebot/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0

Naturally these *can* be resolved after the fact... but that's not really the point

Installing some basic desktop application really ought to just be...
Step 1) Add the additional repository (either graphically through Software & Updates, or via command line)
Step 2) Tell your system the name of the package you want to install (again graphically or command line)

You've kind of got all the information you need, it's up to you how to do this. I suspect you don't package for Linux all that often (just a feeling).

Personally I'd whack arch-dependant versions of openjfx in to the package itself (and the package could stay multi-arch) just like you do libjnidispatch.so.

To be honest including only aarch64/armv7l/i686/x86_64 versions of libjnidispatch.so means the package isn't really 'all' arch anyway - and the Debian lintian systems picks up on that and may warn people the package is of bad quality :S But I don't care about that personally.

[rednoah]

Does apt not automatically install Recommends packages? It seems that openjdk-11-jre is not installed automatically.

Forcing things via Depends has its own pitfalls. See discussions above.

Including OpenJFX is possible, but then it's gonna be amd64 only, as OpenJFX only publishes amd64 binaries. There seem to be more and more Raspberry Pi GUI users recently, so multi-platform would be preferred.

[Lantizia]

If Java 11 is an issue, then we could consider sticking to Java 8 (which makes JavaFX work out of the box on 18.04 but not work on anything newer)

Another way to look at this is... don't bother giving people a .deb file at all.

Make them use the repository - it's the best way IMO. Really .deb files aren't meant to be used in this way (which is why apt only *just* like this/last year got the ability to install from them directly - granted dpkg could, but it wouldn't resolve dependencies without then calling apt-get after to fix the system).

If you stick with the repository you can do what everyone else does and instead of having...

Code: Select all

deb [arch=amd64] https://get.filebot.net/deb/ stable main

Have...

Code: Select all

deb https://get.filebot.net/deb raspbian-jessie main
deb https://get.filebot.net/deb raspbian-stretch main
deb [arch=amd64] https://get.filebot.net/deb trusty main
deb [arch=amd64] https://get.filebot.net/deb xenial main
deb [arch=amd64] https://get.filebot.net/deb bionic main
deb [arch=amd64] https://get.filebot.net/deb cosmic main
deb [arch=amd64] https://get.filebot.net/deb jessie main
deb [arch=amd64] https://get.filebot.net/deb stretch main

That way you can have packages that are tailored to the situation they're going to find themselves in.

Additionally I don't think Recommends are followed when installing an individual .deb package - it is something read by apt... something that is being bypassed by not installing from a repository.

[rednoah]

New DEB for testing:

* Changed to amd64 only and included OpenJFX
* Changed Recommends to Depends

Code: Select all

https://get.filebot.net/filebot/FileBot_4.8.5/FileBot_4.8.5_amd64.deb

The APT repository is built from DEB packages, so there's gonna be DEB packages regardless of whether I make them visible or not. Either way, the final release will be available via APT so users can auto-update easily.

I'd rather not maintain multiple packages for multiple platforms if at all possible.

Multi-Arch DEB for Raspbian / armhf support will come eventually, but I guess that can wait until next year. There's always the portable package in the meanwhile.

[rednoah]

The FileBot 4.8.5 release now contains two additional DEB packages:

* universal (requires OpenJDK 11 and OpenJFX 11)
* universal-jdk8 (requires OpenJDK 8 and OpenJFX 8)

The universal one should work on Ubuntu 18.10 / Debian 10. The universal-jdk8 one should work on Ubuntu 16.04 LTS / Ubuntu 18.04 LTS / Debian 9 and Raspbian / Raspberry Pi (untested). Both rely on apt for all native dependencies.

[Massaguana]

Here this Match by Title don´t work.... i don´t know why...

Original Filename: Detektiv.Conan.S01E15.Eine.moerderische.Zahl.German.ANiME.FS.720p.HDTV.x264-ATAX.mkv

Match: Detektiv Conan - S25E82 - Mörderische Zeiten im Cafe Poirot (1).mkv

When i look into TheTVDB the correct name are: S01E13

What can id do to Rename this Anime?

Thanks

[rednoah]

Looks like the ö / oe prevents an exact title match in this particular case. Replacing oe with ö or o will fix that. Interestingly, the "wrong match" seems to have gotten a boost in this case particular because it was aired somewhat more recently.

Generally speaking, you can always match files and episodes manually:
https://www.youtube.com/watch?v=btNSv7A ... nd&index=2

[weyb06]

Hi,

my expression is :

Code: Select all

{s00e00} - {t} ({resolution}_{kbps}_{vc}_{channels}_{ac}_{source}_{languages}_{lang}_{subt})

1/my 1st question is :
where does Filebot take the informations {source}, {languages}, {lang} and {subt} from ? MediaInfo for all of them ?

indeed, I have plenty of cartoons and when I look at them with MediaInfo, most of them don't have the language set, neither the source, and when i apply the expression, i get "fra" as language --> why ?

2/I don't see how Filebot could retrieve the "source", as i never saw it in MediaInfo --> does it come from MediaInfo ??? how can i set it in the cartoons ? with which tool ?

thank you very much in advance for your reply

regards

EDIT :
I found mkvtoolnix to set the language, but i don't see how to set the "source"

[rednoah]

where does Filebot take the informations {source}, {languages}, {lang} and {subt} from ? MediaInfo for all of them ?

Does NOT use MediaInfo:
{source} is based on the file path only, matching kown patterns such as BluRay.
{lang} and {subt} is for subtitles, matching the subtitle language suffix from the file path, or by running statistical language detection on the file contents of text-based subtitle files.

Does use MediaInfo:
{languages} is a convenience binding for reading audio languages (via libmediainfo or ffprobe depending on your install).

I don't see how Filebot could retrieve the "source", as i never saw it in MediaInfo --> does it come from MediaInfo ??? how can i set it in the cartoons ? with which tool ?

If the filename doesn't say Bluray / DVDRip / WebDL / etc then {source} won't work. If you just have the video file, then it's impossible to tell if it came from BD / DVD / Netflix / iTunes / etc. You could guess based on file size / resolution / bitrate / etc in your own format code but it's ultimately guesswork unless the file is explicitly tagged in some way.

[weyb06]

hi,

thank you for your reply !
i understand a little better how it works !

I found mkvtoolnix to set the language, but i don't see how to set the "source"
--> which property could i set (with mkvtoolnix) as the "source" so filebot recognizes/reads it with MediaInfo (and then afterwards i'll be able to get it), please ?
--> I mean to use a property i don't use to set the "source"...

EDIT : you should precise on https://www.filebot.net/naming.html that {lang} is for subtitles only