robert5733 wrote: ↑Fri Jan 05, 2024 7:11 pm
When I stopped the SQL Server I got this ...
It's saying to executereader in the Y: folder
I'm pretty sure that's a reference to the developer's PC's drives. I believe Binnerup has (had?) a team of developers, and they're likely working off of a shared network drive, mapped as Y:, so that path is to the source code on the developer's PC.
The part that caught my attention is that it is the project folder for MMCM v5.1, not 5.4. Either lazy naming practices/code management on their part, or they've messed up and included some 5.1 code in 5.4. Probably just laziness - I'm guilty of this too. Scary the thought is that they might have used the wrong code...
It's not trying to execute anything on your Y drive. It's executing code in Database.vb, and it's referencing where that source code originated on the developer's PC. This is information that helps developers troubleshoot an issue.
robert5733 wrote: ↑Fri Jan 05, 2024 7:11 pm
As soon as I logged in with no movies in the database, it immediately started with the timestamp every 12 seconds.
Yes, I believe this is the My Movies General Service scanning for changes, and this is just one of the checks that it does. Adding a timestamp to the DB allows it to minimize the effort to perform the next check, as you only have to check for new data that changed after the last timestamp. I do something similar with CME's/CCC's changes only export, but I put the timestamp in the Windows Registry.
Adding the timestamp itself isn't a cause of performance issues - rather it is what the timestamps represent, a full scan for any changes. This statement will have more weight at the end of my post here, just you wait...
robert5733 wrote: ↑Fri Jan 05, 2024 7:11 pm
Disabling SQL Server stops the update. Is SQL Server needed to do the exports? Can you just stop the service and do the export and turn it back on?
As you've already discovered, no. The regular updates are My Movies working as intended. And exporting data via the API pulls data from the database, so the SQL Server (the database host) has to be running or else the DB isn't reachable.
Additionally, the My Movies General Service (which is doing those 12-second interval scans for changes) is also the API host. So if you turn off the General Service to stop the checks, it also prevents CME/CCC from accessing the API.
robert5733 wrote: ↑Sat Jan 06, 2024 2:56 am
Hope I didn't screw something up. CCC Exported in 33 minutes for 1837 titles. More than acceptable for me to use.
That's a great time, much better than I get. Though sometimes performance is better after a fresh boot, and sometimes it is better when data is cached from a previous run. I think you had a ton of memory on this PC, which might have helped on caching. It also might be that your NAS cached the data that MM is scanning for on export, so it provided it faster on repeat attempts.
But don't forget that CME's and CCC's changes only export is really, really good, and runs really, really fast. You should be leveraging that as much as possible.
An occasional full export is helpful, though, as there are some My Movies change detection bugs, so some changes don't get flagged in the API, so CME/CCC don't know to export them. These are pretty rare, though, and not something you encounter daily, and normally only affects data of minor importance to CMC.
I normally do a full CCC export once a month. I only run CME a few times a year, when I plug in my backup array to make an offline copy of everything, and the changes only export is good enough for that. I might do a CME full export once every year or two. So while MM's performance is pretty abysmal, I've worked really hard to make CCC mask that issue so that you almost never notice.
robert5733 wrote: ↑Sat Jan 06, 2024 2:56 am
Since CME is only for future use in the event of MM demise, I can deal with the slow process once in a while. Just have to remember to go in and clear the logs for MM now and again. I think there might have been a place to turn them off in settings.
One thing to keep in mind is that My Movies is single-threaded. That's a crazy thing in this day and age! CMC/CME/CCC are all heavily multi-threaded, something I had to learn how to do years ago to make my pinball controller software - physics don't pause to wait on code latency! Once you learn how to do it, it's pretty simple, and I simply can't understand why Binnerup is still pushing a single-threaded app (though I'll certainly vote for single-threaded over zero-threaded, please don't take my My Movies away!).
Because My Movies is single threaded, it can literally only do one thing at a time, and everything else gets put on hold. This is essentially thread blocking, and is one of the main reasons MM is so laggy in general.
This means that not only is CCC and CME impacted by the My Movies General Service doing other tasks (like scanning for changes), they also compete with each other. You do NOT want to run CCC and CME exports at the same time, as that will bring the MM to its knees and everything will grind to a halt (and catch fire).
robert5733 wrote: ↑Sat Jan 06, 2024 2:56 am
Just have to remember to go in and clear the logs for MM now and again. I think there might have been a place to turn them off in settings.
If you're not actively troubleshooting MM, definitely turn off the logging as much as possible. Not only do the logs slow processing down, but apparently the logs trigger your antivirus software to re-scan them, over and over, as they are being written, so it further degrades performance. This is a well-publicized issue, Binnerup themselves reference it often in their performance troubleshooting steps.
I've never objectively measured performance deltas with logging on/off, but I can definitely say it feels slower with logging on.