Emby server runs crazy every day 0730 - nothing is scheduled.

[requa3r0 12]

My Emby server runs crazy every day 0730 but nothing is scheduled.

The few tasks takes only a few seconds.

The server is not in use in any way

Its almost floors my server. (Runs on a VM under proxmox) - here is the proxmox CPU usage, and htop from the VM

What is going on. How do I stop what ever its doping

 

This is the process

There are no changes to the local files, except of an update script adding new stuff. I check each file for a comparison with rsync. That is all.

 

But logs show its updating apparently the hole lot.

 

Latest Emby server Version 4.8.11.0

Emby Server is up to date

Linux version 5.10.0-19-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.149-2 (2022-10-21)

Running on a Debian 11 server, that is fully up to date.

 

 

[Q-Droid 989]

Does the same happen if you run the script manually? If it does then right or wrong Emby is detecting changes from your script.

 

[Luke 42077]

What is the inatgz extension for?

[requa3r0 12]

Not sure..I don't have any files with that extension. I Only have  *.strm and *.srt files in the lib folders.

Nothing is changed over night.

I only update the files and folders with an rsync command adding a few new files now and then if somthings new has arrived..but emby goes creazy and runs for hours every day.

[Luke 42077]

Well you had them at the time that the server was reacting to the changes. My suggestion would be to have your script run on an external directory and then move the final files into the library afterwards.

Or if you don't want to do that, then I would disable the realtime monitor for each of your emby libraries.

[requa3r0 12]

But..you are right..what is *inatgz ??

And why is an rsync command...on a library folder giving the emby server a reason to re-scan a full library of 80.000 items ?

My script runs a m3u to strm expansion with this github lib.

https://github.com/erdesigns-eu/M3U2STRM

Then I rsync the new extracted m3u data to my local library to add any new stuff.

With this line of code.

rsync -av --exclude '*.srt' -P -R --delete --quiet IPTV /home/debian/;

And then the emby server rescans the hole library for some reason.

Its been bothering me for years.

 

@LukeI can provide the script and some test data / subscription for test purposes.

Can you pm me for further.

requa3r0

 

[requa3r0 12]

Real time monitoring is tuned of years ago.

Can you elaborate if I need to do anything further.

requa3r0

 

[requa3r0 12]

I extract the new m3u content to a temporary folder.

There are only *.strm files.

Then I rsync to the static folder where I have *.strm and *.srt files.

Only a few files are crated in the static folder on once in a while.

Where should the *inatgz files come from? 

The are not there and never was.

 

[Luke 42077]

32 minutes ago, requa3r0 said:

But..you are right..what is *inatgz ??

 

I don't know. Probably some software on your system creating these files temporarily.

[Luke 42077]

Quote

And why is an rsync command...on a library folder giving the emby server a reason to re-scan a full library of 80.000 items ?

The purpose of the realtime monitor is to react to changes in your folders, so when there are changes, the server is going to rescan in order to detect new or updated content.

[Luke 42077]

29 minutes ago, requa3r0 said:

Real time monitoring is tuned of years ago.

Can you elaborate if I need to do anything further.

requa3r0

 

That is not the realtime monitor. What makes you think that? Did we really not word it very well?

Quote

I would disable the realtime monitor for each of your emby libraries.

It is an option on each library.

[requa3r0 12]

If your real time monitor is sensitive to a rsync checking and updating a lib. folder with a few files, and then initiating a full re scan of everything,  something is wrong with the monitor.

For now I have to stop this somehow.

Added this in crontab as a temp fix.

 45 7 * * * /bin/systemctl restart emby-server

Let me know if you what some data, or if you have a better idea.

[Luke 42077]

1 minute ago, requa3r0 said:

If your real time monitor is sensitive to a rsync checking and updating a lib. folder with a few files, and then initiating a full re scan of everything,  something is wrong with the monitor.

For now I have to stop this somehow.

Added this in crontab as a temp fix.

 45 7 * * * /bin/systemctl restart emby-server

Let me know if you what some data, or if you have a better idea.

Hi, there are changes detected to strm files. You can see it in your screenshot. What would you like the server to do? Should we just ignore the changes and have other users reporting that as a problem?

[requa3r0 12]

I run this once a week.

I should properly turn of real time monitoring for all the IPTV related folders then, on each lib. If its sensitive to a rsync update!

But seriously ...something is really wrong if its that sensitive.

how else should I automatically add new stuff to a lib. folder.

 

 

[Luke 42077]

What about running your script externally and then moving the output to your media folders?

[Q-Droid 989]

33 minutes ago, requa3r0 said:

I extract the new m3u content to a temporary folder.

There are only *.strm files.

