[CrystalP]

The wireshark captures show signs of probing for bd / dvd folder structure, but given your explanation that must be blind probing which returns in error.
At the same time the reading of the posters/fanart/actors/etc is not visible... But I don't know the low level protocol and how things are supposed to look.
I'd say that probing for dvd and bd could be more efficient and some network round trips could be avoided for faster scanning, but it's the same for 20.5 and 21 so not a factor in your problem.

git bisect is a tool that helps find which commit changed a behavior. It does a binary search of all the changes between a known good point and a known bad point. What you'd have to do is build the version, try it and tell bisect if the result is good or bad. That will narrow the search, it will propose the next commit to test, until the culprit is identified. Given the number of changes between v20 and v21 there are probably around 10 iterations. When we know which commit is the reason we can figure out a fix.
Any version can be built, git has all the history (provided the matching prerequisites are installed, but that's not a problem for v21 code).

[kittmaster]

The wireshark captures show signs of probing for bd / dvd folder structure, but given your explanation that must be blind probing which returns in error.
At the same time the reading of the posters/fanart/actors/etc is not visible... But I don't know the low level protocol and how things are supposed to look.
I'd say that probing for dvd and bd could be more efficient and some network round trips could be avoided for faster scanning, but it's the same for 20.5 and 21 so not a factor in your problem.

git bisect is a tool that helps find which commit changed a behavior. It does a binary search of all the changes between a known good point and a known bad point. What you'd have to do is build the version, try it and tell bisect if the result is good or bad. That will narrow the search, it will propose the next commit to test, until the culprit is identified. Given the number of changes between v20 and v21 there are probably around 10 iterations. When we know which commit is the reason we can figure out a fix.
Any version can be built, git has all the history (provided the matching prerequisites are installed, but that's not a problem for v21 code).

First: I barely have a handle on GitHub, but that won't stop me from figuring it out it gets to that.

Second: I installed Beta1 and it is as fast if not faster than nexus for the first 40 before I stopped it.

Now there is a known good reference. I think videoscanner.cpp is what to diff... I will see if that yields anything.

Edit: Forgot image.

[kittmaster]

If I had to take a stab, I'm guessing this is probably where it might have started:

https://github.com/xbmc/xbmc/commit/0208...a8398f6411

[kittmaster]

I just ran Beta1 full scan:

2024-05-26 20:14:18.447 T:1480     info <general>: VideoInfoScanner: Finished scan. Scanning for video info took 2255632 ms

37 Minutes 35 Seconds

Within 1 minute of Nexus and over WiFi.

So something has happened along the way.

So I'M NOT CRAZY!!! WHOOT!

[CrystalP]

OK it's good to have a starting point. Did performance go down in beta2? beta3? rc1? rc2? 21.0?

[kittmaster]

I have to roll down each one...doing that now....

[kittmaster]

Well that was easy, Beta 2, is where it acts like a slug. So that is where the problem starts.

I double checked by nuking the install, installed beta2 twice and scanned from scratch to be sure, same results I've been seeing.

So whatever happened, that is the source point. Need to diff those 2 and see what changed. I assume I'm looking in the right spot: VideoInfoScanner.cpp

[kittmaster]

So what happens now and how can we get this fixed?

[kittmaster]

??

[kittmaster]

OK it's good to have a starting point. Did performance go down in beta2? beta3? rc1? rc2? 21.0?

Just curious if you have any thoughts?

[kittmaster]

Just installed 21.1..... IT IS EVEN WORSE!

Log here:

https://paste.kodi.tv/payagulixo.kodi

And it crashed as expected. 

I removed all of my databases, all of the files for thumbnails, it is just slower than before. 25 seconds to scan 1 movie file... then multiple log errors, then crashes. 

This needs some serious attention.

[kittmaster]

I did a base comparison yet again against 20.5 and it is complete night and day.

Omega is a complete fail for this aspect, why is this not being pushed to a higher priority? 

I've tried several nightly builds and those trash too for this issue. 

Someone changed something, it needs to be reverted... so frustrating!

[CrystalP]

That was a regular log, not debug, and please try with a new portable install with the bare minimum configuration needed to scan to the library and Esturary standard skin to avoid the likely unrelated python errors visible in your last log.
Your issue is not widespread, we don't known what's different between your system and everybody else's, so your Kodi needs to be as close to default settings as possible to eliminate possibilities.
No need to scan your entire library for the debug log, scanning a directory that contains 10 movies would be plenty.

[kittmaster]

I posted this on Github or someone who asked:

sebehenepi.kodi (paste)

I'm not at home but did the testing there to see the same results as posted here with the latest versions prior to leaving.

I am remote now, but have a similar structure in my camper, it has a bunch of errors too about not finding paths, yet it fully loads into the main movie section. 

See if that sheds any light "for now", early night tonight, but I'll switch it all over as you mention and post a new log in the morning. 

It's date night... trumps all Kodi work... LOL.

I'm on GMT-5 time, so will have it early morning.

[CrystalP]

In that log the movies are scanned in a second or two, I don't see the problem.