[PROBLEM] library update in progress

[TheOldPresbyope]

@arick

10 minutes or 20 minutes? I'll be generous and assume it took just 10 minutes to scan 112K tracks. That's about 185 tracks / second which seems very low. As I said before, this test exercises only the communication between the player and the server. 

At this point I don't have anything more to offer. I still think your library server arrangement is playing a role but I can't rule out other factors such as resource exhaustion with such a large collection.

Regards,
Kent

[arick]

I only debug stock moOde and I've already mentioned several times that I'm not able to repro your issue on my end so I'll be leaving this thread permanently.

So long

[arick]

@arick

10 minutes or 20 minutes? I'll be generous and assume it took just 10 minutes to scan 112K tracks. That's about 185 tracks / second which seems very low. As I said before, this test exercises only the communication between the player and the server. 

At this point I don't have anything more to offer. I still think your library server arrangement is playing a role but I can't rule out other factors such as resource exhaustion with such a large collection.

Regards,
Kent

Dear Kent, the reason is developer problem. 6.4.2 worked perfectly

[philrandal]

@arick

10 minutes or 20 minutes? I'll be generous and assume it took just 10 minutes to scan 112K tracks. That's about 185 tracks / second which seems very low. As I said before, this test exercises only the communication between the player and the server. 

At this point I don't have anything more to offer. I still think your library server arrangement is playing a role but I can't rule out other factors such as resource exhaustion with such a large collection.

Regards,
Kent

Dear Kent, the reason is developer problem. 6.4.2 worked perfectly

Perhaps you'd be kind enough to share the exact parameters used when mounting your SMB shares.

Windows 7?  That's effectively abandonware.  If Microsoft doesn't support it, except by paid-for security updates, why should we?

Phil

[vinnn]

I agree that OPs scanning time seems very slow, my collection is around 93000 tracks and takes about 5-6 hours to scan in from scratch. I have Moode running on a Pi 3B+ connecting to my file server with NFS over Wi-Fi.
NFS is a more efficient filesystem protocol, you're likely to get a better I/O rate over NFS.... and yes, noone should be running Windows 7 for server duties.

[Dradder]

@arick

10 minutes or 20 minutes? I'll be generous and assume it took just 10 minutes to scan 112K tracks. That's about 185 tracks / second which seems very low. As I said before, this test exercises only the communication between the player and the server. 

At this point I don't have anything more to offer. I still think your library server arrangement is playing a role but I can't rule out other factors such as resource exhaustion with such a large collection.

Regards,
Kent

Dear Kent, the reason is developer problem. 6.4.2 worked perfectly

6.6.0 worked perfectly for me, with indexing a collection of 24,786 albums, but only with the 32-bit kernel selected. If you're using the 64-bit kernel, try switching to the 32-bit kernel, and see if 6.6.0's indexing function works better.

[swizzle]

@arick

10 minutes or 20 minutes? I'll be generous and assume it took just 10 minutes to scan 112K tracks. That's about 185 tracks / second which seems very low. As I said before, this test exercises only the communication between the player and the server. 

At this point I don't have anything more to offer. I still think your library server arrangement is playing a role but I can't rule out other factors such as resource exhaustion with such a large collection.

Regards,
Kent

Dear Kent, the reason is developer problem. 6.4.2 worked perfectly

6.6.0 worked perfectly for me, with indexing a collection of 24,786 albums, but only with the 32-bit kernel selected. If you're using the 64-bit kernel, try switching to the 32-bit kernel, and see if 6.6.0's indexing function works better.

I’ve seen mpd and the 64-bit kernel have problems before, but usually am not running a standard version of moode or sometimes mpd or the kernel. I usually set up all network, audio and system preferences (except 64-bit) then reboot, scan the library, then switch to 64-bit, reboot and done. Once the initial library scan is done adding subsequent albums works as expected in 64-bit.

Tim supports his project for basically free so unless a problem is general in nature or can be easily replicated it’s not reasonable to expect him to spend what free time he has to try to understand why a very complex system is having an issue in one specific instance. That doesn’t mean other users can’t help though and I think Dradder’s suggestion is on the money here.

[Dradder]

@arick

10 minutes or 20 minutes? I'll be generous and assume it took just 10 minutes to scan 112K tracks. That's about 185 tracks / second which seems very low. As I said before, this test exercises only the communication between the player and the server. 

At this point I don't have anything more to offer. I still think your library server arrangement is playing a role but I can't rule out other factors such as resource exhaustion with such a large collection.

Regards,
Kent

Dear Kent, the reason is developer problem. 6.4.2 worked perfectly

6.6.0 worked perfectly for me, with indexing a collection of 24,786 albums, but only with the 32-bit kernel selected. If you're using the 64-bit kernel, try switching to the 32-bit kernel, and see if 6.6.0's indexing function works better.

I’ve seen mpd and the 64-bit kernel have problems before, but usually am not running a standard version of moode or sometimes mpd or the kernel. I usually set up all network, audio and system preferences (except 64-bit) then reboot, scan the library, then switch to 64-bit, reboot and done. Once the initial library scan is done adding subsequent albums works as expected in 64-bit.

Tim supports his project for basically free so unless a problem is general in nature or can be easily replicated it’s not reasonable to expect him to spend what free time he has to try to understand why a very complex system is having an issue in one specific instance. That doesn’t mean other users can’t help though and I think Dradder’s suggestion is on the money here.

I usually set up all network, audio and system preferences (except 64-bit) then reboot, scan the library, then switch to 64-bit, reboot and done.

That's basically what I'm doing now.

Once the initial library scan is done adding subsequent albums works as expected in 64-bit.

Interesting; I haven't tried that yet. I'll give it a go & see what happens.

[arick]

Many thanks to all!

@philrandal
Exact mounting parameters are standard vers=1.0,ro,dir_mode=0777,file_mode=0777. I have changed vers to 2.0, 2.1 and 3.0 with the same result, maybe 2.1 was a little faster. I have used 2 versions of MPD and 64-bit kernel too, the problem of library update stays unsolved. I still use W7 because this PC is not for work, for storing media only.

@swizzle
It will take several minutes to replicate the problem by Tim. It’s necessary to write the image and to start library update, it’s all.


My technical intuition says that the problem of library update isn’t connected with the poor network performance. The real reasons of such performance are slow WiFi, slow HDDs and Ethernet via Powerline. Maybe the problem of library update isn’t connected even with enormous music library size. I’ll try to reduce the library to minimum and reproduce the problem.
I think it‘s developer problem of incorrect library generate or update ending. The system jobs are ended normally, but some system triggers doesn’t indicate it, even after rebooting.

[philrandal]

Just an aside: 30,000 albums is about 60 years of collecting 10 albums a week.

Hardly a normal use case :-o

(Not that I'm envious or anything LOL)