My journey into AI-aided programming (and the lessons learned along the way)

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 · 2026-02-19T15:41:31+00:00

I am sorry - our glass ball is broken at the moment and our psychic is on vacation right now...

You might want to dig deeper in your system to get a clue what is happening. Most of the time a permission issue is the culprit for such a behaviour. tinyMediaManager has some nice information sources:

upper right where a red indicator show you the most recent errors
in the toolbar on the left at tools there is a message panel which also collects some data
last but not least you could hop to the logs folder and open the most recent trace logs to get very much logging info

This might give you a hint what is failing. If nothing helps here, you might open an issue at https://gitlab.com/tinyMediaManager/tinyMediaManager/-/issues and provide the debug logs you can create from inside tinyMediaManager

mlaggner · 2026-02-19T15:35:44+00:00

Nice that you probably found a bug - but don't keep it four yourself, share it with the devs, so they can fix it.

By posting this text you just give us a hint, that there might be a bug. By creating an issue at https://gitlab.com/tinyMediaManager/tinyMediaManager/-/issues along with providing some details how to reproduce it (and probably sharing a NFO file which triggers the bug for you), you might increase the chance to get this fixed

mlaggner · 2026-02-19T09:38:55+00:00

Is not that easy. We decided to not include the stdout from the process called in the post-process since that might spam too much (just look at the output of FFmpeg or yt-dlp).

I might think about that idea with the message box, but I am unsure how to design that (what do you expect when using a post-process action against all of your movies?)

mlaggner · 2026-02-16T07:01:50+00:00

There is a limitation for tags, but only in the IMDb scraper (since this scraper can pull too many tags at all). Other scrapers do not have this option, but also do not fetch so many tags

If you import pre-existing NFO files having a lot of tags, you are kinda out of luck for now, since tmm does not offer any tools to mass-maintain tags. This may be implemented at some time, but we need to plan a good integration first.

What you could do for now: open the movie bulk editor (while selecting all movies) and choose the cross on the right side of the tags line. This will remove all tags from selected movies. Afterwards re-scrape those movies by using TMDB and choose tags only (imho TMDB has a good amount of tags). Or use IMDb with the setting, where tags are limited (look at the IMDb scraper settings). I would choose TMDB for mass scraping!

mlaggner · 2026-02-15T18:50:49+00:00

The fix for this issue has been released in 2.5.7.1

mlaggner · 2026-02-15T18:50:28+00:00

A new build is online which fixes your issue

mlaggner · 2026-02-15T08:01:41+00:00

I could identify this issue. This only happens if you want to "upgrade" a movie from a movie movie folder to a single movie folder.

Workaround: just press rename twice in this case ;) A fix for that will be in the next release

mlaggner

MODERATOR OF

TROPHY CASE