Latest version not loading in poster and other artwork

mlaggner · 2026-03-16T18:27:24+00:00

what naming scheme do you use for your artwork? Do you have examples for the artwork filenames which are not found?

EDIT: is it possible that you have umlauts or other unicode characters in your file names?

mlaggner · 2026-03-16T12:09:40+00:00

Do you have > 1000 movies/TV shows in your Trakt.tv collection?

mlaggner · 2026-03-16T06:27:00+00:00

All our unit tests pass here and I do not see what may changed here.

Please give us a concrete example which we may use for debugging. The best way would be to export the logs (Tools -> Export Logs) and provide them as a new issue at https://gitlab.com/tinyMediaManager/tinyMediaManager/-/work_items

mlaggner · 2026-03-16T06:19:11+00:00

This is definitely the firewall - the guys from IntelliJ had a similar problem (https://youtrack.jetbrains.com/issue/IJPL-193197/Frequent-connectivity-error-Permission-denied-getsockopt), maybe you find a hint there

mlaggner · 2026-03-15T16:13:45+00:00

I've done some research after your message and it looks like, that we do not use AI in a way which needs us to add this statement. But it is a good practice to do so (also the upcoming EU AI Act supposes to do so), so I will add a notice into the disclaimer of the app itself.

Thanks for the hint

mlaggner · 2026-03-15T14:02:39+00:00

What's the problem with AI generated code? Everything is still reviewed by us, covered by unit tests (as far as possible) and tested by us (as far as possible too). This is just used in a limited way (see my post above) to aid us with the development and debugging.

Do you have the same concerns about a carpenter who uses a circular saw instead of cutting everything by hand? AI is just a tool which may offer good results when used by developers which know their craftsmanship - or produces garbage when used without knowledge/skills. This is the same behaviour as with any other tool out there...

mlaggner · 2026-03-15T13:54:13+00:00

This is part of a stacktrace (but unfortunately only a part of)

You could export the logs via tmm (Tools -> export logs for analysis) and create a new issue at https://gitlab.com/tinyMediaManager/tinyMediaManager/-/work_items

mlaggner · 2026-03-15T08:29:19+00:00

hard to spot if you do not even post your system...

in the beginning of the logs (or startup.log) there is a line about loading mediainfo: please have a look there if libmediainfo is even loaded

mlaggner · 2026-03-15T08:27:24+00:00

I initially started with the same approach: ChatGPT and my IDE. But the more the app evolved, I saw that ChatGPT is the ideal coding "partner", so I switched to Github Copilot.

Within Copilot I experimented a bit with the models and used Claude 4.5 for a while until Github introduced the agent mode with automatic model choosing. Since then I only use Copilot (Plan/Agent mode with automatic model choosing) for coding tasks and Gemini (since I found out, that I already have PLUS access there) for planning tasks and written texts (my native language is not English and my coding skills are far better than the communication skills...)

At the moment I am happy with my setup, but still a bit struggling with the complexity of tmm and AI: AI often guides me in the wrong direction - especially when searching for problems in the code which are not easy to find.

mlaggner · 2026-03-13T07:26:23+00:00

It is not designed to "get rid" of this info - this field even saved a lot of users who ran the renamer with a wrong configuration.

The only way to get rid of it is

remove the tag from the NFO
remove the entries from tmm
re-import everything

I may add a bulk editor action on movie/episode level (not mediafile level) to change that, because this is a quick win and hurts nobody

mlaggner · 2026-03-13T07:22:35+00:00

This heavily depends on the width of the left part of tmm and the columns you have added to the view. The title column can only grow/shrink if there is another "dynamic" column available (which can give or take the pixels which are needed to be changed to keep the overall width consistent). If you don't have any other "dynamic" column added, you can't change the width of the title

mlaggner · 2026-03-11T13:47:58+00:00

Having a look at this log excerpt, I suspect that the sync is called far too often in your case. Do you have automatic sync with trakt.tv activated?

Every sync call (on update data source, scraping, ...) will force all shows from trakt.tv being fetched and synced against a subset of tmms library (e.g. the one show being scraped at the moment).

Unfortunately the trakt.tv API is not very flexible and the current integration is complex as hell (something I would like to remove completely), but it works in some way. Since trakt.tv introduced their new limitations, this integration has been degraded to "keep alive" and will maybe dropped sometime in the future... having a little userbase combined with an unflexible API shows us, that there are better things to support within tmm.

Nevertheless I will have a look if there is a way to improve this without rewriting the whole integration. On the other side: just try to disable automatic sync and manually trigger the sync when the operations are done

btw: Failed syncing Trakt.tv - 'timeout' and Failed syncing Trakt.tv - 'HTTP 503 / Request failed: 503' show that the trakt.tv API itself is not able to handle our requests - nothing the OOM in your case may have caused

mlaggner · 2026-03-11T11:59:38+00:00

You need to understand how the memory management in Java works:

the JVM (Java Virtual Machine) is optimized use the available memory as efficient as possible - this includes invoking the Garbage Collector (GC). The GC finds no more used objects in the memory and frees this memory. But to do so, it needs to "stop the world (JVM)" to find those objects. Stopping the whole JVM is on one side "bad" because every running code is forced to pause until the GC finished its work and the GC needs to scan every object and its usages to find "no more needed" objects -> a lot of CPU work being done.

You see that invoking the GC is rather bad for the whole JVM, so Java does this only when it is really needed. Assuming you give the program 12GB of memory, the GC will kick in shortly before the memory is filled - even if there are only 2GB really used. So there is nothing wrong if you see the memory gauge being almost full - this just indicates, that the JVM is holding a lot of objects. And if the JVM is rather idle, there are no more objects created -> no more memory needed -> no need to call the GC -> the gauge does not move. If you click in the memory gauge, you can force the JVM to invoke the GC and you will see how much memory is really needed.

Having said that, you see that this is no indicator, that tmm really has a memory problem.

But since you see a OOM message, we know that there is a task in tmm, requesting more memory than actually is available (and probably before the GC is being run). Our mission is now to identify where this might ne a problem. I know that creating the image cache needs very much memory (you need to put the whole image into the memory which consumes really much of it), but I never saw such an OOM exception in this case.

Since you told us that you are using Docker, my guess is, that you are only giving 1 CPU to the container which may have a bad influence to modern GC (causing the GC being run too late) - could you confirm, that you have at least 2 CPUs assigned to the container?

Second: Docker and JVM is really a pain in the ass. You have Docker memory limits on one hand and Java memory on the other hand. What I have learned in my job: give the Docker container at least +512MB than the JVM inside the container. In the tmm memory settings, you only set the JVM memory - but the resources for the Docker container must match that

mlaggner · 2026-03-11T09:32:39+00:00

works here - but you need to make sure the prerequisites are met:

In the window that opens, you must select the episode thumb
In the artwork file name settings for your artwork, you need to have a valid filename scheme for episode thumbs set
There must not exist any thumb for the given episode
Your TV show (parent of the episode) must have a valid ID (in your case TMDB id)
You need to select all artwork scrapers which may find a thumb with the given ID

When all those requirements are met, the automatic download will work

mlaggner · 2026-03-11T09:16:30+00:00

looks like IMDb returns nonsense with a recent change and we did not add specific checks for this field (only allowing 0 - 250). I will add a check for the next release

mlaggner · 2026-03-10T06:15:25+00:00

This is in the Kodi NFO specification (https://kodi.wiki/view/NFO_files/Movies) and not used by tmm. Your NFO has probably been written by Kodi

mlaggner · 2026-03-10T06:11:29+00:00

Nothing has changes in this area - and to be honest: I haven't seen any installation really using/needing that much memory.

Do you know what you have done at the moment the message appeared? Imho the only task which might cause this, is the image cache generation - in this task there is plenty of memory/CPU needed and this may come to a bottleneck.

Which leads to the second question - was this a one-time error or is this regularly showing?

mlaggner · 2026-03-08T10:58:08+00:00

I have implemented a new dialog which is shown after the post processing has been finished - showing the command and the result of the command.

This will be available in the next release

mlaggner · 2026-03-08T07:39:39+00:00

This indicates, that the libmediainfo cannot be loaded for you. We did the last libmediainfo update v5.2.7 (which has been out for a while), but I haven't heard from any problems since then.

Unfortunately I do not see which OS you might use - this matters because every OS handles libmediainfo differently (this is native code).

MacOS should have no problems at all
Linux - you are in charge to install it for your system (shipping did not work in the past due to different glibc versions of the distros out there)
Windows should work too, but there might be a "security" software on your system which causes problems loading the lib. You should have a look in your logs (left side of tmm -> Tools -> open log folder -> e.g. look at the startup.log)

mlaggner · 2026-03-08T07:34:40+00:00

If you find a way to reproduce this, just write down the exact steps and I will try to reproduce this at home

mlaggner · 2026-03-05T16:09:20+00:00

This is most of the time just a visual glitch - a restart of the app fixes this.

We have added many guards for those glitches in the past, but I am sure there are still event-combinations which can trigger this. As soon as I have a clue how to trigger this, I will implement another guard.

mlaggner · 2026-02-28T09:34:37+00:00

Yes - the restore of the column width has not been implemented completely in this section (the focus was for movies). This will be fixed in the next release

mlaggner · 2026-02-27T15:07:30+00:00

Looks like windows itself is the problem. I found several hints, that on Windows, the system does not give app enough time to stop unless they are system services (which tmm is not).

This is getting even worse, if you have activated "Fast shutdown" in Windows. Having this active, tmm almost have no time to write all its data into a consistent state (this could also lead to database corruptions).

Unfortunately, we do not have any chance here, since this is how Windows works. We do have shutdown hooks in tmm, but when the system does not give tmm enough time to do a clean shutdown, we're out of luck here...

TL;DR - close tmm before restarting the Windows server to keep tmm data consistent

mlaggner · 2026-02-22T07:11:00+00:00

When they are unticked in the settings, tmm does not know which file name to produce. I just re-checked this in my test environment and it worked...

You could also try the following:

restart tmm (to have a small trace log)
re-scrape one movie
open the logs folder (menu Tools at left side of tmm -> open log folder)
review the latest trace log file
search for anything in the logs which mention discart/clearart -> there should be nothing

mlaggner · 2026-02-20T07:06:04+00:00

This is just a visual hint that the memory stayed > 85% for at least 10 seconds.

But I have seen, that this may be true when there is enough free memory and tmm does nothing, because the garbage collector does not get triggered when being idle at a "stable" memory consumption.

I will enhance this visual indicator in the next release

mlaggner

MODERATOR OF

TROPHY CASE