NFS Library mount and library update speed after new build using i20240108

[ceejayemm]

Version: rAudio 20240108
Kernel: 6.6.9-2 aarch64
Hardware: Raspberry Pi 3B Rev 1.2
SOC: BCM2837 • 841 MiB
CPU: 4 x Cortex-A53 @ 1.20 GHz

Flashed a new SD card with the latest release (i20240108) and ended up with couple of problems:

1. I normally mount my Music Library using a NFS connection to my OMV NAS. Unfortunately the NFS connection dialogue box is screwed up with incorrect prompts - see attached rAudio_NFSMounts.png file below. Mounting my music library via CIFS seems to work OK but I would prefer to stick with my normal NFS mount method.
2. Updating the Library, using a Full Update, is very slow, this may be related to Image i20230620 + Update 20230630: Local database update very slow #1377 or due to using a CIFS mount point which I don't normally do. The update started today at 15:35 and is still running now (17:30). My Library is around 335 albums with approx 5100 tracks so not big, mainly .m4a files with a few (30 or so) .mp3 files, FFMPEG is enabled.

Chris

[cmh714]

Updated rAudio has the same issue....but my drives are fine. Curious if you tried doing it direct via fstab?

[ceejayemm]

No, given rAudio has always been able to be configured via the GUI web pages I don't, as a rule, resort to CLI command line 'tweaks' unless absolutely necessary or as instructed by Rern. If the GUI should do it then it should do it.

Chris

[cmh714]

thats fair! I was just curious :)

[ceejayemm]

Library update completed at 20:01 yesterday - 4 hours 26 mins after starting. Processed 337 albums, 5101 tracks.

Chris

[klassikmann]

@ceejayemm

Library update completed at 20:01 yesterday - 4 hours 26 mins after starting. Processed 337 albums, 5101 tracks.

Hi Chris,
That's definitely not ok. IIRC I need less than 30 minutes in the past (not the actual release) for a full update of the database containing 25,000 tracks in 3,800 albums.

You mentioned in your OP my post from July 1st. But my concern is about the comparatively slow performance of a local database update (local = single album or tiny subtree). In this thread I asked @rern the question #1377 (comment) regarding the necessity of "mpc listall" in bash/cmd_list.sh.
If "mpc listall" could be changed to "mpc listall 'subtree'" as used in older releases, the response time of a local database update could be reduced from about 75 seconds to 15 seconds.

[rern]

Hi Chris,

With today's update, there is a new status for update duration in Player page. Now we can see how long it takes to update, by MPD + by cache.

[ceejayemm]

I am away from home at the moment but will check this out on my return.

Thanks

Chris

[ceejayemm]

@rern
Updated to 2024013 tonight. I cannot seen any fixes to the System / Storage / NFS mount point dialogue with this release.

Also I cannot see the new 'status for update duration' on the Player page. There is a small flashing icon next to Player / Music Payer Daemon / Database but it doesn't seem to do anything else but I do still have a full update running right now. The icon doesn't seem to be clickable for any further information at this stage.

Chris

[ceejayemm]

Ok, now that the Full Library update has completed I can see the new data fields:

Music Payer Daemon
Version: 0.23.14-1
Database: (Music Tracks icon) 5101 (web radio icon) 24 [Counts of tracks and web radio stations - correct ]
Since: 2024-01-16 • 09:55 (MPD: 9m 30s + Cache: 15s)

The new flashing icon noted above has disappeared, obviously (now) this only appears when update is in progress. The new data - MPD: 9m 30s + Cache: 15s - is the time the update took to complete as verified with log data from journalctl -b

So the Library Update speed now seems to be much improved.

I will close this discussion but add a new one to cover the NFS mount dialogue box only.

Thanks.

Chris

[ceejayemm]

See details above