Then I rsync to the static folder where I have *.strm and *.srt files.

Only a few files are crated in the static folder on once in a while.

Where should the *inatgz files come from? 

The are not there and never was.

 

The parent directory, the current directory and all of the strm files you listed have a new time stamp of this morning. Those are changes the Emby server has to do something about.

 

 

[requa3r0 12]

Its the same file! 

rsync will update the time stamp upon checking and adding new content.

There is no need to update the content for 80.000 titles in the library just because of a changed time stamp!!!!

your live monitor is not working very smart is it ;O/ 

Ill try to smart up rsync somehow. Perhaps i can avoid the time stamp update somehow.

There are some switches to work with.

https://unix.stackexchange.com/questions/295619/rsync-no-need-to-copy-the-time-stamp

But seriously...perhaps have a look at the real-time monitor..its clearly over sensitive if a timestamp for the same title will call for a full re-scan of a complete library.

 

 

[Q-Droid 989]

3 minutes ago, requa3r0 said:

Its the same file! 

rsync will update the time stamp upon checking and adding new content.

How is this supposed to make sense, is it the same file or isn't it? New content makes it a changed/different file.

 

[requa3r0 12]

39 minutes ago, Q-Droid said:

How is this supposed to make sense, is it the same file or isn't it? New content makes it a changed/different file.

 

Its the same file with the same file-name, but rsync has checked the static folder with a new temp folder for new content - and updated the time-stamp on all files in the process.

1917.strm is still the same content as 1917.strm although it has an updated time stamp, with respect the the media content of the library.

 

Edited July 24, 2025 by requa3r0

[requa3r0 12]

Damn, it was seriously hard to stop rsync updating any time-stamps on existing files.

But alas..its possible with --no-times --checksum

https://unix.stackexchange.com/questions/295619/rsync-no-need-to-copy-the-time-stamp

rsync  -i -a --no-times --checksum --inplace --exclude '*.srt' -P -R --delete --quiet IPTV /home/debian/;

 

the --checksum will disregard the time-stamp and only work on checksum.

Its super small files, so I cant even see a performance difference. Time-stamps are not updated on the existing files!!! 

the --inplace  switch will prevent the rsync temp files, apparently the infamus  *inatgz files ;O)

Anyway this works.

Ill see if that will calm the real-time monitor down a bit.

But...still...there are a ton of reasons why the real time monitor should not activate on a simple time-stamp change on the same file (title), so perhaps this should be looked at.

Thanks

 

Edited July 24, 2025 by requa3r0

[Lessaj 467]

That's literally what it uses to determine if it needs to recheck a file. It's working exactly as intended.

[requa3r0 12]

4 minutes ago, Lessaj said:

That's literally what it uses to determine if it needs to recheck a file. It's working exactly as intended.

I realize that, and its a really bad way of checking. 

@Lukehelp me out here...a file representing a title in the library should not be heedlessly re-scanned just because of a timestamp change.

My lib with 80000 titles have re-scanned every day for years due to this.

Check the path and filename. If its already scanned, why in gods name re-scan it ?
 

[Luke 42077]

1 hour ago, requa3r0 said:

I realize that, and its a really bad way of checking. 

@Lukehelp me out here...a file representing a title in the library should not be heedlessly re-scanned just because of a timestamp change.

My lib with 80000 titles have re-scanned every day for years due to this.

Check the path and filename. If its already scanned, why in gods name re-scan it ?
 

Why shouldn’t it? You could have replaced the video file with a new copy. If it’s an nfo metadata or image file you could have updated it outside of Emby.

[neves000 15]

2 hours ago, requa3r0 said:

I realize that, and its a really bad way of checking. 

@Lukehelp me out here...a file representing a title in the library should not be heedlessly re-scanned just because of a timestamp change.

My lib with 80000 titles have re-scanned every day for years due to this.

Check the path and filename. If its already scanned, why in gods name re-scan it ?
 

I assume that monitoring detects a change in the timestamp on the folder rather than on the files, which generally indicates a change in the folder to update.

Checking only the path is not enough. I often replace one video with another of better quality, with the same file name, so it has to be rescanned.

Edited July 25, 2025 by neves000

[Q-Droid 989]

It has to monitor both files and folders. At least on *nix systems and probably most OS and filesystem types creating and deleting files and directories updates the change time of the current directory too. Updating an existing file only changes the time on the file itself but not the directory. On the other hand renaming a file changes the current directory time stamp but not the one for the renamed file. These should all trigger a scan by Emby because something has actually changed.

So if a sync doesn't have to make changes there's no need to modify time stamps, that would be the correct way to do something like this. If temp files are being created that also means a sync/update has happened because the compared files were not the same.